The Detours of Prototyping

You know, it’s really time for an update on Soulcaster. The longer it gets in between these things, the more I feel like I have to write a long treatise on everything that’s been going on since the last update. And yes–lots of stuff has been happening! But I can’t get to it all in one post. For now, I’ll just try to shed some light on where the project is, and what it’s gone through in the past few months.

My concept for Prototype #2 was to focus on the micro game of combat, and leave the exploration, upgrades, and other metagame stuff for later. So I set out to make a single-screen “waves of enemies” scenario, which gradually added more monsters to the scene after each level. I got it functional enough to show a few people, and quite honestly, nobody found it that interesting.

The reason is that I am missing a key component of what made the first Soulcasters fun and different: combining summon-based combat with exploration and dungeon crawling. The exploration element–moving from room to room, dealing with traps and ambushes as they come up–is just way more engaging than sitting in the same room, waiting for enemies to emerge from predictable places, over and over. It devolved into kind of a lame quasi-tower-defense experience.

It was also a bit too… institutionalized. Soulcaster should be about quick decision making amidst chaos–not, “Okay, are you ready for the next wave?? HEEERE they come!” which is what my prototype became.

Side note: Secret of Mana is one of my all time favorite games. I remember back in the day when I could finally play the only-available-in-Japan sequel, which had been fan translated for the emulator (shhh, don’t tell Square). Now, there’s no question that the graphics in Seiken Densetsu 3 obliterate those of its predecessor. But the gameplay just felt sterile. Each battle had a start and end, kind of like a turn-based RPG, and it defeated the purpose of action-adventure. I missed being given the option to run past enemies.

Without realizing it, I had kinda done the same thing to my game.

But that’s what prototyping is for: to try new things, see what works, and keep the good stuff.  Even though the experimental new scenario didn’t work, there’s actually a lot of good stuff to keep:

  • A “windwalk” (phase boots?) ability for the summoner to escape when he gets pinned down. It lets you walk through enemies and become invisible to them. It’s also useful to slip into a new part of the room to begin setting up a “fallback” position
  • A mana meter that charges up as you slay enemies. I’m going for a Devil Trigger/Rage of the Gods type of mechanic with this one. There are a lot of potential uses, like powering up an existing summon, doing some sort of ultimate summon form
  • Procedural generation of monster populations. I can have the room use a “budget” for monsters and pick a theme for them, and it divides them into waves and places them appropriately
  • When you destroy a monster spawner, it tosses shards of debris into the air, which spin and bounce when they hits the ground (this is important)
  • Housekeeping code revolving around keeping an inventory between rooms, starting a new game, gaining new powerups, etc. It’s not exciting to read about, and even worse to code, but it’s just one of those things that makes it feel like “a game”

So for Prototype #3, I really am aiming for a sparse, functional version of how I envision the full game: interconnected rooms, wandering monsters, traps and ambushes, obtaining items, deciding when to retreat or avoid an encounter. There are lots of unanswered questions about item and character progression, and I think it’s best to address those once the nuts and bolts are all there. Start at the ground level and work our way up.

 

Debug Visualizations & Tile Blending

With each project, I put a bit more time into debugging visualizations. I just try to look for things I spend time debugging a lot (where I step through code) and making sure there’s a quick way to show how things are working.

The most basic is the hitbox visualization, which shows world geometry (walls are red, trenches are yellow) as well as actor hitboxes. The monster hitboxes change color when their AI switches from pathfinding to Gauntlet movement (when they are in line of sight).

This is where you can see a few different layers of the pathfinding AI. The blue blob following the summoner is the vision radius. When monsters step on it, they switch from using pathfinding to directly walking towards the player. The numbers in the top right of each tile are the step values for the path map. They actually represent how many tiles away the target is, in this case the summoner. The numbers in the bottom right of the blue blob are the priority levels for the vision. Because summons also broadcast pathing and vision fields, each tile needs to have a specific target based on distance.

Finally we have the targeting radius. This is built just like the radius above, but it’s not obstructed by trenches. It’s used for the archer to pick targets. In the previous Soulcaster games, NPCs would fire off “line of sight” tracers to find targets. Because of how expensive these were for the CPU, they would have to be restricted to intervals of once or twice per second. This just made the AI slightly less responsive. This system is instantly responsive and by my guess, uses about 10% of the CPU power.

Not a debugging feature, but it’s something I just finished today and think is pretty cool. Since the levels are generated from basic elements, I have to teach the computer to do all the nice tile blending I did by hand in the previous games. It’s a fun challenge. This test just shows 16 different blend tiles which use the cardinal directions. To get rid of the divots in the corners of solid walls, I’ll need to add support for all 8 adjacent tiles. This can be used all over the place, for both natural and artificial architecture.

Ask Twitter: Placeholder art, scoring my own games, XNA, the leap to procedural

With today’s work on Soulcaster mostly being behind-the-scenes stuff involving the new slotting equipment/inventory system, I figured I didn’t have much to say on that topic today. I decided to poll my Twitter list for topic ideas, and got several I could answer lightning-round style. Here goes.

blog topic idea - vgm

On my own games, I get to pick whatever style I want, and have final approval. This does not necessarily make things any easier. Lack of constraints can be paralyzing for me, so I usually set up some artificial constraints before starting the score. On all four of my games so far, I’ve gone for something of a 90’s era redbook audio vibe. Soulcaster used Lagoon (SNES) as its main inspiration, Soulcaster II used Labyrinth (the movie), Escape Goat used Castlevania: Curse of Darkness, and Escape Goat 2 drew a bit from Bayonetta. All of the instrument sets were restricted to software versions of hardware that was available in the 80’s and 90’s.

When Creatures Attack

Part of the code upgrade from Soulcaster 2 to Soulcaster 3 is the way creatures attack one another. Since we’re going to have lots of complex equipment, magic, and creatures in the game, there needs to be a flexible system that can handle a wide variety of special abilities:  Life steal, stuns, poison, regen, invulnerability, mind control… All of these things need special code, and need to be informed of the events of an attack so they can play their special role.

Exposing events for customization like this is called adding hooks.

There are two phases to any attack: targeting (finding a suitable foe) and collision (the actual hit where damage is done). Let’s look at both of these in depth to see how it handles everything behind the scenes.

In this case, our immortal archer, Shaedu, is wielding a bow with a poisoned arrow. A rat is nearby.

rat1