I’m currently designing levels for the campaign/story mode of my tower defensish game Def. There are various approaches that tower defence (TD) or RTS games take in progressively introducing new tower types and enemy types. It’s not uncommon to have a kind of tech tree, or a store where new tower types can be unlocked. As the player progresses through levels and gains more money or experience points, a greater variety of towers become available. These open up new strategies which usually need to be exploited immediately to deal with new enemy types. Because of it’s roots as a minimalist game, with Def I’m taking a simpler approach – the availability (or unavailability) of different towers follows developments in the story. This could be seen as taking away an interesting choice from the player, compared with providing the choice to specialize down one branch of a tech tree as in other RTS/TD games. Instead however, it opens up the possibility to have tower availability to be tied directly to important choices in the story. Additionally, it allows for levels to be designed and balanced around a known complement of towers.
The complement of levels and some details of the story in Def are still in flux – however I have planned the basic progression of tower and enemy types that will appear in each level. First, you just have “Boomer” towers available, and the attackers are “ZDrones” only. Then, “Shooter” towers become available. Then you get to use “Boomers” and “Shooters” together. Then a new enemy type appears, then a new tower type (etc, etc. I’m not going into specifics at this point since I don’t want to inadvertently reveal any spoilers :p). At certain points, the availability of towers and types of enemies will be determined by choices made in the story. Of course, nothing is set in stone at this point, and the basic progression might change in response to external playtesting.
Now … on to the new feature that I added today. As the types of level I wanted to design have become more complex, I’ve been finding that I really wanted to be able to restrict where players could build without restricting enemy movement. In a traditional tower defence game, building zones are usually tightly constrained – there is usually an enemy path and specific slots beside it where towers can be built. A typical RTS allows a lot more freedom, both the enemy movement and ‘tower’ placement are often only restricted by terrain. Anyone who has played the Ludum Dare prototype of Def will have noticed that the rules for tower placement and enemy movement are much more like an RTS – except that the ‘terrain’ changes over time as enemies drop more pheromone (aka Phr) creating an ever expanding ‘no build zone’. For designing more interesting levels, I really wanted to have some initial Phr saturated ‘no build zones’ – but I also wanted to stay true to the idea that the enemies would always lay this down themselves (punchline: I’ve thrown the later out the window).
My first solution to this was the introduction of the “Runner” enemy type. These guys move quickly in a fairly direct path to a base or tower, laying down a hot line of Phr all the way. From a design perspective, one way these are intended to be used is at the start of a level where a small wave of Runners can quickly lay down a Phr path, creating some small areas where the player can’t build, as well as a path that slower enemies will follow. In practise, I haven’t found that the Runners are an effective enough way of creating initial ‘no build zones’. To deal with this, today I added the ability in my level building tools to set some squares that are initially saturated with Phr. With regard to the story, this is quite acceptable – the attackers simply find a way to pump Phr through the Rift in advance of their arrival. In terms of level design, this opens up a whole bunch of interesting possibilities and new challenges for the player, by more tightly constraining where initial towers can be built.
For example, originally a level would look like this, and would rely only on “Runners” to seed any initial Phr ‘no build zones’:
Now, I’m able to build the initial level to look like this – with large zones of Phr (red):
From a design perspective, having more direct control over the initial Phr patterning allows me to force the player to tackle things differently than how they might in the Phr-free version, and prevents the player using some strategies that would otherwise make the level too easy.