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

We are now in the late stages of development for our newest game Septipus: Tentacle Apocalypse, coming to Xbox Live Indie Games in April 2012.  Been working hard for about 12 months now and are excited to share our newest game with you!

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!

SketchBox 360 was programmed in C# using the XNA Framework developed by Microsoft.  Never having to write any boilerplate code certainly made my life easier.

A decision was made early on that our game was going to be all 2D.  On one level that may seem like it makes the job of the programmer a lot easier.  For a gameplay programmer on most games, the answer is yes.  For me, life was not so simple.  The main issue we found early on was that programmers can’t create animations in code very well.  I ended up making a sprite layout and tweening tool called Fluidimotion so that animations could be created and exported by the artist.  I imported the animations into the game project and away they ran.  Some pretty advanced code was written to make a realtime animation engine.  Each scene that was exported was to be its own DrawableGameComponent.

A lot of time was spent after the animations were created to Play them and handle the main structure of the game.  We kind of used our own game state management technique to fit the pieces together easier and more logically than the XNA GameStateManagement sample code.  This allowed us a lot of flexibility for how menu navigation was to work.  Writing menu code isn’t very fun, but the end result from it led to a more consistent package.  The FluidiMotion Engine that powers the game is what gave it a very unique feel.  So much effort was put into making the game graphically impressive.  Even our main menu screen has a dynamic background animation with various abstract shapes moving around.  It’s a very subtle effect that hardly anyone notices, but it really adds a nice touch to the game.  The whole game is made up of a lot of graphical subtleties.  It’s all to achieve the mood of feeling really smooth and, dare I say, fluid.

Whew, we haven’t even gotten to the gameplay yet!  That will be coming soon in the post ‘Making of SketchBox 360: Pt. 2.’