Development – Page 5 – MagicalTimeBean

We’ve Achieved High Resolution

I could post a screenshot, but you wouldn’t be able to tell the difference… but today was entirely focused on getting ready for the move to HD. I have decoupled the tile pixel dimensions from their world dimensions. With the change of a single line, I can set the world up to use tiles of any size (32×32, 24×24, or 64×64 like Escape Goat 2). The move speeds and hitbox dimensions are calculated independently of this.

I still need to figure out a good native grid size: how many tiles are visible on screen at once. Soulcaster II had a visible size of 22×16 tiles. I’ve currently got the tiles scaled to 40×40 pixels, which at 1280×720 gives me a maximum visible grid of 31×17. Here’s what that looks like:

Right now that seems a bit larger than I want. Bringing in the width a bit, here’s 29×17:

A bit more manageable, and I think the aspect ratio is a little nicer. Narrowing it a bit more, to 27×17:

The beauty of this game being procedurally generated is that I don’t have to decide on a visible tile size (default room size) right now. I can make patterns of a variety of sizes, and have the game arrange them in larger rooms. Since the game will have scrolling in two dimensions, there will be some enormous rooms, where you can’t see all the enemies and obstacles at once. The engine also supports variable room sizes, and will center the room in the viewport with optional zooming. (Escape Goat 2 did this, and would zoom in up to 25% larger than default size).

Switched to Integer Math

I was planning for the refactoring of the coordinates system to take two full days, and I am already done with it. I needed to move from floats and Vector2’s to my own fixed-point based structs for position and velocity. I’m a huge fan of integers, and now the Soulcaster engine uses them just like Escape Goat.

World coordinates are now independent from pixels, so I can boost the resolution to HD, and even try a few different tile sizes. I still haven’t figured out what the best visible room size is yet. I might have a bit of zoom like EG2, but there should be a max size that fits the whole screen.

Off The Grid: Research Complete

After a quick rewrite of the collision detection system, and a couple extra AI systems that aid in pathfinding (more on that in a future post), I’ve got the monsters working just how I need them to. Even with a super fast spawn rate, they don’t overlap, and if they get deadlocked trying to get into a doorway from opposite directions, they will back off after a moment and retry.

With omniscient pathing turned on, the rats are completely unstoppable.

This is with pathfinding disabled, and AI set to move Gauntlet style (always towards the player).

Collision Purgatory

Pixel accurate movement has taken a bit longer than I thought it would. I was expecting about one week to get things operational–I think I got 75% of the way there in a week, but now it’s the final 20% that could take up 80% of the time.

Pathfinding and general movement works, but needs hacks to work properly. I created a system to help the monsters file through doorways without getting stuck, but it still relies on a system that temporarily disables clipping for monsters that get stuck together for too long. That system works great for declogging the doorways, but when the monsters get close to the player and start phasing through one another, they just stack in a jumbled, writhing mess. I really want it to look like Gauntlet, with mobs flowing gracefully around corners and stacking into nice grids.

I think my collision detection will also have to move from floating point to fixed point, because accumulation errors are probably one of the causes of clipping bugs among monsters. That change will take at least two days, if not more.

I’m pretty confident it will have been worth the trouble once everything is together. For now, it’s in that purgatorial state where the code is broken and ugly… not a place I like to leave things.