How to improve my Iso Engine?

Game Play & Game Design
#1

Hi!

After I have gained experience in writing a 2D Role Playing Game in Visual Basic, I now want to realize the project in Java.
Since I don’t want it to be just a remake, I decided to improve some features.
One of these improvements is the Iso Engine I use.
Up to now it is a very simple “engine” which is able to display a huge (scrollable) picture of the landscape which can furthermore animate objects (e.g. a mill wheel etc.). Because I use the graphics from http://reinerstileset.4players.de/ which do not have a unified size, the engine is not tile-based and information like unwalkable areas has to be set manually by placing “invisible walls”.
What annoys me is the fact that this engine lacks an important feature:
The hero is painted above all the other objects. That is, he cannot walk “behind” a house for he would conceal the building. Until now, in order to whitewash this weak point, I place the “invisible wall” mentioned above all over the building so the hero simply can’t move to the place where he would be “behind” the building. However, this solution doesn’t look very nice.
I now want to write an engine which supports an improved “ZOrder” so that the hero can walk in front of and behind the building (by the way- how is this feature called correctly?).
Unfortunately I have no idea how to realize such a feature… . I think I will have to discard the practice of simply loading a huge image file as the map and just placing some animated objects here and there. Instead I will have to place every object “in real time” in order to decide if it has to be drawn before or after the hero image. But how can I decide this? When does the draw order has to be changed? And do I have to alter the “invisible wall” concept as well in order to realize the “ZOrder”?

Sincere regards,
Fabian

#2

You could demux the big image up into multiple big images which will be layers. (say three) Such that the first layer consists of objects in the fore ground, the second layer consists of object on the same plane as the player and the third layer of object that exist in the back ground.

and so in the render loop.

draw background layer
draw player plane layer
draw player and enemies, etc
draw foreground layer.

#3

If you’d simply render everything back-to-front (up-to-down) you’d have infinite layers.

#4

Like Riven said, rendering the level from it’s parts at run-time would be the most flexible solution. If for some reason you don’t want to do that, you can create your own z-buffer while composing your level-image. Companioning your level, you would have to create a map of z-positions of every pixel in the map, so you can compare the z-position of your player-sprite with that of a possible occluder (e.g foreground buildung) or obstacle (buillding or invisible wall on the same z-level).

#5

Hi!

First of all: Thank you for your answers!

I already came up against the idea using several layers but there is something I don’t understand:

Let’s say I put all my buildings in one layer and the player is in another one.

So what happens if we want to walk “behind” a building- but being “in front of” another building at the same time?
If the player layer is higher than the buildings layer and as a result is drawn later, we will get something like this:
http://favorithsoft.de/demos/pics/jgo/above.png
As you can see, the hero is drawn over both buildings- not what we wanted.

If the player layer is lower than the buildings layer and as a result is drawn earlier, we will get something like this:
http://favorithsoft.de/demos/pics/jgo/below.png
As you can see, the hero is drawn under both buildings- not what we wanted either.

So, to get the correct result:
http://favorithsoft.de/demos/pics/jgo/correct.png
we will have to sort “in real time”- am I right?

Ok, let’s say we draw “up to down”, as Riven said, and we care about the player’s position, we could get something like this:


// pseudo code
objects_to_draw.sort(); // beginning with the object which has the lowest (y+height) coordinate (second criterion in case of equality: lowest (x+width) coordinate).
for (current_object : objects_to_draw) {
   current_object.draw(); // one of the objects_to_draw is the hero himself
}

By the way, you might ask why I’m sorting by (y+height) and not just by y?
The answer is that if we just sort by the lowest y coordinate, our hero won’t be able to disappear behind a building “completely”, because as soon as his head disappears behind the building (that is when he walks down), his y value is higher than the y value of the building he stands behind and as a result the hero will be drawn over the building (because we are rendering top to down).

This algorithm might work, however sorting the objects_to_draw every frame is not high-performance at all :wink:
Furthermore I’m not sure if I’m not overlooking a possible building-to-building or building-to-hero arrangement which doesn’t work with this code… .

So what to do?
I apologize for any disabusing notation- it’s not what I wanted- I’ve just written down my thoughts :slight_smile:
I hope you can help me to solve this problem :slight_smile:

#6

Sorting every frame might be somewhat slow. You can only re-order the units that have moved.

  1. Take all moved units from collection (preferable NOT one backed by an array, such as ArrayList)
  2. Put them into a separate collection
  3. Sort the collection with units that moved
  4. Insert the moved units one-by-one in the world-list, at the appropriate places.

Pseudocode


sort(moved.sort);

global = ..;
insertIndex = 0;
while(moved.hasNext())
{
   Unit unit = moved.next();
   int y = unit.y + unit.h;

   while(insertIndex < global.size())
   {
      Unit gUnit = global.get(insertIndex);
      int gY = gUnit.y + gUnit.h;
      if(y < gY) { global.insertAt(insertIndex, unit); break; }
      insertIndex++;
   }
}

// add remaining moved units.

moved.clear();

That should be as fast as it could ever be, when relatively few units move around.

A custom implementation of a LinkedList (that remembers what the last get(i) was, and caches it for a quick insertAt) would work best.

And now it’s only a matter of time before somebody hands another solution

#7

An Isometrich Engine handles Z Order by the drawing order.

You draw the tiles in lines, beginning with the top row. First draw the ground, then the top wall and the right wall (if any). Then draw objects on the tile like player, monsters, trees and stuff. Then draw left wall and bottom wall, if they exist, and the tile is done. Draw from left to right and top to bottom.

This way the player is always drawn over walls top of him and is overlayed by walls from tiles below him. The layering is not applied to the whole screen, but actually to every tile. Every tile is drawn back to front in means of the viewing perspective. Elements far away from the camera are drawn first, then elements that are nearer. That way, everything closer to the camera will overlay things further away.

-JAW

#8

Put the player in the same layer as the buildings.

In a pseudo-isometric RPG I made, I had several layers: ground, events (which were invisible), walls/furniture/characters, and roofs. I believe that it is what JAW described, though I’m not sure he described enough detail.

Instead of storing characters in an array by themselves, I included them in a 2d array with the walls, furniture, etc. I put each object in only one array position (rather than storing it in every position the object covered), so moving it was easy. I believe the (x,y) position in the array was the position of their bottom-left tile.

I drew from top-to-bottom then left-to-right, and it all worked out fine.

There may be a slight problem if the characters can be drawn inside the buildings, since you have whole buildings, where I just had walls that happened to form buildings.

Of course, you’ve probably already resolved this, since the topic is almost 2 months old.