Do objects ever overlap recursively?

Discussion and analysis of graphics, story, levels, and so on.
Post Reply
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Do objects ever overlap recursively?

Post by Malvineous »

Hi all,

I've got a slightly odd question about level design, as the answer will influence how the Camoto level editor works. This applies to other games too, as well as Keen.

Ignoring map layers, if you consider that a bunch of tiles represent an object (like a sign, or a platform), and some objects might appear behind or in front of others (like a sign appearing in front of the platform, because if the sign appears behind the platform you can't see it), do you ever have a situation where an object needs to appear in front of some objects, but behind the *same* set of objects? This is really hard to explain, so I will attempt a diagram:

Code: Select all

+---------+
|         |
|    A +-------+
|      |       |
+------|       |
       |   B   |
       |       |
+---------+    |
|         |----+
|    C    |
|         |
+---------+
Here you can see that A is at the bottom, B sits above, then C is on top. If you use a Z order, with each number representing a depth, A=0 (bottom), B=1 (mid) and C=2 (top). By way of a level example, A could be the level background, B could be a moving platform, and C could be some foreground wall in a secret area, which obscures the moving platform as it goes behind the wall.

But once you introduce D, this no longer works:

Code: Select all

      +---------+
      |         |
+-----|    A +-------+
|     |      |       |
|     +------|       |
|   D   |    |   B   |
|       |    |       |
|       |-------+    |
+-------+       |----+
      |    C    |
      |         |
      +---------+
Where does D fit? It's above C, so the Z order should mean D=3. But that would mean it's also above A, which it isn't. So for situations like this, using a Z order number won't work.

So my question is this. Will this situation ever arise during level editing? Using a Z order number is very fast, but it will mean you cannot make levels where things overlap like in the above diagram. You will only ever be able to put objects entirely above or below other overlapping objects, like this, where D is entirely above or below, and not above *and* below at the same time.

Code: Select all

      +---------+                +---------+
      |         |                |         |
+-------+  A +-------+     +-----|    A +-------+
|       |    |       |     |     |      |       |
|       |----|       |     |     +------|       |
|   D   |    |   B   |     |   D   |    |   B   |
|       |    |       |     |       |    |       |
|       |-------+    |     |     +---------+    |
+-------+       |----+     +-----|         |----+
      |    C    |                |    C    |
      |         |                |         |
      +---------+                +---------+
I hope this makes sense!
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Right.


In the Keen games this never happens, sprites are the only things that could do that, and they are ordered by their foreground variable (0-3) and for a given value their position in memory (Which relates to when they were spawned, which relates to where they are put in the level.) Except in vorticons, where there is no foreground variable.


In a level editor; I am not sure, it would depend on how you wanted to do things. TED5 does not ever do this and I cannot see any reason why you should. The Keen games and other Apogee games work on a nice layer basis with say, background tiles always behind foreground.

TOM has a copy-paste feature, but it simply overlays what can be pasted over the level, showing what the pasted area would look like. If your editor wants to work the way games do, it needs z number.

But will it support translucent tiles?
fantomx11
Posts: 3
Joined: Thu Aug 23, 2012 3:56 pm

Post by fantomx11 »

Probably the easiest way to do it is to split object D (or any of them, actually) into two separate objects that are seamless and thus appear as a single object. Although if any of the other objects were to ever intersect the seam, then you would have a problem.
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

Try not to think of this in terms of what is technically possible in a game. The objects I am thinking of are an abstract concept only used when editing a level. The objects will be "flattened" into whatever layers are available when saving the map, but while you're editing it will be possible to have objects overlap.

The idea behind this is to present platforms and other things as objects which you can simply drag around and resize, so you don't have to think in terms of tiles. While you're editing the map, it would be possible to have two platforms overlapping for example, even though this is not technically possible in the game itself (they would be flattened down into a single platform.) You would be free to move each platform around, and tiles that get covered up by the platform are remembered, so that if you later move the platform somewhere else, the original background tiles are restored.

If you've ever played The Incredible Machine, that's the kind of thing I'm aiming for (but with overlapping items.)

In this situation, I am wondering whether there would ever be a need for recursively overlapping objects during level editing. I can't think of a case where there would be, but I wanted to get some thoughts from others.

I think splitting one object into two is certainly a possibility, so thanks for that suggestion. Problems at the seam will be fine, as the modder can take these into account. But it does mean it must be possible to crop objects, which is something I hadn't thought necessary, but could be very useful now that you mention it. So good idea there :-)
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Righto.

So I'm guessing then that while the editor itself is in operation it can have an arbitrary number of active 'platforms'

It is mathematically impossible for us to need recursiveness if the following conditions are met:

* Only one platform can be manipulated at a given time (Resized, moved, etc.)
* Manipulating a platform either moves it to the top or does not affect which layer it is in


However, if your editor allows two objects to be merged, then it is mathematically inevitable that we will need recursiveness unless we deliberately avoid it. This is because it will then be possible to merge two platforms in different layers, imagine D not as a seperate platform, but as an extension of C that merges with A. The object CDA will now be both above and below B.

The way to avoid this is to make two merged platforms take the same layer (Which then makes recursiveness impossible again.) either highest (on top of all), the higher of the two or the lower of the two would work.
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

Good points, thanks. I had planned to allow objects to be grouped together and treated as a single object, so in this case I think it will have to mean the group appears as a single layer, i.e. other objects can't appear in between the grouped items - they are either above or below the whole group (and within the group there would be another independent Z order.) This would mean you may have to ungroup some objects to get the Z order you want - I wonder whether that would ever be a problem? I suppose the Z order could actually be independent of the group...

It sounds like this is the way to go though. I do plan on leaving the tile editor in place, so I guess if the issue ever comes up it can always be fixed manually, tile by tile...
fantomx11
Posts: 3
Joined: Thu Aug 23, 2012 3:56 pm

Post by fantomx11 »

Inkscape, as well as many other graphics programs let you group several objects together with a sub z-order inside the group (which can also contain groups with another level of z-ordering.

it is not a difficult thing to deal with since ctrl+g will group all the selected object and shift+ctrl+g will ungroup them
Post Reply