Last week, I participated in Mini Ludume Dare 53. A mini Ludum Dare is a much more relaxed version of the full version, and it usually has some specialized rules. The number of entrants are usually much reduced (this one spawned 63 entries). In the case of Mini Ludum Dare 53, the rules were quite the same as a regular Ludum Dare (make a game in 48 hours with readily available tools). I chose to participate in the mini LD mostly because I’m moving next month right after the full Ludum Dare event, and I wouldn’t have the time to participate then.
For this mini LD, I made a game called Trash: A Story of Uncertainty [download link]. What follows is my postmortem, a look at how I made the game and what I was trying to portray with the game. As with all of my postmortems, if you haven’t played the game, then reading further will completely spoil everything that the game offers, so if you haven’t played the game, read on at your own risk.
The theme for the mini LD was “The Future is Now” and I wanted to capture that in two ways. The obvious way, which was how most people tackled it, was having something from the future affect the present. The second way was more metaphorical, and it dealt with the concept of preparing for the future in some way.
The idea behind Trash was inspired by a few games. Most notably, I was inspired by my recent play through of Digital: A Love Story, a game by Christine Love about hacking, the internet culture of the early 80s, and the scare of the spread of autonomous computers (e.g., HAL of 2001: A Space Odyssey, and Skynet of The Terminator). Another similar game I played so long ago that I can’t remember the name (and my efforts to find it are turning up nothing), but it was another game that simulated a computer like Digital: A Love Story. With these influences, I was determined to make a computer simulation where a person from the future makes contact and adds to ongoing pressure. Due to my background, I thought it would be easy to make a simulation of a graduate student up against very pressing deadlines regarding papers that need to be written. During the course of the game, an unknown entity would cause problems with the papers, and generate more pressure and panic. To save myself some trouble, I wanted to make sure I was simulating a very simple version of a computer. Overall, I am pleased with how it turned out. What follows is my design process.
I started, strangely, by gathering music from Freesound. I wanted to find some good classical music to play to “encourage” work during the game. This was the backbone behind the computer simulation. I envisioned the computer having a simple operating system that was extremely intrusive and idealistic about what a good work environment is.
After that, I basically just started brainstorming while making the basic art assets for the operating system (backgrounds, buttons, text fields, etc.). While I was working on this, I decided that the best way to simulate what I wanted to portray, the most important applications to simulate would be email and a word processor. At this point, the game was actually called To Do, and the imagery of the sticky note on the title was supposed to support this idea. The basic workflow for the game was imagined to be: use a program, get a task, complete tasks, get more tasks, repeat. Then somewhere along the way, disrupt the cycle. With this in mind, I started making various icons for the desktop scene.
The word processor (or WordPro as it’s referenced in the code) came first, then email, and as I made them I came up with the idea of other common software that would be on this kind of workstation. I came up with the internet and the trash bin first, thinking that the first could be an extremely limited version of the internet, and the second would make for some interesting interaction later in the story. I basically thought up the first major event in the game as I was making the trash icon; at some point, one of the documents would be inexplicably thrown in the trash and need to be recovered.
Once I finished with those icons, and an icon for music, I realized I would need three more applications to fill up a second column and also icons for the documents. I made up the idea of the library, settings and file system application as a way to get things moving, and just figured that the player would be locked out of the latter two. The making of the icons and laying them out was helpful to the design process. They were simple things that I could make, and while making them, I could think of how the applications might be implemented in the game. Laying them out also helped to notice where I would need more applications for the game, and pushed me to make a decision about what would be on the desktop.
After I made all the icons, I did the preliminary work of coding up the desktop and title screen in Game Maker, making art as needed. Early on, I was going to make all the text be images, but very shortly I decided this was a silly idea, and so the text on the title screen looks a lot different from the text in the game. I also took this time to code in what I thought was the easiest of the applications, the “music” application, so that I could use the music I found at the beginning. This took some trial and error, and the music application still behaves really badly, but it was easy to code once the design was in place (I eventually made a music controller singleton object that persisted through room changes). If I had had time at the end of the mini LD, I probably would have torn the whole music application down and recoded it, considering how the rest of the game was structured.
It was about this time that I decided that the way the word processor application would work was to have the player “type” parts of essays. I resolved myself to use real essays, just something I had on hand at the time. Both essays are real essays that I turned in and used for the same purposes as they are outlined in the game. The problem with that was that I needed a proper text box tool. Game Maker’s draw_text is pretty powerful, but it has some quirks that I didn’t want to deal with. So, I ran to the Game Maker extension forums and searched around for a text box extension that someone had written. I ended up with Dave Norgren’s Textbox scripts, which seemed to be a robust, studio compatible textbox script. I knew that I was still going to have to manipulate it, but it would work.
I spent about an hour looking for it, and then a half hour or so manipulating the example project that comes with the scripts to do what I wanted. Basically, how it works is that when the player presses a key, it adds a number of letters to the text box based on a slowly increasing buffer. In the release, the textbox takes four keystrokes before it starts adding another character per keystroke. It doesn’t matter what the player types, and it even works with keys like shift and backspace. The point wasn’t to get the player to write anything, but instead to simulate the act of writing. It starts out slow and then gains speed as you get into the swing of things. I ran into a problem with the code where it would slow down once the text was about two text-boxes long, since it re-makes the text every keypress. This led to the creation of the section buttons, to make sure that the textbox never had very much text as a goal. This also helped guide the structure of the game. All this came later, though, as I was not ready to actually implement the word processor application. I needed to know more about the game before I coded that in.
So, instead I worked on the email application. The email application was going to be the driving force behind a lot of the game’s events. I knew by this time that I wanted to have the future traveler communicate with the player using email, and that I wanted there to be emails that were framing the academic tasks. At this point, I wasn’t concerned with creating content. I didn’t write any of the emails, I just wrote the application. This led to the understanding that there would be only room for 16 emails, unless I wanted to make multiple pages, so this helped inform content creation later. The email system was rather easy to make, but I decided to cut corners and not make each email be individually tracked as being read or unread. I feel like doing so might have helped with some confusion I have witnessed in players.
After email, I coded in some of the easier systems. I blocked off the settings and the file system, with the idea that I would be making them later, and coded in the trash application, which would become the basis for the file system later. This was all procrastination, though. I was avoiding implementing the hardest system, the word processor. Still, before I was able to code in the word processor, I needed to know how the game was structured.
What ensued was a frantic ordering and reordering of events in three tables on my white board. I had two sets of events that ran alongside each other: the creation of the two documents and the struggles of Traveler to get free of the computer and return to the future. I wanted to ensure that Traveler affected the system slowly and logically, so I had to set up enough events. The general idea was that Traveler would try to contact first, then attempt to solve the problem, then try contact again, try to solve the problem again, and finally resign to the whims and needs of the computer’s user. This required a lot of events, and so the idea of writing a paper, getting feedback on it, and revising the paper came to mind, all this interspersed by a second paper that was also needing to be written. the result was a bunch of scribbles, but it at least made sense. There was an eventual problem with my handwriting where an event ended up being “do nothing” because it would have required rewriting more code than I had time for.
With this in mind, I set about writing the word processor application. This application was the most complicated because it was where almost everything happened. If the in-game day had an event for Traveler, then it would happen upon completing a section or closing and saving the word processor. It doesn’t work perfectly. It autosaves if you use the section buttons, but asks if you hit the exit button. During one event, when the file being worked on is put in the trash, regardless of where the document is saved, the current section will be completely erased, instead of being set back to the last saved position. The way I decided to track how far along the papers were and whatnot was really stupid (I had a sections finished variable for each paper, and a was storing globally how many characters the current section had on it, rather than tracking each section individually).
Even still, it works. You type frantically and words appear. If an event is supposed to happen, it happens. Progress on days where multiple sections are written are properly tracked on the to-do list on the desktop. It was easier to code than I had anticipated. More specifically, I got fewer bugs than I expected. This was probably due to constantly testing whenever I made any changes. I must have run the game a hundred or more times in that 48 hour period. A large portion of my final hours were testing and bug fixing.
I considered the worst of the coding behind me. The remaining systems (internet, library, settings and file system) all came together rather easily. I couldn’t think of a good way to do the research phase of the game, so I just made it very boring. Click on 50 randomly populating book and article resources for the proposal, and when you have 35 of them, you’re done. I think there’s probably still a bug in the system, too, but it got the job done. I hoped it would convey the act of sifting through every source until you find the one right for the project. Resource hunting can be very boring and draining at times.
The web application I eventually just made to be a chat room simulation, showing the only other contact from the outside world other than email. A conversation between four people would populate over the days, and the crucial puzzle key would be provided on just the right day. For settings, I just decided to ditch the idea of an actual settings application, and have it just accept codes to do particular functions (codes which would be conveniently handed out on the proper days). I’d wanted to do a more elaborate settings application, but many things I would want to put there (such as background color) just weren’t an option with the way the game was designed.
The last application I made was the file system, which bridged the gap between coding and content creation, since I had to make all the folders and files to populate the space. The file system application was designed as a kind of maze, so it needed a large number of folders and a bunch of decoy files. After the file system was finished, the main portion of the game was coded and all that was left was to code in how events progressed and then just make content.
The event progression was easy to code. It was more confusing to follow my notes. It was here that the extra event 8 that had nothing assigned to it on the Traveler side was discovered and this required some rewriting and shuffling of events to work out. I decided to make it so that progression only advanced when the player left the session, i.e., when the player logged off the computer. There is a lot of that going on. As a result, I had to do a very daunting task and ensure that the game could be saved and loaded. I went the easy way. The game saves off all the global variables into a file using the configuration file functions of Game Maker, which means that the saved games are all readable. Messing with the game saves can have very unexpected results, though, as a lot of the global variables are used to determine what event the player is currently in.
After that it was all content. I wrote all 18 emails of the game (16 normal emails, and two end-game emails) from 5 to 8 in the morning on the final day of the mini LD. I feel like they turned out alright, though I wrote them in notepad, so they probably have many typos. They’re emails, though, so that’s just fine. It really hurt to write some of those emails, a number of them would refer to the player’s “work” as junk and not worth anyone’s time. This was where the game’s title of Trash came about. The game starts off with the player’s committee chair telling them that the last draft they turned in was a complete failure and that the chair had thrown it in the trash. From this, and the fact that the game would only end when both documents were put in the trash bin and permanently deleted, the title of Trash seemed more appropriate than To Do. One particular email was so close to home, that I nearly teared up with writing it. Fortunately, I never had an experience like the one I portrayed in Trash, and I feel a lot of sympathy for those who have.
Once the emails were done, it was time to write the web chat and the rest was all just bug testing. I think this was also the time when I finally implemented the to-do sticky note on the desktop. It was one of the lowest on my priority list. I just had to make sure that the game worked, before anything. And it did. I really owe that to testing along the way.
And that’s the story of Trash: A Story of Uncertainty. This quick little game was made just under the deadline (and with only one sleep-deprived day), and I feel it captured the spirit of what I was trying to say with the game. If you play it, let me know what worked or didn’t work for you, I always appreciate feedback.