I ran a tech blog called SyndicateX for a long time, which had an Isometric Occlusion post. I was cleaning up a hosting account and I rarely wrote posts so I just took the blog down and redirected the domain – destroying the Isometric Occlusion post. I didn’t think anybody would care. Later I discovered that I was getting quite a few visitors looking for the post… So I started this blog and am reposting the Isometric Occlusion content for all you searchers!
Occlusion basically means “blockage” so when I say Isometric Occlusion I’m referring to the process of figuring out when objects are/should be blocking other objects in an isometric game. Isometric games simulate 3D in a 2D space and buildings can be dynamic shapes so there’s no magic calculation for how occlusion should be applied.
A few years ago, before I discovered Satellite Reign, I wanted to build a game that would be an homage to Syndicate by Bullfrog. I started working on a game called Animosity Inc and posted this video:
A few people asked how I did the isometric occlusion and managed depths of characters in 2D space, to simulate 3D. I think there are potential issues and maybe better ways to handle this but here’s how I did it a few years ago. the image below shows a node network, which civilians move around on, choosing nodes at random to wander the city. The player characters can also move around the city, sometimes rendering in front of buildings, sometimes behind. As a player character moves behind a building, the structure should fade so that you can see your character. In the picture below, the player (green circle) is behind a building that is faded out. Civilians (red circles) move from in front of a building to behind it, rendering at correct depths.
Civilians move around the city on a node network.
Each isometric building has two polygons. The green polygon is the Occlusion poly. The red polygon is the Collision poly. The small orange circle under the character is their Collision poly. Each update cycle two collisions are performed. The character is not allowed to move through the building footprint so it has restrictive collision that alters movement. The character is allowed to move through the occlusion poly but the building should fade out. So in that collision event I change both the building’s alpha value, as well as the character’s Z depth. I move the character sprite behind the building sprite if colliding so that the building renders over the character. This is less important for player characters, which make the building fade, but very important for civilians, which move around the buildings and don’t cause occlusion events.
Occlusion collision diagram.
- Civilian 1 is not colliding with anything. It is rendered on top of everything
- Civilian 2 is occluded by the building. It’s drawn just below the building depth so it appears behind
- Civilian 3 is in front of the building. If he tries walking straight upwards, he will collide with the building footprint before he collides with occlusion. This is important because he shouldn’t be drawn behind the building, which will happen if he collides with the occlusion polygon.
- Buildings have two sprites: the “footprint” sprite that shows the building’s footprint on the ground, and the building sprite that fades out.
I have no idea if this will work at scale. There are probably better, more efficient systems but this was what I came up with a few years ago. Good luck and let me know if this system does or doesn’t work for you!
