The development of Septipus: Tentacle Apocalypse from the programmer’s standpoint was a bit tumultuous yet a great learning experience. To make a long story short, a few months after the completion of SketchBox 360, we started work on Septipus. From first glance, it resembles the Bumpers mini game from SketchBox, however, I ended up completely rewriting it. We rewrote many pieces of our level editing tool and made completely new levels for the game a few times throughout the development of the game. We spent many iterations adding more and more game elements from breakable blocks to zombies to treadmills to spikes to breakable-blocks-that-turn-into-treadmills-or-spikes.

When I rewrote Septipus from Bumpers, I had the intent of making it as simple and modular as possible. I think we ended up doing an OK job of it. Level Collision and all the other heavy lifting happened in separate classes. The main Septipus class only handled core game logic, calling into each of the separate modules and updating them as appropriate. The one major drawback occurred in LevelCollision. As we added more and more things to collide with, this class got out of control. I refactored a lot of it, but it would have definitely benefited from a stronger object oriented design to make it more manageable and reusable. We never stop learning. For example, Bumpers was all stuffed into one code file at one time. We recognize that experience is the best teacher. It turns out that while it was a pain to deal with all of the additional elements being added constantly throughout the project, we have learned to spend more time in pre-production doing gameplay prototypes.

As you may know (or will soon to know/be spoiled), there is an epic boss battle at the end of the game that is totally different from the rest of the game. The way that the code was organized for this was excellent. Basically, each component would have an interface in which to expose functionality of the component to other components without direct coupling. This approach is initially a pain, but the benefits paid off over time. For example, we had a component that was a SoundEffectProvider. By encapsulating that functionality and exposing it as a service, it was easier to maintain that one place where sound effects were played rather than in 5 or 6 different classes. Near the release, we started lumping things together, but for the most part, each component was able to be maintained in an effective manner. Our super ridiculous attacks and collision subsystems strongly benefited from this as well.

The last real piece of the puzzle comes from the intro, conclusion/credits, and cutscenes. From a programming perspective, these were easy. The intro and conclusion/credits animations were made in FluidiMotion (our 2D tweening engine) and I simply play them back in code. The cutscenes consisted of a simple state machine for playing the appropriate cutscene. The “fun” part was in stitching all of these pieces and parts together.

Many lessons were learned from the development of this project. First, if everyone cannot work in the same physical location, you’re screwed. Miscommunications and motivation go out of whack if everyone is not together on a consistent basis. It probably would have taken us 6 months max to develop this game if it were not for things like college or paying bills. Also, time MUST be spent in pre-production NOT ONLY on concepts and story, but also on gameplay prototypes.

The team did do many things right and learned a whole lot about the process of making a game. The real success here is that we shipped it out. The game got finished. That is what matters. We can’t wait to show you all what’s in store for our next game. Until then, defeat Septipus and may the plubiest plube be the plubiest plube.

~Ken

This post is a continuation of Making of SketchBox 360: Pt. 1 . In the last post, there was a lot of discussion of about the engine and the tools used to build the game.  Now let’s get to talking about programming the game itself.  It’s always hard getting started with a new project.  The question usually is “Where do I begin?”  The answer is never straight forward and never the same for any two projects.  Making something from nothing but an idea is an awesome power. 

The first step involved with getting the project started was taking the animation engine used in FluidiMotion and implementing it into an actual game project.  Again, I can’t stress how much I love the XNA Framework for maintaining my sanity throughout that process.  Most of what this process involved was copying and pasting code from the engine and creating a series of helper methods to play animations and keep track of sprites.  The very first animation we created was a cursor dot.  A white dot with a ring around it that pulsated.  The best way to make something work is to make what you are working on actually practical to the game. 

After getting a cursor dot animating, the next step was to be able to control the cursor with the controller.  The control scheme sounds simple enough.  Move the cursor with the left stick.  Rotate the right stick to speed up the cursor.  There were also 2 more control schemes that needed to be implemented later.  This was surprisingly difficult because it seemed like it was always jerky and not smooth.  This went on for weeks.  The math worked out perfectly, but strange things were happening around the axies.  The solution? GamePadDeadZone.Circular. Well, who would have known that XNA was kind enough to automatically deadzone our input!  That is certainly a problem with a framework that tries to make your life simple. You don’t always understand exactly what it does for you, especially the times when it does too much.

So after all of that, all we’ve got is a cursor dot moving around the screen with a controller.  Now all we have to do is finish the rest of the ENTIRE GAME.  As it turns out, we had solved a lot of these tough problems early on.  Programming the minigames and the drawing modes weren’t all that difficult once we got our collision all worked out (but that’s a whole other blog post).  They ended up being a few thousand lines of code each.  I don’t think many people can get a grasp of how difficult it is to program simple minigames.

The beauty of a DrawableGameComponent is that it keeps things separated out so neatly.  I had maybe 4-5 of them just to mess around. I had one for testing the controls, the animation engine, playing songs, ect… After getting the dot moving around the screen, the next step was programming the animations for the PlayBox.  I’ll spare everyone the gory details.  I lost my sanity over it.  I don’t feel like recalling the experience at the moment.  All you need to know is that it was a lot of code.  I then started programming Bumpers.  I spent close to a month making Bumpers.  The reason it took so long was that I actually was writing collision physics code that was to be used in all the other game modes.  You might notice that Bumpers contains every element of gameplay in the entire game.  Line drawing, ball/cursor collision, wall collision, and “state management.” 

At this point, it was just a matter of iterating on parts of the game until they were finished.  We had solved all major problems programming wise, and it was just a matter of coding.  It took a few months after Bumpers was done to finish the game.   Finishing and polishing the game, the other “20%” ends up being 80% of the work.  In later posts, I’ll discuss the experience of the difference being the game being done and being ready to release.  There’s quite a difference.  That’s all for now.  See you next time!