Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!

Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created.You NEED ratings to get a score at the end. Play and Rate games to help others find your game.We’ll be announcing Ludum Dare 36’s August date alongside the results.

New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.

Full Circuit, a game created within 48 hours for the game jam Ludum Dare, is a game about planetary voyaging, pseudo electrical circuits, and most importantly, brutal passive aggressive punishment. In the game, the character of Less Patters travels from planet to planet to restore electrical power by reconfiguring the broken circuits deep underneath the planets’ surfaces. The game is very similar to Sokoban, the Japanese crate pushing game. However, instead of having the final positions of the crates marked, the player must position the crates in such a way as to complete the circuit seen in the level. This adds another layer of puzzle to the original Sokoban mechanics.

As with any postmortem, I will be explaining what went right and what went wrong during the development process of Full Circuit.

Full Circuit actually exists for two purposes, both of which define its identity. The first purpose is to be a competitive Ludum Dare entry. The second purpose is to be a project for my high school Physics course. When the themes were being voted upon, I was desperately hoping that the result would enable me to effectively pursue both of these intentions. Thankfully, the final theme of “Tiny World” lent itself extremely well to my recent studies focusing around basic circuitry. With a theme and scientific topic in mind, I put myself to sleep with the intention of having a complete and reasonable game idea on the other side. And I did. Thus I decided to go ahead and combine the concepts of circuitry with the game mechanics of traditional Sokoban.

The first stage in Full Circuit.

During the whole entire duration of development I was able to keep myself motivated, which was a definitely welcome surprise. This was not the first time I had programmed a clone of Sokoban, so coding the initial game mechanics was not much of a challenge. I started with the player’s movement and collision code, and then threw in the player’s animations. The graphical style of the game was always intended to follow the 8×8 grid format in order to keep the art demands low and to make the game world look tiny to the player. The art style turned out fine, and while it inherently has no issues, it would latter affect the game for the worst. After adding in the code for crates and doing some initial sprite work for the objects I was expecting to add into the game, I had to face my first coding challenge during development. How do I simulate the wire that is connected to the two ends of a battery such that it will only recognize itself as being charged when both ends are connected in a circuit? This proved to be a tricky problem, and one that I was not able to full fix.

My first solution to simulating a circuit was to have each piece hold two Boolean variables, one that says the piece is connected, in some way, to the positive end of the battery, and the other dealing with the negative end. This method would actually work if the circuit was a static whole which could not change. However, in Full Circuit the player needs to be able to build parts of the circuit on their own, and so, the circuits in the game are not static but dynamic. Why did this method not work with dynamic circuits? While I could let each segment of the circuit know it was initially connected to a certain charge, I couldn’t figure out a way to let it know it was disconnected in a way that made sense regarding the limitations of Game Maker. After a break to attempt clear thinking on the subject, I finally came to another solution.

This second solution to coding dynamic circuits simulated individual charges moving along the wire as actual objects. There were blue, positive charges and red, negative charge that would travel through a wire and, if they reached a dead end, would be destroyed. How did this system allow me to know whether or not a part of the circuit had been disconnected from another? If a piece of wire was no longer connected to a source of positive charge, for example, no more positive charges would reach it, and thus, it would revert back to not having a positive charge once all of the charges it did have left. Unfortunately, because of the way this method worked, the charges would have to move through the wire at a far slower speed than desired. Whether or not this is an effective way to simulate the actual science of electromagnetism in circuits is definitely questionable. However, with some level design trickery, the original message of, “The lights come on only when the wire is connected to both the positive and the negative ends of the battery,” still holds.

After finishing the code for circuitry, the bulk of the programming work needed for the game was done. I added in at this point some of the fluff that I usually hate to do, such as the opening, title screen, and intermissions, to get them out of the way in order to completely focus on creating level content. My biggest mistake with making Full Circuit was to interpret the theme as requiring the game to take place on different planets, or “worlds.” This in turn led to me using an art style that demanded large, single screen stages, which would exist as large, one circuit systems. Rather, a game that took place on the small scale of actual circuits, with the player controlling a small creature with the intention of fixing people’s broken electronics, would have led to a premise that could present a far better gameplay experience.

All of the stages in Full Circuit are beyond brutal because of their layouts. Each level is one large puzzle that, if the player makes a tiny mistake, must be completely restarted. The initial solution to this problem is to add some checkpoint or saving system in to the game. Admittedly, this should have been done, since it isn’t too difficult to do with the kind of game Full Circuit is, but I did not have much experience with implementing these kinds of systems and chose to ignore them as potential solutions to the difficulty problem. Another, perhaps better solution, would, as I had stated earlier, be to choose a premise that led to inspiring me to create smaller, more traditional Sokoban levels that would be far more manageable to play through. Unfortunately, I was too fascinated with the idea of having one part of a level affect another because of their interconnection. My mind was also too polluted with the imagery of small, single screen planets due to following the development of several other Ludum Dare games to consider anything else outside of my initial premise as an option.

After building and testing the three stages of the game, I added some polish (such as the animations at the beginning and end of the levels) and faced my Achilles’ heel in regards to game development; sound design. Fortunately for me, both sfxr and Autotracker-Bu came to the rescue and produced, some, well, workable results for me to use. Both of these tools output lo-fi sounding audio that mixes very well together. The only regret I have regarding Full Circuit’s audio is that I did not decrease the size of the .wav music files.

For my first submission to Ludum Dare, I am proud of how Full Circuit turned out. However, from it I have learned that, as a game developer, I need to have empathy for the player and put them first, no matter what.

This entry was posted
on Saturday, April 28th, 2012 at 12:41 pm and is filed under LD #23.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.

One Response to “A Postmortem for Ludum Dare 23 Entry Full Circuit”

>However, from it I have learned that, as a game developer, I need to have empathy for the player and put them first, no matter what.

Hah, this sounds familiar. Often I’m happy with how my game turned out, but I get comments like “too hard”. After having immersed yourself in playtesting, it’s easy to ignore how a first-timer reacts to everything and might not understand something left unsaid about the game mechanics.