Ludum Dare is over, and my entry, Symptomatic, can be viewed here. (If you want to judge the entry on the Ludum Dare site, you can find it here.) The non-competition jammers are probably wrapping up their 72-hour game jam entries as I type, but having done the 48-hour competition, I’ve had the luxury of relaxing for a full 24 hour already. Time to look back and reflect.
For getting this done in 48 hours, I’m reasonably pleased with myself. I had a hard time properly assessing my pace, since I’m so used to measuring things in days and weeks, not hours. 24 hours into the competition, I had only just implemented basic user interactivity, and still didn’t have anything like a proper game available anywhere other than in my head. That concerned me, since I was wanting to use Sunday for polish. But if I didn’t even have a complete game, what good is polish?
I did manage to get something slightly playable before I went to bed Saturday night. In fact, I spent about an hour “play testing” it, not realizing that a full hour had passed. Essentially, I had gotten the toy implemented enough to try playing with it, and the evidence from my sample size of one suggested that there was some fun to be had here.
I quickly got the full range of proper game play implemented Sunday morning (starting a new game, winning, seeing progress, et cetera), which allowed me to move on to things that ordinarily I would not call polish, but for a gamejam, definitely feel like a bonus. The most notable of these were simple manual, animations, sound effects, and a couple of interface enhancements involving paths.
In the end, however, I suspect that any fun inherent in the core is hard to find, because the mechanics of the game are not readily apparent to the player. One has to conceptualize a lot. For me that was easy because I designed the mechanics. But for an ordinary player, it’s not at all clear why things pop up in the location that they do. Granted, that’s kind of the whole point of the game, to not immediately know why, but to puzzle it out through logic and experiment. But when your game’s core concept inherently makes your game hard to comprehend, well, um, that sucks. Because of this, I could not visibly indicate where the pathogen or the symptoms were moving; that would give away the answer. But by not doing so, it becomes massively more difficult for a player to realize what is happening.
Part of my inspiration for this game was Minesweeper, so I contemplated why it was that Minesweeper manage to be simple to comprehend, despite similarly hiding information from the player. I realized that Minesweeper makes it really painfully easy to lose when you don’t know what’s going on. The result? The player sees all of the mines, all of the possible hints, and where they went wrong. It doesn’t take too many losses before you start to comprehend what’s going on at least on a basic level.
For my game however? You can’t lose. Ever. The only way to actually see the correct paths, where your guesses were correct, and where they were wrong, is by winning. And if you don’t understand very well how the game works, winning is really hard. The lesson? Give the player a way to fail, and enable that failure to teach the player something.
Will I come back to this game? I’m not sure; it’s not exactly the kind of project I get excited about. It could work well on mobile, especially tablets, but I have little interest or skill in mobile game development right now. And whatever nugget of fun exists, there’s a lot of work to figure out how to restructure the mechanics to make that fun excel. I did have lots of ideas during the jam that I had to shelve due to time constraints. That’s always a regret with tough deadlines (though it’s good practice too). Some of the ideas were simply additions or small tweaks to try to make the game more comprehensible. Some of them are radically different ways of using the hidden paths concept. Some came from Friday night before I had even landed on the idea of using hidden paths.
Come to think of it, Friday night was really fun. I might in fact try to carve out time in the future to simply brainstorm for its own sake. That’s one of the biggest benefits of game jams for designers, I think. That, and getting to evaluate your designs after you’ve got them functioning. But everything in between is just a high stress slog, it seems. I rarely learn much on a technical level simply because I don’t have the time to do so. Instead I use what I know, what works, and cut corners everywhere. Perhaps sometimes I’ll run across ways to cut corners that don’t actually harm the code quality, leading to efficient architectures and patterns that I can use in the future, but for the most part, I don’t want anything I write during a jam to make its way into production code.
Anyway, it was overall another good experience. That’s two game jams down, and two playable games complete. I’ll look forward to and fear Ludum Dare #30. This last time I seemed to manage my stress better than with Ludum Dare #28; perhaps #30 will be a walk in the park. Until then, it’s back to working on my city builder project!
As a bonus, here are a bunch of white board images from during the jam, in which I brainstorm, fiddle with old fashioned geometry, get confused about hex cell indexing, and switch to a to-do list mindset to wrap up on time: