Topic: Isometric view, baselines and seeing through walls.

[Egmundo Huevoz]

Hello, everyone! I've been thinking of making my game with an isometric view, like classic old RPGs like Diablo or Fallout. I have a couple questions:
1) Is this recommended? I've read every post about this in the forums, and I seem to recall somebody saying there could be trouble with baselines.
2) Is there any way to be able to see through an obstacle when the character is behind it? Like this:

Maybe make that south wall to be an object, but then... I don't know how would I approach it, and if it's even possible.
3) Is it possible to make a grid system with such a view? So I can move characters around this imaginary grid, etc. For example, Fallout used a hex system. I only want a square grid. Recently, I've made (with help) a grid system for a map room, but that's more straight forward, because it was just a plain aerial view, not isometric.

Thanks!

[Khris]

I happen to have created both a Fallout hexagon "engine" and a standard iso one. For the latter I actually ended up implementing a pixelwise z-buffer since I wanted my characters to be able to move freely on walkable tiles. I almost broke my brain while figuring out how to eliminate the clipping, and it's only possible because each tile shape has a handcrafted depth map:

x1 x2 x4 x8

If you're fine with the characters' positions being restricted to a tile's center, it's easier to pull off. You'll still have to either break up all walls into pieces or do lots of z-sorting.

The Fallout code is simpler and even cuts a round hole into walls in front of the player, but I've not tested it with multiple characters yet.
If you want to take a look, here's the 3.2.1 source: Google Drive

Suffice to say, anything that incorporates angles other than 0° and 90° can turn into a nightmare really quickly.

[Egmundo Huevoz]

Hi Khris! Well, if anybody could do it, it was you
Before I go with my usual round of questions, just answer this one, because if the answer is "no", then all the remaining questions are pointless. Is this too ambitious for a noob like me to pull off? I mean, I can imagine figuring out a simple rhomboid isometric grid, or something. Even if it takes me a week, heh. But I NEED to be able to see behind walls when the character is there. Otherwise it doesn't suit my game's needs. Is this too ambitious?

To the questions:

I happen to have created both a Fallout hexagon "engine" and a standard iso one. For the latter I actually ended up implementing a pixelwise z-buffer since I wanted my characters to be able to move freely on walkable tiles. I almost broke my brain while figuring out how to eliminate the clipping, and it's only possible because each tile shape has a handcrafted depth map:

I understood about 30% of this paragraph Although I understand the general idea of what you're saying... What's a depth map? Where does it go in AGS? I'm guessing those green thingies are the tiles and it's "depth", but that's about it. I'm sorry for my ignorance.

If you're fine with the characters' positions being restricted to a tile's center, it's easier to pull off. You'll still have to either break up all walls into pieces or do lots of z-sorting.

I'm fine with them being in the center. Z-sorting the objects, right? That doesn't sound difficult. Maybe time-consuming, but not "my brain can't handle this" difficult.

The Fallout code is simpler and even cuts a round hole into walls in front of the player, but I've not tested it with multiple characters yet.
If you want to take a look, here's the 3.2.1 source: Google Drive

You don't say... I thought a rhomboid/squared grid would be simpler than an hex one. Yeah, I'm totally fine with it just cutting a round hole. I've taking a look at the code, and I have to say, as with most of your more complex codes, it just looks like magic to me... I suppose you wanted me to press F5 and see for myself, but when I do, it says:

Hexagons.asc(306): Error (line 306): Variable 'do' is already defined

BTW, is that code you sent me a working code? I mean, could I use that Fallout engine you made into my own game?
Bottomline, I'm fine using either kind of isometric view, be it the Fallout hex one, or the standard one. Even one without a grid, moving with the mouse (like Baldur's Gate). The thing I have to figure out is the viewing through walls.

As always, thanks a lot for your time and dedication.

[Khris]

Let's put it this way: I don't know how feasible it is to create an iso game using built-in Objects and Baselines. The main problem is this:

        /   
       / o
      / 
   o /
    /

(top down view of angled wall and two chars)

The left character is further down the screen than the right one, so where do you put the baseline for the wall? If you put it in between the characters, the wall will cover the right character, not the left. One way to solve this is to split the wall into multiple objects and give each one an appropriate baseline.
I solved this by painting both characters manually, pixel by pixel, but only if what's already on screen is actually behind the character (this requires a secondary, hidden screen, the z-Buffer, were each pixel is used to store distance instead of color).

