Looking for feedback on an isometric style game in 2D

Unity Engine
1

I’m investigating making an isometric style game similar to this:

http://youtu.be/Pjkhw0crcOs?t=2m50s

1479164--81781--$Legend-of-Mana-This-Tues.jpg

This style game is essentially 2.5d, similar to games like King’s Quest, with 2d sprite characters moving around in an isometric view, with layered sprites for structures like buildings, trees, etc. You walk around a scene, and then reach an edge and move to the next screen. The camera may scroll a bit across the scene before it reaches the edge.

From a technical perspective, I was thinking of the following:

Using the new 2d features of Unity, a scene would consist of:

  1. A background layer - always behind everything else.
  2. A mid-ground layer, where buildings, trees, etc. as well as the characters move around on.
  3. A foreground layer, always in front.

I’d like to use the Unity editor to place sprites in the mid-ground layer, then attach a script to them which sets their “Order in layer” (Renderer.sortinOrder) value based on the screen Y position. That is, the higher they are in screen space, the further back they are in the layer.

Since characters move around in the scene, I might be constantly re-sorting the sprites, but perhaps would only have to re-sort the movable sprites through some trickery (leave large gaps between the sorting order values of the static sprites).

Extra thoughts:

I’d like to create a prefab gameobject, with one sprite that renders to one layer, and another sprite that renders to a different layer. For example, I’d like to have a building render to the mid-ground layer, and a shadow sprite render to the background layer, and have them both move simultaneously when placing them in the editor.

Okay, so does anyone have an opinion on this approach?

Thanks,
Clay

2

If you’re trying to sort scene objects, simply using their y position won’t work. If they stretch out , the y position isn’t accurate for determining render order. For example, you could have a desk stretching out from top-left to-bottom right.

From my experience: What you don’t want to do with isometric views is sort them. There are too many special cases. And you’ll spend your life scratching your head over all of the different special cases that you’ll miss.

The solution I came up with for an isometric game is to create a graph. Each object builds its own local graph of nodes, these nodes only have to deal with the sort order for the objects the visually collide with onscreen. This greatly reduces the complexity of figuring out special cases because you’re not worried about the entire scene, just the objects that overlap in visual space. You have to listen to collide events and rebuild the local graph.

You should be able to walk the graph backwards from each individual node to figure out render order. This works most of the time.

Hope this helps.