Hidden Homework (updated 2019)
Every year I run a prototyping class at NYU, where students make a new game every week, starting with a prompt or constraint that I give them. It’s become a tradition for me to hide one of their prompts inside a small, prototype-scaled game. Ostensibly it’s to give them some inspiration and benchmark the right amount of work for a 1-week prototype, but really it’s just fun for me to design a game which people will be forced to play to the end. It’s an unusual reward structure to work with: if you beat the game, your reward is homework!
For me, a good prototype expresses a single idea or tests a single hypothesis, so a prototype is actually a great container for a creative prompt, which typically takes the form of a single encapsulated concept or provocation.
I’ve done this for
four five years now, so I figured I’d do a little round-up. (Updated for 2019)
For 2019 I ran two prototyping classes – one in Pico-8 for the undergraduates and a graduate version with no platform constraint (which generally means they work in Unity). So this year I hid the same prompt in two different interpretations of the same idea. I tuned the Pico-8 game for the youthful reflexes of the undergraduate class, but I did not count on the fact that none of them would have ever played a bullet-hell game, and as a result, only one of them was able to reach the end and find out what the assignment was. I instructed that person that they could keep it a secret if they wanted to.
This is 2018’s assignment, a diabolical puzzle. You’re a monk who has forgotten where his cell is in the monastery, and who must walk the labyrinth in order to remember it. If you can find his room, you’ll find out what the assignment prompt is. I was a bit worried the students would be unable to find the prompt hidden in this one, but about half of them got there eventually. (The rest were expelled from the university.)
2018’s class was 100% Pico-8 so it seemed appropriate that the prompt game should be in Pico-8 too. Pico-8 is so great for prototyping — as a case in point, it builds to a single JS and HTML file which loads quite happily in the browser from a local file, so you don’t get annoying permissions or crossdomain problems.
For 2017 I made Last Word, a little action word game where the difficulty increases as your words get longer. There’s a proper videogame version (with no prompt hidden inside it) here. Made in Terry’s Haxegon engine, a nice ultra-minimal Haxe library which is perfect for small prototypes. I love using engines that build to the web as well as native targets – makes it very easy to share prototypes without asking the player to do anything more annoying than play the actual game (which might already be quite annoying, honestly).
In 2016 I got interested in optical illusions and op-art, and I made Zebra, an optical maze. Mazes are not the most interesting gameplay element if you’re relying on intrinsic motivation — they’re just not very entertaining — but if there’s some sufficiently compelling extrinsic motivator I think their irritating properties become quite interesting. Made in Unity, which is pretty great for making 3D prototypes.
2015 was the first year I made one of these prompts, at Doug Wilson’s suggestion. The game is a simple physics game, a reinterpretation of the speed-skating from Epyx’s C64 classic Winter Games. Downward pressure from the skates on the ice is converted into forward momentum, which would be easy enough were it not for the hazards of the ice rink.
Made in the old version of Sven Bergstrom’s Luxe, which used to be a rather lovely Haxe library and is now on the way to becoming a rather lovely Wren library. I don’t mind either way; I’m not a good enough programmer to have opinions about languages. Whatever library or language I use, it seems to lend its own flavor to the work you make with it. I don’t want a single tool that I can use for any game… I want a digital toolshed that looks like Depeche Mode’s synth collection.