Full Circuit v1.1 is Out! (And now far easier)

Full Circuit, my Ludum Dare 23 entry, was a polished but incredibly difficult take on Sokoban that introduced some elements relating to circuitry. I have added a checkpoint system in the latest version, that, while maybe cheaply produced, makes the game significantly less frustrating.

Check out version 1.1 at http://www.indiedb.com/games/full-circuit.

A Crusade Against the Arbitrary

I have reached the point in the development of my Pac-Man clone where all of the fundamental game play and meta stuff is implemented and working just swell. Basically, from here I expect that I can just create a huge load of content, implementing additional mechanics as needed, and then, once the game is "playable" from beginning to end, and all of the major issues have been ironed out, I can proceed to add a thin, shiny layer of polish. This is basically the approach I applied to my previous two games, minus the polishing stage, which was substituted with me trying to make sure the first pass on each element was, well, good enough. Such is the case in hyper accelerated game development processes. However, will this work for a large project such as The Pac-Man? I am interested to see.

A problem of entering into the content creation stage is the delicious temptation of creating "cheap" experiences. Or, experiences that provide no growth for the player, present no new ideas, are usually quite "grindy" in an attempt to artificially extend the life of the game, and contain no opportunities for the player to enter to mystical flow state. How are these created?

Creating levels for Pac-Man at first might seem like an incredibly easy job. The designer needs to draw a maze, of whatever shape, and then add in pellets, power pellets, ghosts, and Pac-Man. After this, the work is done; congratulations, you just created a Pac-Man fan game with over +200 levels. Put that on the back of the box (shoddy website).

Except, the experience will be terrible.

In the original Pac-Man arcade game the player had to play through the same maze over and over, to the point that the layout of that is burned into the minds of millions under the fever. Shouldn't a large variety of maze setups provide a better, more surprising experience? In a sense, there is an element of surprise and anticipation of the next maze, but when each maze is essentially the same in nature, except arbitrarily rearranged, these positive attributes quickly fall it despair and death. Haha, alteration is great.

The original Pac-Man maze is designed. It is the perfect size to allow for just enough space between Pac-Man and the ghosts for tension but not frustration. Regarding the ghosts themselves, their artificial intelligence is very carefully designed to take full advantage of that maze, with different sections showing off multiple types of enemy behavior. The symmetry of the maze adds a sense of order and duality, and the placement of the four power pellets makes absolutely certain that they can not be abused. As I mentioned earlier, it is very iconic for an entire generation of gamers, and rightfully so.

Anyways, I have been having to avoid the urges to just simply draw a bunch of randomly conjured mazes, decorate them a bit, and call it good. The option seems so easy to embrace, but it is also ultimately unsatisfying. With the different way that I am handling the enemy AI in this project as opposed to the original it is cloning, each stage can be designed around the wills of a variety of enemies. The goal is to maintain that balance between creating a challenging, engaging experience, but not a frustrating or dull one, which arbitrary level design seems to always lead to.

One last note on arbitrary level design more generally applied to other games. In the past two years, thanks to the success of the indie title Minecraft, it seems that developers have become far more willing and inspired to implement procedurally generated content. There are obviously games that handle this concept better than others, but I think there is a very clear difference in the quality of the experience had in a procedurally generated level design compared to a human crafted level design. Just contrast the experiences had in the dungeons of the Zelda series to those of any game that procedurally creates dungeon. Yes, it is Zelda, but Zelda does design better than almost anything else on the market, and the reputation of the franchise is a testament to that (regardless of fan's feelings on some of the more recent entries, the games still have that designed quality). Even games like Skyrim, whose dungeons are not random generated, but abundant and extremely similar, face this problem. Once the player has entered one dungeon in Skyrim, they have basically seen them all; the only differences are in layout, element arrangement, and story notes that are more often than not completely meaningless or ineffective at providing a constant stream of interesting content.

Since this post is at the breaking point of dissolving into a rant, I will stop here.

Rule #1 of Video Game Design...

...every single game IS REQUIRED to begin with a happy, breezy, carefree grassland stage, NO MATTER what. Amen.

Download Full Circuit from the Ludum Dare Website...

...if you dare!

Ludum Dare 23 Entry Full Circuit

A Postmortem for Ludum Dare 23 Entry Full Circuit

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.

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 8x8 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.

Ludum Dare #23 and Oh Boy, I Have a Twitter!

This weekend I am going to be competing in Ludum Dare #23, which will hopefully turn out to be a productive experience. I am going to be lost in the depths of development, so I will not be posting updates on the game I am making. Rather, I am going to put together a postmortem once all is said and done.

Also, take a look, I am now on Twitter, @JMRante.

Time to die...

I Am Working on a Pac-Man Fangame and I Feel No Shame

Currently though, the ghost A.I. is incredibly difficult to get right. At the moment, programming A.I. is one of my weak points and hopefully this project will help me gain a better grasp of how to deal with such.

I am still under the curse of senioritis, so I am unable to write further about the development of this project. I leave with a screenshot of the current build: