Tag: soulcaster 3

Latest Fixes: Pathing for Pixel-Accurate Movement

Today was focused on getting the monsters to behave as intelligently as they did back when movement was tile-based.

  1. Monsters uncrowd when they are overlapping (should pretty much never happen in general, but sometimes they spawn in the hitbox of another creature). If an intersection is detected between two creatures, they get an override that compels them to move away from each other for a few frames.
  2. Cardinal directional movement replaced with simple vectors, to allow for diagonal movement.
  3. When monsters have a line of sight and can walk directly to a hero, they use 8-way movement to get there. I added a bit of tolerance to the check to prevent the monster from zigzagging when on the same X or Y coordinate.
  4. Without line of sight, the monsters fall back on pathfinding (that is, if the monster is intelligent enough.. more on AI changes in another post). Just like with direct walking (which I call Gauntlet Movement in the code), it uses 8-way movement. This was really easy to do with my existing path mapping: it just checks the 8 adjacent tiles by including directions, rather than only the 4 adjacent tiles in cardinal directions.
  5. When monsters are in melee range, they can attack in 8 directions.

A quick word on diagonal movement. In many games with two-dimensional movement, the X and Y movement vectors simply get combined, and not adjusted for the trigonometry. Bishop movement becomes unnaturally faster than rook movement in this case. Think Doom II or Secret of Mana.

Traditional diagonal movement just combines X and Y to give you this nice diagonal reach.
Traditional diagonal movement just combines X and Y to give you this nice diagonal reach.
The "proper way" to do it adjusts diagonal movement to about 70%.
The “proper way” to do it adjusts diagonal movement to about 70%.

After spending so long with these games, my adjustment to trim diagonal speed actually feels like a real debuff. It seems slower even though it’s the same speed. For now it’s still in there, but I’m not sure what I’ll do later. A friend suggested the fast diagonal movement be a powerup.

Why Soulcaster 3 Will Not Have Persistence Between Runs

I’m a big fan of generosity in game design. My past games have all had infinite lives and quick respawns. So get ready for a break from tradition:

When you die in Soulcaster 3, you lose everything.

There are no unlockables or upgrades you can take with you to make the next run easier or different.

But why, Ian, WHY…?

I realize how polarizing this is. AAA companies spend a lot of money on market research and focus testing, and they are pretty much all in agreement on game presentation: tell the player exactly what they do next, and if they make a mistake or die in the process, start them about five seconds back.  I have no doubt this is how most people like their game experience. It especially makes sense to cater to this if you’re spending $50 million making the game.

It seems like indies are given a bit more license to be brutally difficult. I’m not sure why, but maybe it’s just that those of us who don’t much like the “Disneyland ride” game experience are happy to get a bone thrown our way. So I’m taking this license and running with it, perhaps to an abusive level. (Generosity is not completely dead, either… more on that at the end.)

Continue reading Why Soulcaster 3 Will Not Have Persistence Between Runs

We’re Off The Grid (mostly)

Pixel based movement is in.

When monsters form a full horde of 10 or more in one location, they sometimes overlap a bit, so that’ll need to be ironed out. Pathfinding needs to be updated to use 8-way movement, not just 4-way movement. Line of sight works really well. It definitely feels more like Gauntlet this way–once the systems are all working properly, I can test it out in the context of the whole game. Overall I’m excited about where it’s going.

Numbers are node weights. Shortest path to summoner is as easy as picking the lowest number in the squares adjacent to you.
Numbers are node weights. Shortest path to summoner is as easy as picking the lowest number in the squares adjacent to you.

The Grid, Continued

I couldn’t shake the idea. This morning, my first order of business was trying out pixel-based movement for the Summoner.

It actually seems to work really well. Even placing summons felt natural–I’m having them align to a grid, double the resolution of the tiles, to keep it tidy. It’s actually a lot like how Escape Goat handled a combination of tile grid and pixel accurate movement. Now Aeox can block a two-tile wide corridor… we’ll see how that changes things at the micro level.

Enabling pixel based movement for the monsters opened up a can of worms. Since they swarm so close to one another, I had to bring some of what I learned about collision resolution from Escape Goat, to keep them from merging and overlapping. It brought me back to the good old days of 2011, when, for months on end, every SVN checkin was noted as “collision hell”. I can probably keep this visit much shorter (though I said that to myself every day back then). Collisions are nowhere near as complex as Escape Goat, so basic AABB testing should do the trick.

I’m looking forward to seeing how this will look with dozens of monsters packed tightly together–should be reminiscent of Gauntlet.