It’s been two days since I submitted my entry to the Compo, and I wanted to take a look back at the good and the bad of the entry. Postmortems help me formalize my understanding and intuition on my projects, so I can more easily see what went right and wrong over the course of the event. Without further ado.
The Tools
In my “I’m In” post, I talked about wanting to try Unity2D this time around due to wanting some real experience with the engine prior to working with it on another project. While I had used LOVE for every entry prior to the first, I rarely ever kept anything from past projects, so using a framework like LOVE cut down on the actual game implementation quite a bit. Rather than working on my game, I had to first set up the foundation.
However, there was one little snag in my plan: I also wanted to stream the development. I felt that due to my inexperience with Unity, I wouldn’t provide anything exciting to see, as most of the time would be spent searching for answers to questions that even a novice Unity user would be able to answer. So, I went back to LOVE to both use something I am already familiar with and to provide an option for viewers to look at a framework that they may not have been aware of.
The Theme
Prior to the beginning of the event, I usually look at the final round and think of a few, simple, starter ideas for each theme. This helps kick start my creative juices and separates the themes that I’d like to do from the themes I wouldn’t. Connection Worlds was not a theme I was particularly excited about.
One thing that I believe makes a good theme is how agnostic it is. Something like Break the Rules or You Must Leave It Behind can apply to any setting, any genre, and nearly any game. It doesn’t coerce you toward a single path. Global Game Jam often provides good, ambiguous, agnostic themes that you can wrap your idea around, rather than the theme encompassing your idea.
A shorthand that I have for identifying good themes is how quickly you begin to think of ideas for it. The quicker the ideas come, the more the theme is pulling you in a direction. Connected Worlds pulls you heavily in the direction of “space,” and you have to fight to find your way out of that mindset.
The Game
After twisting myself away from the first idea I had (a Settlers of Catan-like board game, which would have either required multiplayer or decent AI to make interesting), I went with a Lost Viking style platformer called “A Galaxy United.”
You have three characters from three different planets orbiting a yellow sun: Foo, Bar, and Baz. Each character has a special trait that the others do not possess.
Foo is actually a much smaller alien that rides around in a tank like vehicle that he can deploy and retract into his pocket. This allows Foo to pass through small pockets that are too small for the others to squeeze through.
Bar is a world class boxer with a single floating fist that demolishes structures. He can break through obstacles that others can not avoid.
Baz is the most athletic of the group, and can use his spring to jump into the air. He crosses gaps that would be the death of anyone else in the solar system.
There are seven different levels in the game: one for each possible combination of characters. Each character has a solo level which acts as a tutorial for their ability; the level is usually extremely straightforward. Then, there are levels for each pair, and finally a level at the sun which requires all three characters.
The Good
love.physics
I had previously used supplementary user libraries like HardonCollider (no, I didn’t misspell that) or bump for collision detection, and then rolled my own simple physics, but I wanted to give the box2d implementation that LOVE comes packed with (love.physics) a shot, and for the most part, everything went extremely smoothly. I didn’t have many issues with getting simple platformer controls in place, and had much more flexibility in creating what I needed for individual objects on the screen. One particularly good part was combining Tiled’s Object Layer with defining the solid ground my players would be on. I could simply build my level with my tiles (of any shape and size), and then define a polyline in the object layer that traced the edge of the world. Then using box2d’s chain shape, I simply create physics objects that follow the polyline. Before, I was often either having to create large, conditional logic functions for particular tiles with abnormal shapes, and had to try and programmatically construct a complex definition of the “solid ground.”
Metadata
I decided to formalize a Lua metadata file for each piece of art I used, regardless of whether it was an actual spritesheet or not. This allowed me to be much more generic in my classes, since I didn’t need to hard code in the quads or animation definitions. Each metadata file had the path to the image, width and height for the physics object, quad bounding box definitions (Quad being the LOVE term for individual subsections of an image, like the frames of a spritesheet), and animation definitions (which references the indexes of the quads for easy reuse).
Art
I am absolutely not an artist. I can get by if I take a long time to craft an image, but it usually doesn’t turn out well. This time, however, I was determined to try and implement some character art. Since the game revolves around using special powers for specific characters, I needed at least some distinguishable models for each character. I also wanted to try and implement some animations as well, because there is nothing worse than a single frame just moving statically across a screen. I started out with much more complex models, but quickly realized that the more complex the model, the more fluid the animation would need to be to avoid being stilted and jerky. So after a few aborted attempts, I ended up with the models present in the game, which all have a nice charm to them.
Streaming
Streaming probably saved my game. At one point, with around 10 hours left, I was extremely dissatisfied with the game. I already had my MVP (minimum viable product), but I just wasn’t invested in improving it. However, I had made a promise to stream the development, and felt that I would be abandoning the people who might have been enjoying my work, regardless of my personal feelings on it. Streaming, and the obligation to stream, kept me from pulling out. Beyond that single instance, streaming meant providing entertainment for an audience, which reduced the amount of time I spent screwing off. Given how well streaming kept me focused, I might do it more outside of Ludum Dare for game development.
The Bad
Polish
One thing I have found throughout my many Ludum Dare’s is that the more polished a game is, the better reception is receives. It doesn’t really matter if it is the simplest game or the most complex; the more bells, whistles, and polish a game has, the easier it is to look over other issues. My game has very little polish. It has only two states: level select, which is a static screen with the different levels visible, and the game state. If your character falls into oblivion, you have to restart the executable. There is no sound; all the art besides the characters is extremely bland. There is no explanation of controls, no options menu, nothing that a highly polished game would have. There are probably plenty of bugs that I wasn’t able to squash.
A lot of my issues with polish have to do with my choice of LOVE as a development tool, By using a framework, I have to spend far more time creating the engine and then my game using the engine, meaning less time for art, sound, and debugging. That was part of the reason I considered Unity this time. I always plan on creating something simple and then spending the last 16-18 hours just polishing what I have, but it never ends up that way. I usually have only 6-8 hours for all the art, sound, and bugs, so I am super rushed at the end to cram it all in.
Fixes
I say this nearly every Ludum Dare, but I need to make simpler games. Even “simple” games end up being complex, so I shouldn’t worry about whether my entry will be complex enough, because adding addition complexity in the programming seems to increase time spent exponentially.
Currently, I am fairly rusty on game development practices, and as such, need more time to remember the best ways to implement things. I should code more often to stay fresh.
Use more libraries, whether self-built or from users. I have a tendency to want to do everything myself, but that just wastes a lot of time when it is something that doesn’t really require custom logic.
Conclusion
