Follow-up on Saturday's clinic: Games
Yesterday, in about two hours, I probably presented enough information about games to fill an entire course. (Hey!, that would be cool). I also ended up inspiring MYSELF to write a new game. I hope that some of you were inspired to create a game too.
I’d encourage you to have a go. While I don’t pretend to be a guru in absolutely all areas of Android development (anyone who makes this claim is lying), I know quite a bit about games – and I can give you all the expert help you need. Well, I can help with the easy bit – programming. Design is another matter. I’m just in awe of anyone who can come up with great-looking game characters and worlds.
There seemed to be some confusion when I talked about depth-ordering (z-ordering) in an isometric projection world. After the presentation, I was troubled as to whether people had understood what I was talking about. I wasn’t sure what was at the root of the misunderstanding either. So that’s probably why my answers didn’t seem to resolve stuff for you.
I was talking about how to decide what was in front of what in an orthographic world.
The brute-force approach would be to calculate the distance from the observer, and sort the objects based on that. But sorting can be computationally intensive. Especially in an MMO (Massive Multiplayer Online) game where there may be many avatars in the scene, all moving around.
I presented a standard simplification strategy to z-ordering. The one used by the OpenSpace Flash engine that I’ve used.
In this strategy we effectively number each cell in the way shown above. Then we apply a rule something within a cell with a larger number is placed in front of something in a cell with a smaller number.
Note that cell 10 is actually further away from the observer than cell 9. But this doesn’t matter because there wouldn’t be any overlap between the contents of these cells.
So, we spoke about this strategy working for graphical things in the same locality. This is what seemed to confuse people. Some of you thought of this as a limitation of the scheme, and seemed to be searching for a fix to overcome this limitation. When in fact, the “limitation” never manifests itself in a way that the observer would notice. There’s nothing to fix.
Maybe the misunderstanding lies with an understanding of what depth or z-ordering actually does. Consider two shapes. A blue square, and yellow circle. If the shapes overlap, then we notice which shape is in front of the other. We NOTICE the z-ordering.
In the first example above, the yellow circle is in front of the blue square. In the second example, it is behind. If these shapes were associated with cells in our orthographic grid, the shape in the cell with the highest number would be placed in front. This works well for cells in the same locality.
But when the cells AREN’T in the same locality, the likelihood is that the images associated with these cells WON’T OVERLAP.
In the first example above, the yellow circle is in front of the blue square. In the second example, it is behind. Spot the difference? There ISN’T ANY. Not to the observer anyway. If the image associated with cell 10 of the orthographic world gets placed in front of the image associated with the image associated with cell 9 (Event though cell 9 is closer to the observer). No one will notice. As far as the observer is concerned, everything looks right. There’s nothing to fix. The scheme works.
But when images associated with a cell occupy a larger area of a world, then it is possible for images that are not in the same locality to overlap. Yesterday, I gave the example of a house, and how we carefully choose which cells to associate (register) the images to – so that our scheme still works.
Yesterday, someone asked about the case where the house had a low roof. So an avatar seen at cell position 10 or 20 could be seen over the top of the building.
It was at this point that I realised I had REALLY confused you all. I and couldn’t comprehend the root of this confusion to fix things.
Suppose we have an avatar behind the house, at cell position 10. Suppose there is no overlap between the house and the avatar, so the avatar can be clearly seen. It is not obscured in any way. So it doesn’t matter whether the avatar is ordered in front or behind the house.
The blue square represents the avatar. The yellow circle represents the house. They don’t overlap. In the first example above, the yellow circle is in front of the blue square. In the second example, it is behind. Spot the difference?
But actually, in the house example, an avatar at cell position 10 IS BEHIND the house. Whether the avatar is obscured by the house or not. It is further away from the observer, and our depth-ordering (z-ordering) scheme concurs with this – and places it behind. There’s no conflict. No problem.
I think some people thought I was describing some kind of hidden surface removal? Or maybe object clipping? I don’t know?
I wasn’t describing this at all. I was just talking about what was behind, or in-front-of what.
If something is ordered behind something else, but it doesn’t overlap, and it can be seen clearly – there’s no problem. Just because we’ve decided that it’s behind, we’re not removing it or making it invisible, or clipping it or anything. It’s still there. It can be seen.
Maybe just saying it was “behind” something, when there was no overlap was enough to confuse people yesterday? I don’t know.
I still can’t understand root of the misunderstanding yesterday. Hopefully, I’ve explained myself better in this blog. If you still have a problem, please leave a comment. I really want to resolve the misunderstanding – whatever it is.