I originally posted this on April 9, 2013 on my blog on Gamasutra. Cross-posting here, as I should have done before.
I first learned of Ludum Dare last August. I wasn’t in time to participate, but I was able to play a wide variety of interesting games. That got me fired up — I definitely wanted to participate in December’s 48-hour compo (hereafter LD48). I hadn’t programmed in years, really, but I was signed up for an Intro to Computer Science MOOC and was pretty sure I would be capable of pumping out something come December.
Participating in Ludum Dare #25
When December and its LD48 came around, I was not at all confident in my abilities. I had successfully brushed up on basic computer science concepts and learned some new things, but the MOOC had been taught in Python instead of the C/C++ I originally learned in. I could do some things with Python, like perform computations and output things to IDLE, but I had no clue how to do things like play sound and draw graphics. To make things worse, I live in Japan, which meant that the event would be starting at noon on Saturday for me. In order to be functional for work on Monday, I needed to get to bed around midnight on Sunday, leaving me with only 36 hours to make my game. In short, my limitations were many.
I did not, however, allow that to stop me from participating (succesfully). I spent the first hour of LD48 pondering design options. I could make a plain ol’ text adventure, but that felt more like a writing exercise than a game. I didn’t want to come up with something that required graphics and/or sound, because I’d be in trouble if I couldn’t implement them in time. I sought a solution which would hopefully be unique, but which (most importantly) could be implemented with a text interface and made graphical later if I had time.
It didn’t take me long to decide on making a simulation game. I made this decision with no small amount of ruefullness. What was I thinking? I was going to make a bloody simulation game in 36 hours, by myself, and with no time to test balance?!
The thing is… yes, it’s a simulation game, but the nature of the game and the story I wanted to tell with it didn’t require a particularly complex simulation. Nor did it require saving the results of the simulation segments — in fact, all simulation results are thrown away. Hell, it didn’t even matter, for the sake of the story, that the player do a good job. It was vital to the story that the gameplay exist and that the player be engaged in the simulation segments, but the simulation’s flaws and lack of fine details do not in any way detract from the whole.
Even though I had to rush to finish writing the story in time, I was satisfied with the game I made. The theme was “You Are the Villain”, and although a player must play through to the end to see how the game connects to the theme, the game fits the theme quite well. That, combined with the fact that it looked at first glance like Just Another Text Adventure, meant that not everyone gave it full consideration. However, the feedback I got from those who did was very heartening. All in all, I felt like the story, the gameplay, and their interconnection delivered what I intended and the game was well-received. Out of something like 900 entries, I placed 34th for Mood, 101st for Theme, and 115th Overall. The real surprise for me was that I ranked 119th in the Humor category. I wasn’t really going for a funny game — indeed, the overall message was dark and dystopian. In general, the responses I got reinforced the satisfaction I already had with my LD48 entry, Decommissioner.
Learning About Programming
Designing a game from the ground up by myself in such a short time frame was… an interesting experience. I learned a lot. But I also knew that I wasn’t crafting elegant code. My code was limping around on a crutch because one leg was tangled up in the far-too-voluminous sleeve of its other arm. It was akward, it was clunky, and it was dressed very, very badly.
But I really like this game concept, I thought. I want to see how far I can take it. It really deserves to be treated better. And so I embarked on a quest to clean up the code and make the game more extensible. Over the past few months I’ve worked on improving it here and there, but various things kept me from devoting a great deal of attention to it until a week or so ago, after I started buckling down on learning pyglet for this month’s LD48.
Ironically, I still haven’t made any changes to the game involving graphics or sound.
The pyglet tutorial I’m using takes the reader through the process of creating an Asteroids clone from scratch. It starts with zero files and, using good coding and Python module conventions, ends with a lot more than zero user-created files. The tutorial carefully explains when to create new files, where to put them, and into which file each snippet of code goes.
Now, I’m a fast reader. I achieve this partly through fast processing, but partly through skimming and skipping parts. Learning to skim articles is a skill any whipper-snapper raised with the internet picks up, I think. In this case, however, that has been the opposite of helpful. At first I skim-a-dee-doo-dah’d down the page, missing some key instructions and finding myself with code that was hangy like a game of hangman two eyelashes away from doom.
At first I arrogantly assumed that there was something wrong with pyglet — I’m using a 64-bit Mac OSX installation to do my programming, which means using the alpha build. The things I hadn’t missed in the tutorial gave me enough information about how modules are built to start fiddling with the pyglet files, looking for the particular classes and functions I was using to see if I could find any errors in the code. Errors I did not find, but in looking for them, I started to better understand the nature of modules and gradually came to the realization that I must have missed something in the tutorial instructions.
Sure enough, I had — and when I went back and reread the tutorial more carefully, everything worked just fine. I started to advance through the tutorial again, but it wasn’t long before I stopped playing with the pyglet-based Asteroids clone and started applying what I had learned about module composition to Decommissioner. Over the past few days, most of my .py files have been moved into folders and divided into smaller files so that I can avoid importing more than I need. Subsequently, my import statements are a lot cleaner across the board. You wanna know what the best part is, though? It’s that my game’s directory looks like a program directory!
You can see the difference between the original and post-LD improvement branches on my GitHub account.
Why This is Important
I started college as a Computer Science major, intending to be a game programmer for a living. For reasons that, in hindsight, were very silly I switched to being a Japanese Studies major during my second year. While I don’t at all lament the time I spent getting my bachelor’s degree or the things I’ve done with it since, I’m looking forward to returning to North America and making games for a living.
To that end, I find myself needing to relearn everything I knew about programming and learn all the things I didn’t learn in the first place. Rather than try to explain the things I don’t know or don’t think I know or didn’t know and do know now or whatever, I’d just like to talk about Asteroids clones.
The asteroids clone on which I am working now is merely a tool for learning how to make pyglet work. It covers a variety of things any game developer might want to do with pyglet: make images and text display; make things move; make static and moving objects display at the same time; add player controls; etcetera, etcetera. Furthermore, since Asteroids is a simple and classic arcade game which a student can easily learn about if they aren’t already familiar with it, students can easily tell without help if the game is doing something it shouldn’t be doing. As a teaching tool, it hits everything the tutorial needs and is easy to diagnose.
This is exactly why we used it in my computer graphics class back in college. Different language, different syntax, but we used the same game for the same reasons. Speaking as a teacher (albeit of a far different subject), I can now appreciate the value of such a tool.
During that college class, however, I was just… uninspired. Uninterested. My classmates really got into it. They came up with some impressive Asteroids clones, with rule variations and nice graphics. Mine was just kinda… meh. I’ve never done well with cookie-cutter art projects. Making the same thing as everyone else is boring.
But here and now, this pyglet Asteroids clone has caught my attention. There are two reasons for this. One is the reason why I started doing it in the first place: I want to be able to use pyglet for LD48 #26, and this tutorial is a means to that end. The second reason is that every non-pyglet-specific thing I learn is something I can immediately consider applying to Decommissioner, about which I care a great deal. I therefore have internal motivation to work on this Asteroids clone and — more importantly — to eke out of it all the learning about Python and Pyglet I can find.
I’m having a blast right now, working on these projects and getting ready for the next LD48. What saddens me is realizing that my computer science classes would have been far better with more open-ended projects than clones of preexisting games.