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.