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).
I wonder – how do you go about creating this kind of decoupling?
I feel like this seems to be “always” the best approach, so I wonder why this isn’t brought up in tutorials more often. Is there a drawback or a particularly difficult portion of implementing this kind of decoupled approach?
The original Soulcaster engine processed movement and position in pixel coordinates, using floating point numbers. The summoner had a walk speed of 1.0f, so he could traverse a 16-pixel tile in 16 frames. The skeletons had walk speeds of 0.5f, and so forth.
I kept the concept of 16 units per tile, since it’s easy to remember, but I switched from pixels (screen coordinates) to world space. There are only a couple places where the game needs to convert world space to screen space, so I have a conversion method that looks at the constant of pixels per tile, and does the multiplication. I guess it’s kind of like having fonts measured in point sizes, and scaling them to screen space based on the resolution.
I don’t have any experience with 3D, but I’m pretty sure you *have* to decouple world space from screen space in that situation. I’d be surprised if this weren’t a common practice in 2D as well…