Soulcaster I Behind the Scenes Part 2: The Design Doc

By popular demand, I’m going to continue this series and dig up some of the relics of the Soulcaster design process.  In part 1 I talked about lightweight design and posted shots of a few levels that ended up on the scrap heap.  Well for today I’ve found a special treat: the original design document of Soulcaster 1.

I haven’t edited anything besides coloring the text.  Stuff in red is stuff that never made it into the final design.  Italics are annotations I’m writing today.

Tower Defense Adventure

like tarchon, but more focused on individual rooms with finite enemies and handling “waves” perhaps [Tarchon was an earlier concept featuring one-player party-based dungeon exploration]

take your party into a dungeon room and you start to get attacked. you need to fight your way from room to room within a floor, surviving waves of mobs. when one aggros, all others in a small radius aggro, so they start filing in for the attack.  [I never tested this behavior, and it would be cool to have leader and following types of enemies in the future]

there are choke points like in any tower defense so you are facing waves of guys.

basically you set up your defenses by placing party members at key locations. you have ranged units who can fire at enemies, or over walls. aoe based attacks and that sort of thing. there are melee units, some of them can set up barricades. other disables such as stuns are also available. [There were no barricades or stuns. Status effects is something I hope to introduce in SC3, though it will be time consuming to balance.]

when you place a party member, he stays in one spot and executes a simple script. usually it will mean just firing at any enemy in range. it can also mean moving within a small radius to melee attack enemies that come that way. [The random skeleton friends in SC2 were an experiment with melee allies.  I could experiment with it a bit more, but for the first game it took away from the unit placement strategy.]

different situations that call for different strategies:

  • single file enemies where you can lob over a wall to kill them before they show up
  • narrow corridor which can be blocked by a shielded unit or by stunning the front line
  • 2-square exit where freezing an enemy can block it down to a single file, slowing the trickle rate
  • wide group of enemies where stuns and AOE are essential
  • multiple paths for monsters to appear—attacking from all sides where the party must stay close together

different monster types also require different strategies:

  • high armor creatures which remove the first x hp of damage, must use high damage attacks to defeat them
  • erratic units that don’t simply sprint for the player, can muddle up attacks and are easier to kill
  • hordes of low-hp monsters where high rate of fire is good, or AOE attacks do well
  • ranged units which must be confronted by melee units who can close the distance [SC2 introduced the doppelganger as a ranged enemy.  They would have to be some of the meanest and most feared enemies.  I’ll definitely be experimenting with these for SC3.]

enemies spawn from generators like in soulblazer. each generator spawns a finite number of enemies. generators are activated when the player gets close enough to them. [I made a simple scripting system that locked generators like doors, until the player stepped somewhere or another generator was destroyed. This way I could make the maps unfold in a variety of ways.] they cannot be destroyed, but disappear when all monsters have spawned from them.
each generator has a type of monster it spawns plus a rate of spawn and a number of monsters to be spawned. the rate of spawn can determine the rate of attack.

one situation—a spawn point is in the middle of a room so getting near it will cause a horde of spiders [probably the only generic fantasy monster to not appear in this game.  Wait–I would also need slimes.]  to spawn rapidly, 2 per second. without setting in ahead of time, this can overwhelm the party. members must be placed ahead of time before getting near the generator.

each floor shows the number of monsters left on the floor in the GUI [I think Soulblazer did this, and it would be worthwhile if the generators all needed to be cleared to proceed.  It just wasn’t useful ultimately.]

killing all monsters within a generator destroys the generator and leaves a treasure [I ended up with treasures being placed directly on the map, and as drop items from monsters, rather than being associated with the generators.]

killing all monsters on a floor yields a valuable treasure, or may even release the soul of a warrior (party member) [Again, this was me thinking in terms of Zelda or other similar games where you get a prize for destroying all the monsters in the room.  Levels were generally built so you had to destroy all the monsters, though in some you simply had to run for your life.]

trade out party members at the inn above ground [Here’s something I would love to do in SC3: custom party composition. It introduces so many design challenges, not to mention the extra assets for art and music and behavior code, so I skipped it for the first two games.  Even if I don’t have more than three summon types, it would be cool to offer more customization of the party somehow.]

we don’t need gates, keys, or one-way portals here. just passable and impassable terrain, and two way portals. monsters are not explicitly placed, just their generators are. there is no treasure on the map aside from what the generator leaves behind. [Drop items made the game more fun.  Tons of treasure flashing on the screen is cool.]

start without any allies, but find the first ally very quickly, within the first room or so.

player can have three allies in the party total, but there are more like 6 total allies in the game. they are swapped out in town.

allies could have a mana-based special attack, or two states to handle a variety of situations. [The “ultimate attack” per summon was something I was going to have in addition to the Scroll of Ruin attack.  Basically variations on the last-ditch nuke to save yourself.  The archer could have a rain of arrows, the bomber could do some sort of fire attack, the knight could do a war stomp to stun everyone on screen… It was another complication that had to be saved for another day.]

 

Not shown here are all the things I added to the game, notably the Merchant (upgrades) and the Soul Orbs system.

Looking back on a design doc helps remind me that even if I think I have a great concept, it’s only a vague notion of what could potentially be a game.  In my imagination features X Y and Z might be fun, but in the human world it might work out differently.

Leave a comment

Your email address will not be published. Required fields are marked *