Most people who discover MiniScript are delighted at its design and feature set. It covers all the important functionality — things like true lists and maps, functions as first-class objects, and object-oriented programming — while still being minimal and clean, small enough to document in a single page.
But there is one omission that is sometimes a source of complaints: MiniScript, as of now, does not have math-assignment operators like += and -=.
A Mini Micro user today asked me to explain why it was designed with sprites that are retained between frames, instead of having users explicitly draw them on each frame. This is an insightful question! It's the difference between retained mode and immediate mode graphics.
The Common Gateway Interface, or CGI, remains a valid and simple way to create dynamic web pages and services. MiniScript is an excellent choice for creating CGI scripts. In this post, we'll go over how to set up your web environment and get started making your own CGI scripts, along with some simple examples.
The import function is not a standard part of the MiniScript language, but it is a feature common to many MiniScript environments, including Mini Micro, Farmtronics, command-line MiniScript, and Soda. In this post, we review how import works, and describe some techniques for advanced users.
Version 1.1 of Mini Micro included a couple of very useful additions to the stringUtil module. If you aren't already using the new fill and match methods, you probably should be!
I was live streaming a coding session today, wrapping up a Tetris clone in Mini Micro. All was going swimmingly until suddenly we noticed a bug: after clearing a line, subsequent pieces would sometimes stop before hitting anything. Upon closer inspection, we noticed that the higher-up lines, after moving down to fill the cleared row, often had blocks in the wrong place.
What ensued was an abnormally long debugging session. I tried confessional debugging; I tried walking through the code; I tried checking my assumptions by having the code print out what it was doing. After 20 minutes of this I was still stumped. In desperation, I reached for a tool I should have brought out much faster: the validate method.
MiniScript is most commonly used either in the Mini Micro virtual computer, or embedded within some other game or application. However it is also available on the command line. A command-line MiniScript user asked me the other day: is there a way to clear the terminal window from code?
The answer is, yes and no. There is no built-in API for it, but in most cases, it can be done with an ancient set of tricks known as VT100 escape codes.
As more and more people discover MiniScript, the question is occasionally asked: why? Why was MiniScript created, and why should someone use it rather than some other language?
It's a perfectly valid question, so in this post I will try to clarify. My purpose is not to convince anyone of anything, but to explain why, after years of using other scripting languages, I felt compelled to create something new. I'll do this without attacking other languages, since every language has its fans and I don't want to kick anybody's dog; instead I'll focus on what I think is really cool about MiniScript, and how it offers a collection of advantages that, taken together, can't be found anywhere else.
MiniScript has been available as a Unity plugin since 2017. But it has been such a success with its users that it deserved wider distribution. MiniScript in Unreal games, MiniScript on the command line, MiniScript in your browser... why not? And while it was great to get a little financial support for working on MiniScript in the early days, in the long run keeping it commercial only slows down its adoption. That's why, as of today, MiniScript is open-source.
I have long thought that Unity did not really support configurable input out of the box — at least not without using the ugly default Graphics/Input configuration dialog (which no polished game would ever inflict on its players). Particularly if you wanted to support hot-swappable joysticks or gamepads, I always believed you had to use some third-party plug-in.
But I recently discovered that this is not true! Making configurable, hot-swappable input in Unity can be done without any plug-ins, and it's not even all that difficult. Read on to see how.
A lot of games in Unity are organized into several scenes, most notably a title scene and a play scene. If your game has background music, you're likely to want different background music for each scene.
Just sticking a music clip on an AudioSource in the scene would accomplish that, but the music would cut off abruptly when you change scenes, which is jarring and unprofessional. Much better to fade it out over several seconds. That requires not letting the object be destroyed when the scene changes, and handling the scene-change event — which thanks to recent changes in the Unity API, is not as easy as it used to be.
A frequently asked question in both the Unity forums and on Unity Answers is: How do I make a projectile arc to its target, like an arrow shot from a bow? I've seen (and given) lots of different answers to this question, and honestly, most of them are unjustified hacks.
The right (and easy!) way to do this is: just add a bit of arc to your standard movement. Objects in freefall (ignoring air resistance) follow a parabolic arc, and the equation for a parabola is very simple. So, we can just use that equation to compute how must extra height we should have, and simply add it to our Y position, and the job is done.
Cheat codes are secret ways to alter the functionality of a game. It's a term that makes me cringe as a parent, since we teach our kids never to cheat — but once a game starts to grow complex, cheat codes are absolutely essential testing tools. They let you bypass minutes or hours of gameplay you already know is working, in order to get to the part you're trying to fix.
So, how do you actually implement them? This post explains how we do it in our Unity games.
One of the most general and common tricks ever to come out of industrial control theory is the proportional–integral–derivative controller (PID controller), sometimes known as a "PID loop." It is a simple equation that you can use to control any one-dimensional variable, such as a throttle, a motorized hinge, etc. All it needs for an input is an "error" signal — that is, a measure of how far off something is from where you want it to be, plus three constants. Most importantly, it does not need any model of how the value it's controlling relates to the output.
In this post, I'll give you well-encapsulated code for a PID controller in C#, and show how to use this in Unity to control the throttle of a hovercar. The hovercar physics involves momentum, drag, and controls that don't respond instantly, just like a real hovercar! But the PID controller doesn't care about any of that; once you have the three constants tuned, and hook up the error signal (in this case, the difference between the current altitude and the altitude you want), it does the rest.
For our High Frontier video game, we wanted a data file format that would be easy for people to read and write. This is partly for our own use — we would be hand-editing files defining various parts of the game internally — and partly for mod authors, who would be creating new content for the game.
The big players in the serialization space are JSON and XML. XML is, to be blunt, horrible. It's fine for data that is only ever looked at by computer programs, but for anything that might be read or written by a human, it's just awful. JSON is much better, and it's what we've often used in the past. But it too has more syntax than feels necessary. And at the same time, it lacks some features we really wanted, like comments.
So we have designed a new serialization format: GRFON (General Recursive Format Object Notation). We've been using it for over a year now, and loving every minute of it. And today, we are making it available for everyone else to use too, under the permissive MIT open-source license.
When doing rapid iterations of an app (a cornerstone of agile development), testers sometimes find themselves with an older version of the app. This could be because they didn't get the update email, or they clicked the wrong link, or DropBox didn't sync like it's supposed to, or something got cached along the way... whatever the reason, there are few things less helpful than getting a bug report for something you've already fixed.
In C/C++, it's easy enough to use the standard __DATE__ macro, which the C preprocessor fills in with the actual build date. You can just display this on the title screen or wherever, and testers can easily see whether they're running the latest build. But, surprisingly, C# doesn't have any such feature. This makes displaying the build date in a Unity app a bit harder.
Fortunately, it can be done. Here is the arcane magic you need.
I'm currently doing a job where I need to take 3D polygon data and display it in Unity. These polygons are planar, but oriented arbitrarily in 3D space. Moreover, they can contain holes (possibly multiple holes). Think of a building wall with window cut-outs, and you'll get the idea.
This turns out to be a surprisingly thorny problem in Unity. There is a simple script on the Unity wiki called Triangulator, but it only works with Vector2D and doesn't support holes. I found a blog post on Advanced Triangulation in Unity, but it was neither sufficiently advanced (only works in the XY plane) nor actually in Unity (it wrote each polygon out to a file, invoked an external command-line tool to do the triangulation, and then read the result back in).
The utility referenced in that blog post is called Triangle, which is widely regarded as a very good triangle library. It's open-source C code, so one could make a Unity plugin out of it. But it's not licensed for commercial use, which is a problem for this project. Also, making a native plugin means setting up a build chain for every platform you want to support. For both reasons, I kept looking — I really wanted something in pure C#.
Unity has provided a built-in state machine editor for managing animations since version 4. This is the officially recommended approach to animating a game character. However, it often leads to game logic being divided between code and the animator state machine. I would prefer to have all my game logic in one place, to simplify development and debugging. Moreover, in some cases — especially simple 2D sprite games — the Animator can seem like more trouble than it's worth.
To help clarify the pros and cons, I built a 2D game character using three different approaches:
For the rest of the story, see the full article on Gamasutra!
Unity had a "Live Training" demo called Events: Creating a Simple Messaging System. This is often pointed to as an example of using the UnityEvent class that was introduced in Unity 4.6.
While this was a fun and educational video, it uses UnityEvents in a very odd way, wrapping them in a string-based notification system and hooking everything up in code. Honestly, you could have done exactly the same thing using standard C# events, and it wouldn't have made any difference. (Indeed, prior to UnityEvent, many Unity developers — myself included — did exactly that.)
So I decided to make my own video, accomplishing the same demo but using UnityEvent the way nature intended. The result is a lot less code, easier to maintain, and harder to screw up.
I've been teaching my son C# programming lately. This is a great choice, because it's the best language to use with Unity, and with Unity, he can make games for virtually every platform under the sun. With some luck, he'll be able to make enough money in the various app stores to pay his way through college (or at least pay his own car insurance). And as a bonus, when you know C#, you can also develop native apps for Mac, Windows, iOS, and Android, using various toolkits (such as MonoTouch for example).
However, the code-run-test-debug cycle is slower in Unity than I would like for his purposes. Learning a language is easier when you can play around with it interactively. This is especially true when you're working through small programming problems like those at Project Euler.
We've been delving into Coroutines in Unity lately, and ran into a strange behavior today that took all morning to sort out. In brief, a routine we thought we were calling never got called at all -- a Debug.Log as the very first line of the function never logged anything.
Last week, we gave a sneak peek of BOSS, a new approach to string searching. We mentioned a "bit of magic" with regard to the repetition modifiers, * (0 or more) and + (one or more): these would do a lazy match, except at the end of the search pattern, in which case they would be greedy.
We expect this to be the most controversial feature of the whole BOSS design, so it's worth some time to explain all the considerations behind it, why we made this decision, and what the heck "lazy" and "greedy" mean when it comes to string searching anyway.
In the last couple of blog posts, we first reviewed some of the shortcomings of regular expressions (RegEx). We then took a look at parsing expression grammars (PEGs), which are a new formalism that has a lot of advantages for defining (and more importantly, parsing) computer languages. But while they're great for that, using them directly for string searching is a bit of a square-peg-round-hole situation.
So, we at Luminary Apps have begun work on a string matching library that combines the best features of PEG and RegEx. This blog post is the first public discussion of that library. It's called BOSS, and I think you're going to love it.
In our last entry, I bemoaned the shortcomings of regular expressions for complex tasks. (This was after spending a day wrestling with a three-page-long RegEx pattern for finding functions in a C# TextWrangler language module.) I sketched out what I thought an ideal string-matching system would look like.
Well, that was three weeks ago. I've had time to do some more serious research, and it turns out that there is some modern work that is very relevant. It almost fits exactly what we were looking for — but not quite. It's a new construct called Parsing Expression Grammar.
RegEx is handy. I use it all the time. For simple tasks, it's quite pleasant to use. For intermediate-sized tasks, it's acceptable. But for complex tasks, it is a nightmare to write, read, and maintain.
So, I'd like to suggest that it's time to design an alternative -- something that works just as well on complex tasks as it does for simple ones, and stays readable and maintainable. I agree with not reinventing the wheel... except when our current wheel is square and lumpy.
Subscribe