Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Isometric Projection in Game Development

pikuma.com

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Isometric Projection in Game Development

#81

Post by kkukshtel »

Shooting my shot here:

I developed a large-scale, 2D isometric tactical strategy game called Cantata: https://store.steampowered.com/app/690370/Cantata/

It's sort of like a 4X version of a smaller tactics game like Advance Wars. Supply lines, region capture, unique units, etc.

It's isometric throughout, in part because I just love the aesthetics of pixel art isometric (having grown up on RTC, Age of Wonders, Simcity, Alpha Cen, Civ...).

This article was (and is) still the gold standard on describing isometric math: https://clintbellanger.net/articles/isometric_math/

We built a custom renderer for the game as well to support doing lots of crazy tile-layering steps that mix and match Z-depths based on various factors like specific units, terrain type, terrain decoration type, etc. Things like:

If a human soldier is on grass, the grass should be rendered on top of them, but if its a tank the grass "makes sense" to be under the tank, etc.

Art assets were based around 64x64 size tiles, and as someone else pointed out we were technically dimetric instead of isometric (as were most isometric games, dimetric feels too uniform).

Re: Isometric Projection in Game Development

#82

Post by YesBox »

qingcharles wrote: post #2

I developed the isometric engine for this[0] video game in the 90s. I remember trying to figure out the algorithm to determine where the cursor was (converting screen x/y to position on tile, taking into account height of tile stack and the fact the tiles could be transparent) was a monstrous headache for some reason. The sort of thing you'd solve in 30 seconds with Google in 2024. The 2D tiles were rendered out of 3…

Even with Google, it's a difficult problem[1]. What if you have multiple items on the same tile? What if one of them is one pixel wide (e.g. a wall)? What if something in front of that tile is tall enough to block the view? What if you need pixel perfect collision?

My first solution (before the buildings in my game had multiple floors) was to take the ISO mouse position, grab a list of items within a cone spreading towards the screen, then:

1.) Loop through each item

2.) Create a sprite of the item (so I have direct access to RGBA info)

3.) Convert mouse coords to sprite coords

4.) Check if I'm hitting a pixel (i.e. alpha > 0)

5.) Keep track of this item

6.) Update if an item closer to the bottom of the screen (i.e. closer to camera) gets a hit

Once I added building height, this became impractical (too many items to loop through, sprite creation is CPU intensive).

New solution is to assign a 24 byte UUID to each item, convert that to RGB, draw it to the screen (invisible to the user), and then return a tiny texture every frame from the GPU at the mouse position. If the color in the texture is not black, then convert RGB back into the UUID.

PS: If you know how to draw so that alpha replaces existing alpha (instead of blending), please let me know so I can have 32 byte UUIDs!

[1] Source: I'm developing Metropolis 1998 https://store.steampowered.com/app/2287430/Metropolis_1998/

Re: Isometric Projection in Game Development

#83

Post by pharrington »

qingcharles wrote: post #2

I developed the isometric engine for this[0] video game in the 90s. I remember trying to figure out the algorithm to determine where the cursor was (converting screen x/y to position on tile, taking into account height of tile stack and the fact the tiles could be transparent) was a monstrous headache for some reason. The sort of thing you'd solve in 30 seconds with Google in 2024. The 2D tiles were rendered out of 3…

I'll be honest - I'm spitballing here, as I havent made an isometric game yet. My instinct would be that the cursor, a visual UI element, only directly interacts in visual space - ie the screen tile is the screen tile, with no height information. When rendering though, you're projecting logical information to visual information. So when you render an object, you fill some struct that correlates screen tiles with last game objects' IDs that were drawn over it. The cursor logic just queries that structure.

edit: thats assuming you cant select anything that's been occluded. If you need to select things that've been occluded, lmao i dunno

Re: Isometric Projection in Game Development

#84

Post by qingcharles »

dgb23 wrote: post #40
codeflo wrote: post #9

Earlier quoted context omitted.

That’s awesome. > The sort of thing you'd solve in 30 seconds with Google in 2024. This is unfortunately becoming increasingly untrue, as the forums where stuff like that was posted are rotting away, and Google’s advertisement optimized result ranking neglects the long tail. And to the extent it is still true, it’s because pioneers like you figured it out and shared their results!

I've become a paranoid link hoarder because of this. I'm Pretty Sure these things are true in comparison to the past: - There is much more high quality content on the web than was ever before. - The signal to noise ratio is _much_ smaller. - Search results are getting cluttered by SEO spam, some of which is straight up copying from organic social media style sites (forums, SO, reddit, Github issues etc.) It's extreme…

I've become the same. I quickly realized that when I find a good article, I can almost never find it again later, even in my Chrome/Google history, so I've taken to immediately bookmarking everything I need later.

Re: Isometric Projection in Game Development

#85

Post by qingcharles »

Lewton wrote: post #63
qingcharles wrote: post #2

I developed the isometric engine for this[0] video game in the 90s. I remember trying to figure out the algorithm to determine where the cursor was (converting screen x/y to position on tile, taking into account height of tile stack and the fact the tiles could be transparent) was a monstrous headache for some reason. The sort of thing you'd solve in 30 seconds with Google in 2024. The 2D tiles were rendered out of 3…

Oh man, I completely forgot about that game. Absolutely loved it as a teen!

