ahegames
patreon
Working in Isometric [SfI]
🕑 Added 2020-12-08 16:18:43 +0000 UTCHey there,
I'm Grey and this post will cover the current coding progress with Snowballs for Inya.
Instead of waiting too long to make this post and polishing up the game engine as well as waiting for all the sprites to be completed, we figured it'd be nice to show my progress.
Going with an isometric system was a pretty daunting task, as the whole depth sorting system was a bit of a nightmare to put together.
The first thing to keep in mind with an isometric system, is that it's much easier to program interactions between objects in 2D space- so taking that 2D map and drawing it to the screen in isometric is the way to go.
The 2D map will usually not be drawn to the screen, it's just to help the development process.
However, when building a level, it's awkward to design it in that 2D form- so I had to write a script to convert the isometric level in the room editor into that 2D map form.
This was accomplished by flattening the isometric map (bringing all blocks to the floor height, in other words the lowest Z value) and then gathering the data of all the blocks.
Unfortunately, there's no way to sort the tiles by depth in GMS2's room editor, so things will overlap weirdly while designing rooms (like the snow tile being above the tile that's actually higher than it).
In order to improve visibility, the editor sprites only include the tops. An in-game room editor will not have problems like this though (a feature like this will probably come after the initial release if I do make it).
Once in 2D map form, I get the data from all the tiles and sort them by two values: their depth and Z value.
The depth value is calculated from the Y value a tile would have in isometric space if it's Z value was 0. The Z value is simply the vertical value of a tile.
The draw order is first determined by depth; Tiles with a higher depth value will always be drawn first, so they are behind everything else. Tiles with the same depth are then drawn in order of lowest to highest Z value, so they are drawn in an upwards stacking fashion.
Next thing is ramps- they are always a bit tricky to deal with, even when making a 2D platformer. This is because the center of an object has to be what interacts with the ramp, meaning that when going up a ramp from flat ground, the player has to be halfway to the ramp tile before it starts ascending. And on top of that there are a lot of unique interactions, such as going from a ramp to flat ground, to another ramp, or moving sideways from one ramp to another.
Also as a side note, this looks a bit janky without the finished player sprite, as it's way wider than the player will be.
There's also a snow particle system, which has varying wind speed which can be blowing from left to right.
The speed gently transitions between randomly selected speeds, never exceeding a specified top speed. The snowflakes also spin faster based on the wind speed.
This is done with a "data driven particle system" in which each individual particle is not an object, but rather a collection of values stored in an array (basically a list). This saves processing power and allows for a ton of particles to be drawn to the screen.
Next step will be to implement the snow interactions, and from there all of the other puzzle elements.
See you next update!
![Working in Isometric [SfI]](https://img5.patrefans.com/storage/6/bb/tf/563145-019e8b50-d5f7-7781-bbc4-dbb23aabe954.gif)
