Marshmallow Bear /
Designing an isometric 2.5D game like Final Fantasy Tactics Advance

One of my favorite game consoles was the Game Boy Advance, particularly the SP version because it had a light-up screen and you could fold it to fit in your pocket. However, I find that I'm enjoying the old form GBA now days, mainly due to being able to mod it to have a back-lit screen, and it's more comfortable to play with.

modded back-lit screen game boy advance, with final fantasy tactics advance

One of my favorite games on the GBA was Final Fantasy Tactics Advance, when I was a kid I picked it up because I liked the artwork on the box. Recently, I've been playing the game anytime I have some down-time and, other than being fun, it has got me thinking about developing a game. Playing through it I started to think about how cool it would be to create a game with that isometric style including using pixel art characters and animations.

Isometric, without tactics

One of the main things I'm thinking about is mostly creating a game with that visual isometric and nostalgic feel. I'm not exactly interested in making a "tactics" style game, to be honest. I thought it would be interesting to be able to freely move around an isometric world, including with the iconic sharp elevations of floor tiles (see below image). I'm thinking of just having the character automatically jump up or down to the next tile, depending on their movement vector.

final fantasy tactics advance tile layout

It would also be interesting to see if I could get the world to dynamically load in as you move around, this way there would be no loading screens in the overworld. If I dynamically load the interior of buildings as they are loaded into view, it might also be possible to teleport the player to the building interior instantly upon entering the building door.

The last part of this is that I want to make the world 3D, but the characters and props are going to be 2D sprites. This will make the physical movement around a bit easier, and it will make it easier to place objects within the world. This might give it a bit of a Ragnarok Online feel, though I don't really have an intent to orbit the camera around, it'll likely be fixed but can zoom in/out. Ragnarok didn't have this tactics style isometric floor, but it did have the 2.5D artwork (see below example).

ragnark online gameplay

Gameplay

I haven't really worked out the gameplay mechanics, which is odd because that's typically what I start off working out. I know that I like the idea in Final Fantasy Tactics Advance where you place the nodes around on the map, build up your clan, and send them out on missions. It might be cool to anchor to that concept and work out a simple form of combat, possibly like World of Warcraft or Final Fantasy 14, where you designate a target to attack and use abilities while fighting that target. Having clan members, pets, or maybe even friends (through multiplayer) help fight monsters might be a cool way to make the fights more interesting.

Game Engine

The game engine I'll be using is the one I've passively developed over many years. It's a C game engine using Vulkan for rendering, though I've ported it over to C++ for integration with any libraries I need and to simplify some things. It's in C++, but it is very much closer to C than C++ if you were to look at the engine, in fact C++ die-hards probably would be disgusted with what I've done here. I am a creature of habit and there are many reasons I primarily use C over C++ in general, but I can make a blog post all on it's own for this topic, I have a lot of opinions on it.

Getting started with tiles

The engine I've developed has a lot of stuff already done in general, so really it's just about starting on the game. I've already began doing some experimentation on the floor tiles as they were what initially inspired me. For this, I'm generating each individual floor tile cube directly in code, setting it's UVs, it's height, and it's vertices. In order to make it tile correctly, I'm not using just one large cube with a texture stretched across it, this would be an issue because I wouldn't be able to use a tile-map effectively by doing this. So I've taken the hit on having more vertexes so that I can have an uber tilesheet for the world artwork (instead of many little ones). Below is an example of how I can configure/construct a floor tile in code.

cpp
Mesh* m = isoland_create_cube(host, IsolandConstructCube{
	.height = i+1,     // Copied from a loop, thus the 'i'
	.tilesetWidth = 4, // Tiles in the tileset image
	.tilesetHeight = 4,
	.sideTileX = 0,    // Side tile image in tileset
	.sideTileY = 0,
	.topTileX = 0,     // Top tile image in tileset
	.topTileY = 0,
});

Doing this in a simple loop, we can see how the floor tiles and the tiling textures on them look. Ignore the texture artwork I'm using here, it's something I threw together quickly in Retro Sketch to make it easier to review.

first test of floor tile code

Resolution and camera

One of the things I have been trying to work out is if I should render at native (1080p) or if I should render at a smaller resolution and scale up to the window size (without super sampling). This might give it a nostalgic jagged edge (aliased) look that could feed into the retro feel of the artwork, however, it might also may conflict with the pixel-art style characters and props. I may do something in-between, where I don't render to a too low resolution (say just 720p HD) and see how that looks.

Example of 320x240:
example of rendering at 320x240

Example of 720x480:
example of rendering at 720x480

Example of full resolution:
example of rendering at full resolution

For the camera, I'm likely going to be rendering in perspective, but with a lower FOV (field of view) to get a somewhat orthographic look without actually using an orthographic camera. I'm not entirely fond of a fully orthographic camera for rendering just because I think some perspective gives it a little more life/character than no perspective at all. As stated previously though, I'm not likely going to allow for the camera to orbit, but I will likely let it zoom in/out a bit for cinematic effect.

What to work on next

Next I'll be laying out a definition file for designing out the world. This will just be a specification that will allow me to set the heights, well, basically it's going to be a heightmap. So perhaps I'll use an image to do this, or perhaps I'll use some other form of custom binary file to specify this.

Placing buildings and props should be as easy as specifying their location in the world, the height should be automatically picked up from the heightmap data. This will require a standardization of assets, all of the pivot points of each asset must be at it's base so that it will snap to the floor correctly. However, I will need to also provide the ability to offset from the floor, in case the prop is on top of something or floating in the air for effect.

Timeline and goals

For the most part I'm hoping to keep a shorter timeline, but that is going to be proportional to how much time I can spend on working on the artwork. It would be nice to have the core of the game up and running in about three months. However, artwork takes a very long time, so I'll need to come up with some methods of creating the artwork in an efficient way, and skip out on making things that aren't important to the core game itself. It'd be hard to project out right now at the very beginning of testing things out, but I feel that three months is a good goal; it's how long it took to initially create/release Retro Sketch.

As for my goals, it really is just to make a game in my game engine. Retro Sketch's goal was to create some software I can actually use to create games, but also to fully test out my bespoke UI system idea in the engine. Since that was pretty successful, I'd like to use this game as a way of proving out the ability to create games without much friction from the engine. I'm not typically focused much on money/return on the things I create, though nice, it's not exactly my primary goal for creating things.