The simpler method requires to z-sort all characters, objects and wall parts, each frame. However if characters only move from cell to cell, you can simply draw back to front (painter's algorithm).

As for the hex-grid being simpler, it's essentially a staggered rectangular grid (think brick wall). The only difference to a square grid is that each cell has six neighbors. The source code I linked to needs AGS 3.2.1. to run, which you can get here: http://www.adventuregamestudio.co.uk/finals/AGS-3.2.1.zip

Long story short: it's definitely ambitious to pull off.

[Egmundo Huevoz]

Well, I've tried understanding the FO code you gave me, and I think I won't be able to pull it off in a million years. BUT there's a little good news. I figured out how to do something resembling what I want, based on Diablo rather than FO. In Diablo 1, the walls where you could walk behind are always transparent, thus you can see yourself, objects, and other characters. That doesn't exactly suit my needs, but I modified it so any given wall makes itself transparent when I'm inside/outside the building (depending which wall we're talking about), by using regions. It might be cumbersome to draw, but it works:
1) I draw the room and the building using layers. Then, I import the whole thing as the room's background, and paint the regions over the appropiate walls. For instance, region 1, in cyan, is drawn on top of most of the south wall, which then becomes transparent when I step on this region (i.e inside the building, south parth of the floor).

2) I replace the room's background with another one, this time without the building (but the regions persist).
3) I make the building using 4 objects, which represent the walls. They sit on top of the regions.


The walls have overriden baselines, so I can sort them by Z-order. But as always, I have an insurmountable problem. If I want a character other than the player to sit inside the building, it just appears drawn like he's outside, sticking to the outside face of the wall (in this example, he's the one wearing a black shirt).


I want him to only be visible when the player enters the building, like this:


I've tried fiddling with his z property, his baseline, but all to no avail. If I could do something like the object's "baseline override", the problem would be solved. But I don't know if it's possible. I can't find a solution anywhere.

[Khris]

You do realize that's the exact issue I outlined in great detail in my previous post...?

[Egmundo Huevoz]

I suspected as much, but I wasn't sure. To be honest, sometimes I'm at a lost, inbetween my noobness and the fact that english isn't my native language. I'm really sorry, you probably think I don't pay attention to your answers. The truth is, I read it at least 10 times. Something was telling me it was the answer, but... I wasn't sure.

One way to solve this is to split the wall into multiple objects and give each one an appropriate baseline.
I solved this by painting both characters manually, pixel by pixel, but only if what's already on screen is actually behind the character (this requires a secondary, hidden screen, the z-Buffer, were each pixel is used to store distance instead of color).

The simpler method requires to z-sort all characters, objects and wall parts, each frame. However if characters only move from cell to cell, you can simply draw back to front (painter's algorithm).

How would I make this "z-buffer" screen? I've seen a couple videos about this painter's algorithm and I understand the concept now. Should I make a function in the room's rep_exec that checks every object, character and so on in the screen, and makes it visible in the order I want?


I went to sleep and had an epiphany about another one of my "workaround" noobish solutions. I could just make that NPC invisible, and when the player enters the region I talked about, on top of making the south wall transparent, it could make the NPC visible again. If it was an interior room and wall, I could do that with another region, and so on. This probably isn't the better method, because I can't see a way of automating it, and it would be time-consuming. But it would achieve what I want, albeit slower. And I would have to refrain from making random dungeons with isometric views, unless I could somehow make a function that does this automatically.

[Khris]

One picture is worth a thousand words:



The dots are possible character positions, the lines are possible walls. Let's consider the black wall, and two characters A and B.
Using a painters algorithm, you'd first draw the green part of the wall, then character B, then the blue part of the wall, then character A, then the purple part of the wall. That way the wall is behind character B but covering A, exactly what we want.

However this means that characters cannot be wider than half the tile width.
Consider B moving towards B'; shortly before crossing the blue line, they're still drawn before the blue wall part is drawn; if they're too close to the wall, part of their sprite will be covered by the blue wall part, they'll clip into the wall, basically. The same happens to A if they move to the right; too close to the wall and they'll appear in front of the blue wall part.

In short: if your wall parts aren't much wider than the characters, and if the characters keep their distance from the walls, basic z-Sorting will work fine (the one AGS already does for you, based on the baselines).

If you want more freedom for your characters, or to cut a hole in the wall covering the player, you will at the very least need DynamicSprites to dynamically change the objects' sprites.

[Egmundo Huevoz]

Thanks Khris, I understood perfectly. However, I refined my own system, using functions applicable to different rooms without having to write everything over and over. It works 90% as intended, I have only one issue with it. I'm gonna make a new post about it, because the title of the post no longer reflects what I'm having trouble with.

I'm gonna keep your way as a backup in case mine runs into an insurmountable problem later on.

[selmiak]

can't you just cheat a little and make a walkable area inside the diamondshape and play an animation when changing room (player opens door, walks through it, appears in the next room) and then move the player character by a fixed amount of pixels into the walkable area in the next diamond shape ?!