I can’t help but notice that my last post was all the way back in March… half a year ago. I’d rather not go into detail as to the reasons, so suffice it to say that the last 6 months have not been kind to me. Blogging—and even game development—were on the low end of my priority list. However, I’ve finally started making games again, so I figure that I’d better revive this blog, too.
I’m still working on the “Towers” project I mentioned in my last post, but I’m rewriting it from the ground up. The prototypes I built before were promising, but I was starting to hate a lot of the underlying architectural and design decisions. While this does mean that I’m throwing out a lot of work, the lessons the prototypes taught me (both in terms of programming and game design) are valuable in and of themselves. In this post, I’d like to go over some of those lessons, as well as why I felt I needed to discard a lot of the preceding work.
To recap the high concept, the Towers project is centered around the idea of competitive tower construction, with players having to balance building towards a goal with sabotaging their competition. The intended experience is a frantic, strategic game in which players are struggling to keep their unstable towers upright.
This is a pretty vague concept, admittedly. This is why I’ve already gone through a couple prototypes, and intend to go through more to nail down how the game should look, play, and feel.
The first prototype approached this concept pretty literally. Each player had a junkyard from which they could grab building blocks, and then they would arrange and weld them together to climb higher than their opponent. Some of these blocks were structural, while others were weapons that could be fired periodically at the enemy to deal damage to their tower. As these towers got higher and higher, they would wobble back and forth, and the loss of a structural support (or even a heavy impact on the tower to knock it over) became a more pressing concern.
There was a lot of stuff going for it. Playing with the physics to build a tower is satisfying, and it’s even more fun to knock them down and blast big holes in the sides. However, there were some big problems. The building method was awkward and unwieldy, not really lending itself to quick placement of blocks. The player had to rotate and place each component manually, overlapping them to weld them. This made actually building the tower a frustrating, unwieldy experience when the tower was taking damage, moving around, etc… and since building towers is a central part of gameplay, this was unacceptable. Another problem was that the weapons needed to be fired manually, and this became a babysitting task that took away from the building process even more.
I made some rather drastic changes to try and address these problems. The original “drag, rotate, and weld” method of building construction was replaced with something more akin to the building method of World of Goo: the player would click near existing parts of his structure, and if there were resources available for building a new “node” was added to the structure and linked with existing nodes. This was a big improvement, because you could rapidly construct and repair your structures even under fire from your opponent, and because the wobbly World of Goo style structures play very nicely with the physics engine and are satisfying to watch.
The weapon systems were also overhauled. Instead of drawing weapons from a resource pool as before, there were “depot” nodes scattered in the environment. Building up to them would allow you to claim them, and once claimed they would generate a powerup on a regular basis. That powerup could be dragged to an existing node to transform it into a weapon. This is great, since it ties building more closely into the combat aspect of the game, and provides a more interesting reason to build upwards. I also removed the manual firing of the previous prototype; weapons would now fire automatically, as they reloaded. The player would only control their orientation, which could be set on the fly. This way, the player could focus more on building and less on babysitting their arsenal.
There were still problems with this design, however. While making the weapons fire on their own helped the babysitting issue, manually orienting the weapons meant that it was still a factor whenever aiming needed to be done… and with both the player and their opponent’s towers swaying around, breaking, and otherwise not staying still, this was distressingly often. The same problem was occuring with the powerup upgrade mechanic, in that players would need to watch the depots and drag the powerups out as soon as they appeared in order to not give up the valuable resources.
My plan to address these issues is to take a page from the tower defense genre. In tower defense games the player will usually have a single pool of resources to draw from which they can use to build or upgrade defensive towers. Similarly, I want the player in my game to have a finite, renewable resource (for brevity’s sake we’ll call it “metal”) which they can use to upgrade nodes in their tower for specialized functions. Further upgrades can be done later on those nodes to transform these specialized nodes into even better versions of themselves, for a price.
This is a better mechanic for upgrades, I feel. The resource it relies upon has no cost for not being immediately exploited, as metal can accumulate in a way that the powerups could not, and the interface is cleaner, with the user only needing to interact with the node in question and not some potentially distant depot. It also makes it much, much easier to add variety into the arsenal, and I have a whole array of potentially crazy ideas on how to take advantage of that flexibility.
I also plan to take another cue from the tower defense games in that the player will have no interactions with the weapons once they’re deployed, as they aim and fire automatically. If the previous prototypes have shown anything, it’s that babysitting an ever-growing arsenal is a lot less fun than building and repairing a teetering tower.
The depot mechanic of the previous prototype is not something that I want to lose in this transition, since it ties the combat and building components of the game together so elegantly. The depots, then, should be changed so that they now increase the regeneration rate of a player’s metal supply. Once can also thing of multiple kinds of depots… maybe they provide different resource types that allow for specialty upgrades, or provide “victory points” that decide the outcome of a match. This is something I’ll be experimenting with.
I won’t spend a whole lot of time on this, but as I mentioned earlier architectural decisions in the game engine were a significant factor in me doing a rewrite. The biggest change was moving from a traditional hierarchy of game objects to a component based model. Basically, instead of using inheritance to share functionality between game objects (e.g. a TowerNode object is a type of PhysicalObject is a type of GameObject) I use composition (a game object is just a collection of different components, which together define the behaviour).
I’ve found that this is much better for prototyping, and saves a whole lot of code duplication. I can create a new object by pulling together a whole bunch of existing components. For instance, a tower node might have components for a sprite, physical simulation, object ownership by players, and HP. A new “money generator” node could be just as easily created by adding a “give the owner money every second” script to that same collection of components.
The downside is that collaboration between components is not as straightforward as it would be in a more monolithic class. It requires some extra thought as to how game logic should be implemented. Preferably, one wouldn’t create a new component for every object type, since that defeats the purpose… the challenge is to find a way to combine existing, generalized components to get the desired game logic, or, if that is insufficient, then at least to make the new components required general enough to be reusable.
The whole thing has been a hell of a learning experience, and I hope to be able to post more about it soon!