Haha, thanks.

It was supposed to be a fully 2D game, and several months in we realized we'd run out of RAM for all the sprites with all their rotations. So somehow I managed to convert it into a 2D+3D game in two weeks.

Re: Isometric Projection in Game Development

#86

Post by TremendousJudge »

qingcharles wrote: post #84
dgb23 wrote: post #40

Earlier quoted context omitted.

I've become a paranoid link hoarder because of this. I'm Pretty Sure these things are true in comparison to the past: - There is much more high quality content on the web than was ever before. - The signal to noise ratio is _much_ smaller. - Search results are getting cluttered by SEO spam, some of which is straight up copying from organic social media style sites (forums, SO, reddit, Github issues etc.) It's extreme…

I've become the same. I quickly realized that when I find a good article, I can almost never find it again later, even in my Chrome/Google history, so I've taken to immediately bookmarking everything I need later.

Chrome history search has always been very bad compared to Firefox. I don't know why, it's just text search over titles, but on Chrome you can never find squat. I always suspected it is on purpose, they want users to just use Google all the time.

Re: Isometric Projection in Game Development

#87

Post by mrec »

YesBox wrote: post #82
qingcharles wrote: post #2

I developed the isometric engine for this[0] video game in the 90s. I remember trying to figure out the algorithm to determine where the cursor was (converting screen x/y to position on tile, taking into account height of tile stack and the fact the tiles could be transparent) was a monstrous headache for some reason. The sort of thing you'd solve in 30 seconds with Google in 2024. The 2D tiles were rendered out of 3…

Even with Google, it's a difficult problem[1]. What if you have multiple items on the same tile? What if one of them is one pixel wide (e.g. a wall)? What if something in front of that tile is tall enough to block the view? What if you need pixel perfect collision? My first solution (before the buildings in my game had multiple floors) was to take the ISO mouse position, grab a list of items within a cone spreading t…

Heh. I remember doing your first solution for an Eye of the Beholder-style FPV engine back on the Amiga circa 1994. This was using existing blitter mask bitplanes so there was no sprite creation, everything was very fast (assembly). Can't remember whether I did culling based on bounding boxes first.

I also remember being quite chuffed about coming up with a "novel" approach using dithered planar masks to offset colours into palette ranges for not-too-blocky lighting. Then Quake came out. You forget just how siloed we all were before the Internet took off; every wheel imaginable must have been reinvented so many times...

Re: Isometric Projection in Game Development

#88

Post by goostavos »

qingcharles wrote: post #2

I developed the isometric engine for this[0] video game in the 90s. I remember trying to figure out the algorithm to determine where the cursor was (converting screen x/y to position on tile, taking into account height of tile stack and the fact the tiles could be transparent) was a monstrous headache for some reason. The sort of thing you'd solve in 30 seconds with Google in 2024. The 2D tiles were rendered out of 3…

Hearing that other people struggled with this problem gives me solidarity. It took me an embarrassing amount of time to get "click and drag thing" working in isometric [0]. Rendering differently sized sprites was a whole other thing.

Figuring it out without google was immensely satisfying, though. Reminded me what I love about programming.

[0] https://chriskiehl.com/article/home-theater-calculator

Re: Isometric Projection in Game Development

#89

Post by goostavos »

dgb23 wrote: post #40
codeflo wrote: post #9

Earlier quoted context omitted.

That’s awesome. > The sort of thing you'd solve in 30 seconds with Google in 2024. This is unfortunately becoming increasingly untrue, as the forums where stuff like that was posted are rotting away, and Google’s advertisement optimized result ranking neglects the long tail. And to the extent it is still true, it’s because pioneers like you figured it out and shared their results!

I've become a paranoid link hoarder because of this. I'm Pretty Sure these things are true in comparison to the past: - There is much more high quality content on the web than was ever before. - The signal to noise ratio is _much_ smaller. - Search results are getting cluttered by SEO spam, some of which is straight up copying from organic social media style sites (forums, SO, reddit, Github issues etc.) It's extreme…

My paranoia has grown from link hoarding to storing PDF dumps of sites that are really important to me. There've been so many times over the years that amazing resources just blip out of existence.

Re: Isometric Projection in Game Development

#90

Post by deathanatos »

Waterluvian wrote: post #50

Can anyone name an isometric 2D-rendered game they swear was 3D. Or a 3D game they swear was actually 2D? For some reason I find these most interesting. I could look up the answer but I swear Bastion is entirely 2D. Though the characters might be 3D models constrained to certain angles.

> Or a 3D game they swear was actually 2D?

Doom sort of fits in this category? The original[1] renderer cheated significantly in order to render the scene. It had to, for the hardware of the era. But it's not capable of arbitrary rooms/map layouts, and so, e.g., the maps are strictly 2D. IIRC, this is the reason the camera is locked on the pitch axis.

Factorio is a 2D game, but the assets are 3D, sort of like the DK example. The fun comes in that the game is 2D grid of tiles (pretty normal) but not top down, and that causes some associated havoc when things try to rotate: https://www.factorio.com/blog/post/fff-133

[1]: many modern ports do, or can, use true 3D renderers, and are thus not quite the same as the original in this regard. Later ports are also capable of non-2D maps, including things like bridges and overlapping rooms that the OG renderer couldn't do.

Post reply on HN