Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sweitx]

Code: [Select]

░░░░░░░
░B.░.B░
░.+░+.░
░░░X░░░
░.+░+.░
░B.░.B░
░░░░░░░
Draw the door at a 45-degree angle to the walls (i.e. vertical or horizontal in the isometric view) just like some tilesets would do for a wall in that position.

Code: [Select]

░░░░░░░░░░░░
░B..░..░..B░
░░░░+..+░░░░
░B..░..░..B░
░░░░░..░░░░░
Revolving door. This could be a standard fallback for when it can't figure out how to make a door make sense.

I think the main issue is that door is an occupy-able tile, so it's more of a piece of wall that disappears when a dwarf opens it and that there's no directionality to it.  So for all intent and purposes, every door in dwarf fortress behaves like a revolving door.

[zchris13]

You've said there'd be problems with ramps in any (?) projection. As a reference, take a look at Transport Tycoon and the way it handles ramps.

That's a limited set of easy ramps. (it looks like it handles some cases similarly to the way Simcity 2000 does, with the extra of supporting a smooth full-tile slope on a diagonal) I wasn't kidding when I said there are dozens of distinct ramp types that have to be considered even without rotation. This doesn't even consider, for example,
what

Code: [Select]

###
#^#
... should look like.

It is a fan shaped ramp.  You can only go up it north, north-west, or north-east.  Like all fan shaped. I guess.  Sort of.
Man, more of a problem than i thought.

[Jiri Petru]

This doesn't even consider, for example,
what

Code: [Select]

###
#^#
... should look like.

I suggest:



Yes, there are steps on the sides of the ramp. But they are small and I think it makes sense that creatures can pass them.

[Random832]

Still, that's a decision you had to make (nevermind that Z-levels are probably a lot taller than that)- there's dozens of decisions to make (4^8 [minus flips and rotations; if we use a rendering engine that can generate tiles from a 3d model that can be flipped or rotated.] if floor/down-ramp, empty space, wall, and another [same level] ramp are considered separate choices, and I can think of distinguishing cases between any of these) and the call's not always going to be that obvious. It's possible we'll need to think of a fallback model.

What might be more interesting would be to _smooth_ the terrain - declare ramps to be half-height initially, then use some sort of smoothing function on the height map (with discontinuities at cliffs)

http://www.gamedev.net/community/forums/topic.asp?topic_id=287520&whichpage=1&#1821342

http://www.squidi.net/devlog/oldrogue/entry004.php

The real problem is that the player can dig out (or build ramps for) whatever illogical configuration of slopes they want to. It's easy enough to constrain it so that worldgen mostly gets slopes that make sense in a simplistic model like SimCity or Transport Tycoon (really, it does now) - the problem is when the players build ramps, or dig ramps, or remove slopes/ramps, or dig next to slopes, or build walls, and end up with a configuration that doesn't really make _sense_. nevermind that ramp configuration spontaneously changing because you built a wall next to it doesn't make a whole lot of sense to begin with, even if it's otherwise perfectly reasonable.

The real problem is the information of what was next to a ramp/slope when it was first created - or what a ramp "looks like" - isn't stored. And if it does get stored, there's a temptation to make it have pathing implications (like not letting dwarfs traverse those "steps" in that one example).

Another problem is that the fact that DF allows diagonal traversal means some cases seem to make sense for its "ramps" that don't with others. So does the fact that cliffs are allowed (I think simcity 2000 makes rendering decisions about some "slopes" we see on the screen based on tile height alone)

[Footkerchief]

I suggest:



Yes, there are steps on the sides of the ramp. But they are small and I think it makes sense that creatures can pass them.

That happens to be a neatly symmetric situation though.  What about something like:

Code: [Select]

##.
#^.
...

where the ramp's "orientation" is ambiguous?

if we use a rendering engine that can generate tiles from a 3d model that can be flipped or rotated

That's kind of excessive.  I think it would suffice for community artists to render their own sprites from high-res models a la Infinity Engine, if they didn't want to go the hand-drawn route.

What might be more interesting would be to _smooth_ the terrain - declare ramps to be half-height initially, then use some sort of smoothing function on the height map (with discontinuities at cliffs)

