GDC is over and I'm hanging out at Noisebridge with some friends. I've been inspired this week by some amazing Twine games and authors so I decided to make a short one myself. It feels most like a poem to me.
I just finished playing Christine Love's Analogue: A Hate Story. I would like to share with you my thoughts on the design, themes, and ramifications of the game, hopefully without revealing many plot or character details that could spoil the experience.
Analogue was a remarkable game that stirred up a wide range of emotions. I felt repulsion at the backwards, patriarchal society depicted. Shock, the traumatic kind, at the depiction of horrific events. Sympathy and affection for the protagonist (at least, that's who she was in my view.) And some funny, cute, and adorably awkward moments as well. It was quite unlike the expectations I had for the game going in. It was deeper, more meaningful, more significant.
Processing is a wonderful little language. It's designed to be easy to pick up by artists who want to learn some programming, etc. However, it's a real programming language. If you haven't played with Processing, I'd recommend you go do that right now. They have a great series of tutorials, and of course the entire SDK is free.
This post is for people like me - programmers who want to take advantage of Processing's short iteration cycle, clear syntax, and simple API to use it as a prototyping environment.
First, here is what I think Processing excels at:
Interactivity - It's dead easy to get and use mouse and keyboard input and define event handlers.
Engineering flow - like I said above, the short iteration cycle, clear syntax, and simple API make it a breeze to get up and running quickly and iterating.
Fun - Because of all of that, it's a lot of fun to write stuff in Processing, especially for smaller projects where you are just messing around.
Multiplatform - Out of the box, Processing 1.5 can build native applications for Windows, Mac, and Linux, native Android applications, and web applets (yuck.) Via Proccessing.js you can also supposedly get your sketches to run natively in web browsers.
Here is what I think Processing is weak at:
Large, complex programs (they tend to get a bit unwieldy since it's impossible to organize your classes inside a folder structure.)
Programmer assistance (No out-of-the-box debugger. The preprocessor's errors are often frustratingly non-specific, and can leave you blindly hunting for syntax errors across multiple files.)
Audio (there is no out-of-the-box support, but there are libraries available) Processing now includes the excellent Minim library, but you have to explicitly import it. Audio still appears to be an afterthought in the documentation and tutorials.
I have been prototyping games and visualizers (including the one above) in Processing for several months now, and have learned some incredibly useful things that I think any programmer looking into it should know. Here they are:
For many people, it really doesn't make a difference. But I'm a programmer. I edit code for a living. My editor is the tool of my trade and I want to use the most efficient tool available.
I'd be preaching to the choir if I was telling programmers that they should use good text editors. But I've noticed some patterns in the history of text editors I've used that have made me come up with my own philosophy about choosing an editor. My goals and usage habits are certainly not the same as everyone else's, but I hope that in sharing them I might get you to reflect on your own habits and see if they match up to your goals.
The find utility is so useful for automation that it deserves a special mention on its own. I will not attempt to cover all of its features, only the ones that I use on a daily basis.
I typically use find for two purposes:
To create a list of files matching some search terms.
To execute a batch operation on those files using the -exec argument.
In Shell Scripting: Becoming a Wizard, I layed out a recipe for productive and useful bash scripts that uses a while loop over some sort of multi-line input. This construct is more powerful than find's built in -exec flag, but that power is not always needed.
I'd like to show off some projects of mine that are currently on the back burner, to avoid them from gathering too much dust.
Here is a video of a game prototype I was working on in UDK. My idea is to express the feeling of being in zero gravity in a way that hasn't been done in games before (i.e. no jetpack.) You move by pushing yourself along surfaces and kicking off them towards other surfaces. Once airborne, you can't alter your velocity without grabbing on or bumping in to something (or possibly throwing stuff out of your pockets.) I hope someday to make a real game from this concept.
I reflect on this prototype, why it went to the back burner, and what I learned after the jump.
I was fortunate to get several chances to play Nidhogg at GDC 11. I'd like to share my first impressions of the game.
Nidhogg is a brilliant fighting game for two players created by Messhoff (Mark Essen.)
I suck at most fighting games, although I have a lot of respect for the people that play them. Watching my old roomate Kilo play Super Smash Bros. Melee and BlazBlue and talking with him about it helped me to understand the deep nature of these games. So did the excellent documentary I Got Next. Key to these games is the idea of a metagame, and playing mindgames with your opponent, occurring on different layers of anticipating your opponent, called yomi. Check out David Sirlin's excellent article for an explanation of the layers of yomi in mindgames. The basic idea is that you have a certain set of moves, some of which can be used to counter others. Some provide a greater reward (more damage, a stun, etc.) but at higher risk. Some are lower reward but also lower risk (low damage, shielding, etc.) Effectively mindgaming your opponent relies on knowing what your opponent thinks you will do, and playing off those expectations. A noob will try to use his most powerful move at all times if he knows how good it is, but this move is risky, so a pro will know that and counter it. But if a pro is playing another pro, he might also use the powerful move, precisely because the other player wouldn't expect him to since it's typically too risky.
Sirlin's game Kongai did an excellent job of bringing these mindgames to a wider audience by removing the need for the millisecond reflexes that pro fighting game players must have, following in the vein of stuff like the battle game from Pokemon.
Nidhogg has accomplished something fantastic, in that it retains the real-time thrill of a classic fighting game, but provides a relatively small amount of actions that the player can take, which makes the game easier to pick up and play for the average gamer without having to learn a bunch of different combos for each character. However, the design is elegant, as these moves are more than enough to create interesting mindgames.
Tee is a wonderful but often-overlooked core utility. It's purpose is to intercept a pipeline, write the output to a file, and pass the output along the pipe. It can be used to easily add output logging to any command pipeline or script.
To get the most out of tee, it pays to read up on how input, output, and errors are handled by the shell. (As a byproduct, a good understanding of bash I/O redirection will make you a more efficient bash user and scripter!)
There are three standard streams that can be used by any unix program: stdin, stdout, and stderr. Each of these can be thought of as a file. By default, all unix programs read from stdin, write normal output to stdout, and write error messages to stderr. The shell's job is to take things being read or written to one of the standard streams and redirect them through pipes that you specify. By default, the shell will take the characters you type into the terminal while a program is running and pass them to that program's stdin. It will take the characters written by the program to stderr and stdout and print them to your terminal.
If you instead insert a pipe, like so:
command1 | command2
the shell will redirect the characters written to command1's stdout to command2's stdin via a pipe. Command1's stderr will still get written to your terminal.
Bash has syntax for specifying custom redirections. For instance, you can redirect stdout to a file instead of your terminal:
command1 > file
This is where tee comes in. If we want to both log something to a file and pass it along a pipe, or just have it written to the terminal (by leaving tee as the last command in the pipe,) we can insert tee into our pipe:
command1 | tee file | command2
If you want to do something other than use tee to log just stdout, you should read more about bash I/O redirection. Here are some resources:
Today, I would like to highlight the usefulness of the file utility. It is a command-line utility that is common on Unix systems. File will take one or more files and try to determine what type of file they are by examining their contents. It's the most accurate general-purpose tool of its type that I have used. It can be very helpful in identifying file types when there is no extension in the file name. Since it works off of the file contents rather than just the extension, file can tell you, for instance, that the a file called "picture.jpg" is actually a PNG with an incorrect file extension.