LD25 Postmortem

Posted by (twitter: @MikeRedhorse)
December 19th, 2012 6:42 am

Now that it’s all over, and comments are still rolling in, it’s time to figure out what went right, what went wrong, and just what I’d change. All of these things are things I will change for this coming year, and my New Years’ resolution, One Game a Month. They’re basically the things I will focus on, one or two at a time with each game. As my LD24 resolution was ‘Next time, I need to focus on making a fun game, and one that works from a technical standpoint.’, this resolution will be longer, and aimed at making me a better game developer overall, rather than just a better game jammer. This’ll be a bit of a long post.

What went right:

  • The idea(s): I managed to come up with a simple idea for each theme in the final round of voting. I didn’t stop there. When it was announced, I forced myself to come up with another two ideas I liked. The first was an Evil Genius-like game, which basically everyone came up with. The second was so unmemorable, I’ve already forgotten it. Out of the three, I decided the early one and the first one were the two I liked best. Out of those two, I went with my keyword: “Antibition”. Rather than go with the ambitious dungeon-building game that involved lots of mechanics and was considerably more impressive, I decided to go with the simpler idea, but polish it a lot more. The choice was a good one, after seeing how many people came up with dungeon-building games, and how few people came up with railroad-type games (one, that I’ve seen)
  • The tools: Starting out, I decided that I would have to choose between C++/SFML, the hard option, and Python/Pygame, the familiar option. ‘Hard’ in the sense that I was unfamiliar enough with the library that I wasn’t confident I could make a full game, even if I could make a tech demo. If I hadn’t felt confident I could at least make a tech demo showing off the mechanics (but not including any user friendly interface, animations, etc), I would have chosen the familiar option and researched SFML more before next time. C++/SFML was immensely more powerful than Python/Pygame, less problematic, and a lot more easily packaged.
  • The progression: My initial milestone was making a working representation of a railway system, with junctions, with no train. The second milestone was getting junctions (or actually, any tile) to have a mode, which toggles the direction of travel when coming from the right direction. The third milestone was representing a train that exists on rails and moves in a pixel-based fashion (this failed, and was replaced by..). The fourth milestone was getting a node-based graph back-end to the railway, created when the level is initialised, and on which the train exists. The fifth milestone was getting the train to respect junction modes, and to have a variable speed. The sixth milestone was being able to toggle junctions (by mouse callback, which then calls an internal function that the AI also calls when changing junctions). The seventh milestone was allowing the AI to turn you around, and adding cooldowns for all these abilities. The eighth milestone was getting the cooldowns represented onscreen as the HUD, as well as the current speed. The ninth milestone was getting a working menu system to choose between two levels. The tenth milestone was getting an instructions menu. Those I had established beforehand. Once those finished, it was all polish, reworking graphics, failing to add audio, etc.
  • The updates: In case you were reading my site, you might have noticed what were basically hourly updates on what I’ve been doing, following all those previous milestones. These were a bit of a nuisance for a particular roguelike news aggregator picking up a dozen updates in a day, but were useful both for me and for people to see my progress in somewhat real-time. Next time, I might attempt a livestream, or, if not possible, a timelapse. At the same time, I’ll attempt to be more active in IRC next time.
  • The endpoint: Finally, I called it quits when I should have. Finishing the core gameplay and milestones less than a day in, I didn’t decide I should give in to feature-creep and keep adding mechanics I wasn’t sure about before. That, most likely, would have had me at less than five hours left with no polish and half the mechanics broken and unbalanced.

What went wrong:

  • The graphics: I’ve mentioned I’m not fond of the graphics in it. The animations are horribly choppy, and the train is a classic example of programmer art. I’ve never been properly artistic, or at least artistically creative, and I feel this shows in the way I tackle graphics in most projects. I’m capable of producing half-decent art for things like backgrounds, terrain, mechanisms, etc, but I’m really bad at detailing them properly, animating them fluidly. This is something I know I can improve, and I will improve, however my resolution for this is another. I will attempt to collaborate with artists more, for game jams especially. Not having to deal with the graphics would basically free up half of my core development time to spend on gameplay, and almost all of my polish time to spend on bugs, balancing and interface work. Speaking of..
  • The interface: This is basically a remnant of my progression as a programmer. I started out with Visual Basic when I was very young, which is fine, but it was way over my head at that point. Followed that up with Pascal, but stayed well away from any of the graphics bits in it, and worked solely with text/file input/output. Veered into C/C++ at one point, steering straight into user interfaces and OpenGL, and gave it up when it turned out they were difficult. Moved through various languages, always managed to stay with text-based interfaces, attempting tutorials on graphics-work every so often and giving up once the projects got big enough to be useful. Settled on Python for a long while, and after a long time, decided to turn my roguelike work into simple graphics. Gave it up once again. This year, I finally decided to stop being a baby and tackle graphics properly. In the month or so I worked with OpenGL, I managed to get to a point where I’m no longer scared or confused regarding graphics, 2D or 3D. In fact, I’ve even got 2D perfectly under control now. However, my interface work is still horrible. By which I mean, menus, widgets of any description, buttons, windowing systems, etc. Sure, there’s GUI libraries out there, but I need to go an use them. My resolution is to make a game with a proper windowing system, and an interface that works, feels nice to use and has no bugs.
  • The audio: Something I wasn’t happy with was the lack of audio in the game. This was because of two major reasons. My electric guitar and preamp decided that they should be noisy as all hell when plugged into my computer, to the point where I could not manage any sort of clean recording, and my dorm is also noisy as all hell, to the point where any attempts to record my acoustic guitar were foiled by people shouting, dancing, singing off-key and yelling at one another on the hallway just outside my door. There wasn’t any sort of clean recording in the whole two hours spent attempting to record. To that end, my resolution, which is unrelated to game development in itself, is to attempt to pick up a piezoelectric bridge for my acoustic to allow me to record on my acoustic properly.
  • The intuition: To start off, I know I’m not the most eloquent person. I definitely know I’m bad at explaining things as well. I also know that most things that seem intuitive to me are plain ass-backwards to most people. I’ve had this pointed out to me what feels like half my life so far, and accept it, while attempting to improve it. I already knew before-hand that I need to consider everything in my game as unintuitive as possible to most people and attempt to explain it as well as possible. I managed to fail to consider junctions as a potentially unintuitive element, and have also managed to fail to explain the AI’s abilities properly, or make intuitive enough that it requires no explanation. Out of the ten or so real live people I’ve had test my game (while of course offering no assistance or comment besides the ones given in game, translating for some) only two thought the junctions were intuitive, three spent over five minutes attempting to make a train turn in a junction in a way it isn’t possible for it to, eight didn’t understand how the cooldown meters for the player worked, and nine were annoyed when the second ability for the player showed up. Five of those nine considered it a bug, despite reading about it in the instructions. Out of the other four, three said it makes the game plain impossible, and refused to believe me when I demonstrated how to win, claiming I had changed it somehow since I was the developer. So, my resolution is to make mechanics as intuitive as possible, not only easily explained, but to require no explanation whatsoever.

That’s basically it. A long post, but I hope it provides some insight into the process of finishing a game jam, for me.


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]