Introduction
The idea for Psychic Construction Company came from the basic premise “Use farseer to do something”. I like physics based games, such as Crayon Physics, and I feel that the genre hasn’t been fully explored yet. I thought about real-world physics based games, and the most prominent are things like Jenga, where you stack or unstack blocks, with balance and a steady hand determining who wins or loses. This led to the idea of a block stacking game. I wanted the block control to be a little imperfect, so that the player would have the risk fo knocking down their own structure if they weren’t careful; I came up with the idea of psychic characters as a way of explaining this.
What went right
- Development order
I had a very specific development order planned from the beginning, and I think it worked very well: first get single player gameplay working, including physics and controls. Then get multiplayer up, then do graphics and sound last. Having singleplayer up early gave me a lot of time to test and change the physics and the control system, which were the two most important parts of making the game feel right. Doing graphics late saved me from making graphics for things I didn’t need, such as different characters for the different player roles (which I ended up scrapping), different block tile sets for different block types (which I ended up scrapping), etc. I also felt that testing singleplayer early and finding that people enjoyed it was very helpful for my morale when I learned that multiplayer had problems and needed overhauling. Instead of being lost as to how to fix it, I knew what kind of core gameplay I wanted and worked towards getting the players doing that again.
- Art + Sound
I’m pretty happy with the art style I ended up developing for PCC. I knew I wanted things to be cartoony, and I planned from the start to have bobble-headed characters with giant brains. But the cityscape background, the brick textures for the blocks, and animated hands for the characters were all developed after the initial design.
- Level Design and Level Editor
My initial plan was to just have players race to build a taller tower, but the idea of having multiple levels came up pretty quickly. I wanted to make the levels very simple. The controls for the game were already getting fairly complicated, and I didn’t want to add more complexity through level design. I also wanted to leave a lot of room for players to solve levels in a lot of different ways, so I rejected any designs that I thought were too restrictive. The + and - goal system allowed a reasonable number of different levels and challenges and made building strategies almost completely open ended. In my playtests I saw very different solutions to some of the levels, so I consider my design successful.
I wanted to make levels easy to change, so I wrote a ‘level editor’ which takes images and parses them into PCC levels. The upper left pixel in the image represents the size of the blocks, and then there are pixel colors for green goals, red goals, base platforms, and swinging base platforms. The difficult part is combining adjacent pixels with the ‘base platform’ color into a single object. I tuned the level designs very frequently over the course of the project, and with the level parser all I had to do was open up some images in photoshop; it saved a lot of time.
- Hacks
I did a number of things somewhat inelegantly to save time; some of these were good ideas and some of them were terrible ideas. One that worked really well was the hand animation. Hands have two modes: swing, in which they are a constant distance away from the shoulder and the arms rotate from one angle to another, and slide, in which the hands are up by the head and slide towards a goal point without any regard for how far away from the shoulder they are. I initially wanted a ‘real’ animation system where I could draw points at the elbows and everything would look realistic, but to save time I did it in this simplified way and it wound up looking pretty good.
What didn’t go so well
- Farseer
The most frustrating part of the project by far was dealing with Farseer bugs. Complex 2D physics was absolutely necessary to make my game work, and Farseer was pretty much the only option when I started development. A full C# version of box2d is being written right now, but it is not yet available for public use. So I don’t actually regret using farseer, because I didn’t really have another option. But I do feel that it has a ton of shortcomings, including:
Sliding: blocks constantly slid apart in the initial versions of PCC, regardless of how stable they looked or how strong the friction was. I eventually added a manual workaround for this, in which I check a box’s position before and after each physics update, and if it moved a tiny amount I ignore the motion.
Setting things static: here’s an odd bug that came up when I was making the ‘freeze’ ability. If you have a static object (the level base) with two things sitting on it (such as a block and the character), and you set one thing (the block) to be static, then farseer flings the other thing into space. Sometimes it just crashes intstead. The fix for this was to set a custom collision handler for the frozen block which ignored collisions with other static objects.
Intersection: this is a bug that still exists, although I made it harder to achieve. Create a stack of about 10 4×1 blocks, then grab the top block and pull straight down. Somewhere in the stack, two blocks will slide into each other. I made this difficult to cause by carefully controlling how hard you can pull a held block, but it’s still doable. I have no idea what causes this problem.
- Energy System
I didn’t realize just how complicated the gameplay in PCC is until I was writing the ‘how to play’ section. Which is a lesson in itself, but anyway: most of the complication comes from the energy system. I introduced energy when I put in block freezing, because I wanted greater control over how often the player could use that ability. Attacking also had an energy cost, and I added one for block creation to tie the game together better. Having written up instructions for the game, it seems that energy takes too much of the player’s attention for something that was intended as an unobtrusive pacing mechanism. The player has to charge his energy, there’s no way to know how much energy something takes aside from trying to do it and seeing if you succeed, and the charge rate mechanics are confusing. I do plan to keep workin on the game, and the next version should remove the energy system and replace it with a timer for certain actions (like the one currently used for freezing blocks).
- Hacks
Earlier I described the hand animation system as a successful hack which saved a lot of time by dropping realism. One hack that I’m not happy with is the faked camera system. Instead of writing real viewport code, the camera change that occurs when a player attacks is done with a translate and a whole bunch of different cases in the draw code. Aside from making the code hard to read, this also makes it really difficult to change anything in this section, such as adding an animation for moving to the other player’s screen instead of just appearing there. Writing a real viewport system would have taken a lot longer, but it would have made this part of the game much easier to change.
Conclusion
I think I succeeded in most of my goals. I made a game which uses physics, which is fun to play, and which has a lot of room for variation between how different players play. Although there are some things that need to be streamlined, I think that PCC is close to being ready to go on the XNA community games site. Between PCC and my breakout game, I think it’s clear that my biggest problem when it comes to game design is making things too complex when a simpler design would play faster and be more fun.