Mithaldu did something like this for Lifevis, I think.  An isolated ramp (one that doesn't let you climb up to anything) is a sort of flat-topped octagonal mound about half as tall as a tile, and then as walkable walls get added around the ramp, extra panels get added to link the top of the mound to the tops of the walls.

That was in 3D.  In isometric 2D I think it's reasonably straightforward -- you draw one sprite for the central mound and 8 additional sprites for each of the possible connections, and then layer them back-to-front as appropriate.

edit: oops, that wasn't what he did, and now that I think about it, it would look like crap if you had several ramps next to each other or something.

The real problem is that the player can dig out (or build ramps for) whatever illogical configuration of slopes they want to. It's easy enough to constrain it so that worldgen mostly gets slopes that make sense in a simplistic model like SimCity or Transport Tycoon (really, it does now) - the problem is when the players build ramps, or dig ramps, or remove slopes/ramps, or dig next to slopes, or build walls, and end up with a configuration that doesn't really make _sense_. nevermind that ramp configuration spontaneously changing because you built a wall next to it doesn't make a whole lot of sense to begin with, even if it's otherwise perfectly reasonable.

The real problem is the information of what was next to a ramp/slope when it was first created - or what a ramp "looks like" - isn't stored. And if it does get stored, there's a temptation to make it have pathing implications (like not letting dwarfs traverse those "steps" in that one example).

Another problem is that the fact that DF allows diagonal traversal means some cases seem to make sense for its "ramps" that don't with others. So does the fact that cliffs are allowed (I think simcity 2000 makes rendering decisions about some "slopes" we see on the screen based on tile height alone)

This problem is something that the game logic already handles.  The game keeps track of how the ramps connect to surrounding tiles, and if those connections don't make sense, that's the fault of the game logic, not the graphics.  In other words -- the graphics shouldn't be responsible for figuring out whether the connections make sense, it should take what the game reports and run with it.

[Andir]

That happens to be a neatly symmetric situation though.  What about something like:

Code: [Select]

##.
#^.
...


I'm more interested in this ramp:

Code: [Select]

###
#^#
##.


[Random832]

Code: [Select]

##.
#^.
...

where the ramp's "orientation" is ambiguous?

In that case the ramp can simply points northwest. There is some trouble in getting this across in one tile (rather than having the slope spill into adjacent tiles, either above or below) - in SC2K, the two orthogonally adjacent tiles above would have a corner cut out, and the slope tile itself only has one corner off the ground.

if we use a rendering engine that can generate tiles from a 3d model that can be flipped or rotated

That's kind of excessive.  I think it would suffice for community artists to render their own sprites from high-res models a la Infinity Engine, if they didn't want to go the hand-drawn route.

The problem is that there's so many tiles to contend with. With an isometric camera, each tile can be pre-rendered once (for a given texture) and then cached.

What might be more interesting would be to _smooth_ the terrain - declare ramps to be half-height initially, then use some sort of smoothing function on the height map (with discontinuities at cliffs)

Mithaldu did something like this for Lifevis, I think.  An isolated ramp (one that doesn't let you climb up to anything) is a sort of flat-topped octagonal mound about half as tall as a tile, and then as walkable walls get added around the ramp, extra panels get added to link the top of the mound to the tops of the walls.  That was in 3D.  In isometric 2D I think it's reasonably straightforward -- you draw one sprite for the central mound and 8 additional sprites for each of the possible connections, and then layer them back-to-front as appropriate.

That's nothing like what I said. That's actually more like what I was hinting at when I talked about a fallback case (but I think we really do want - for example a ramp that's part of a straight row of ramps going from a straight row of floors to a straight row of walls, i.e.:

Code: [Select]

###
^^^
... or even:

Code: [Select]

##^
#^.
^..- to look like a simple slope, and not some octagonal stepped monstrosity. Can you post some screenshots of lifevis?

By "smoothing" I meant turning the coarse height-map of floor / ramp into a smooth function to where a slope might actually become a continuous level change three or more tiles in both direction. I.e. if our ramps look like

Code: [Select]

          ________
         /
        /
_______/instead have it look like

Code: [Select]

             ..--''
       ..--''
..---''
The biggest trouble there (apart from computation) is preserving cliffs.

Now, as for empty space, what I meant by that was that

Code: [Select]

#
 ^
 . should look like a simple ramp, but

Code: [Select]

.#.
.^.
... should probably make it more clear that it can be entered from most directions below and not just from the south.

[Random832]

The real problem is the information of what was next to a ramp/slope when it was first created - or what a ramp "looks like" - isn't stored. And if it does get stored, there's a temptation to make it have pathing implications (like not letting dwarfs traverse those "steps" in that one example).

Another problem is that the fact that DF allows diagonal traversal means some cases seem to make sense for its "ramps" that don't with others. So does the fact that cliffs are allowed (I think simcity 2000 makes rendering decisions about some "slopes" we see on the screen based on tile height alone)

This problem is something that the game logic already handles.  The game keeps track of how the ramps connect to surrounding tiles, and if those connections don't make sense, that's the fault of the game logic, not the graphics.  In other words -- the graphics shouldn't be responsible for figuring out whether the connections make sense, it should take what the game reports and run with it.

Well, yeah, it _is_ the fault of the game logic, but that really is part of what we're talking about. The issue is that the game doesn't keep track of anything - i.e. a ramp doesn't "know" that it's north-south because there was a wall to the north and a floor to the south when it was built - if you tear down the wall north and build one east of it it becomes an east-west ramp.

Which is a fault of the game logic, but really has just as many implications for appearance than it does for gameplay

[Jiri Petru]

So... what exactly is the ramp problem? That there are too many variations? Or that some ramps can't be logically imagined and drawn?

[Footkerchief]

That's nothing like what I said. That's actually more like what I was hinting at when I talked about a fallback case (but I think we really do want - for example a ramp that's part of a straight row of ramps going from a straight row of floors to a straight row of walls, i.e [...] or even [...] to look like a simple slope, and not some octagonal stepped monstrosity. Can you post some screenshots of lifevis?

By "smoothing" I meant turning the coarse height-map of floor / ramp into a smooth function to where a slope might actually become a continuous level change three or more tiles in both direction. I.e. if our ramps look like [...]
instead have it look like [...]

The biggest trouble there (apart from computation) is preserving cliffs.

Yeah, I edited this into that part about Lifevis, probably while you were writing:

Mithaldu did something like this for Lifevis, I think.  An isolated ramp (one that doesn't let you climb up to anything) is a sort of flat-topped octagonal mound about half as tall as a tile, and then as walkable walls get added around the ramp, extra panels get added to link the top of the mound to the tops of the walls.

That was in 3D.  In isometric 2D I think it's reasonably straightforward -- you draw one sprite for the central mound and 8 additional sprites for each of the possible connections, and then layer them back-to-front as appropriate.

edit: oops, that wasn't what he did, and now that I think about it, it would look like crap if you had several ramps next to each other or something.

Anyway, here's a screenshot of a mountainside in Lifevis:



As you can see, it handles the "typical" slope situation gracefully (I think that's the smoothness you meant), but some of the more ambiguous situations are kind of a  confusing jumble of crap.

Now, as for empty space, what I meant by that was that [...] should look like a simple ramp, but [...] should probably make it more clear that it can be entered from most directions below and not just from the south.

Yeah, this is what the octagon mound thing is good at.

[Impaler[WrG]]

I though this thread could use a bump as I've just released a new fortress viewing engine called Khazad that will try to incorporate some of the ideas expressed in this thread and address some of the issues raised.  I'm using an Isometric viewing perspective but might add perspective at a later date if it proves workable, camera movement is very free allowing full 360 degree rotation, tilting from vertical to a near horizontal.  A vertical slicing and shading system gives a strong sense of depth.  Please give it a try and give me feed back on what you like or dislike, I'm also looking for development partners to further expand the project.

See thread at
http://www.bay12games.com/forum/index.php?topic=34633.0

[Jadael]

I always figured the easiest way to handle ramps is just to make them half-height tiles. This gives an idea of how the game actually handles them- they're sort of like a tile that's two z-levels tall. That's not the best explanation though.

But then flows being able to move through ramps would be more visually ambiguous.

[Random832]

Is it possible for any of these viewers to get the stone type for tiles? Because what this (and lifevis, and 3dwarf) really needs is textures for all stone types (and ideally also for grass) - I'll start a thread for this.