Print

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

[Silverionmox]

As we know, walls behave in a peculiar manner: no matter which way you look at them, they always look the same. This naturally stems from the fact that no information is stored for the different surfaces.

It would be possible to add a floor between every two blocks, just like there one at the bottom of each square currently. This allows to store information about particular sides, not the whole block. Those floors could also be used as a space for water to flow in, so we would get water curtains, instead of blocks of water falling down. It's a rather fundamental change, of course, and the switch to 3d isn't that long ago yet.

Would this be worthwhile?

Disadvantages:
- slightly more complicated
- code overhaul
- interface can't possibly display it in ascii

Advantages:
- more believable behaviour of walls
- the opportunity to add all kinds of wall features
- the opportunity for thin doors, walls, grates, fences, etc.
- sleekly flowing fluids (waterfalls, etc.)

[Duke 2.0]

 So like Roller Coaster Tycoon and fences? Yes, I know I bring that game up a lot, but a lot of systems it uses are similar enough to DF to be used.

 So if you have ever played RCT, something like the system they use to place fences?

[Silverionmox]

No, I've only seen some screenshots of it. But it's a fairly common problem if you want to represent real objects without modelling atoms: focusing on the boundaries or the volumes? A civ clone I helped with a bit used to have "Should rivers run through squares or on the edges?" as a recurring issue.

[Draco18s]

Actually, DF does know which side of a wall got engraved, it just doesn't have a way to visually represent it.  It also doesn't have a method of engraving the other side of the wall too, so the engraving is counted as being on "all" sides.

[Derakon]

The game already does this for Z-levels: there's the space for the level, and then there's the floor (and there should be a ceiling, too, but it's not implemented that way).

It'd be a bit problematic for the faux-ASCII display, though. That's my only major concern.

[Seryntas]

Actually, DF does know which side of a wall got engraved, it just doesn't have a way to visually represent it.  It also doesn't have a method of engraving the other side of the wall too, so the engraving is counted as being on "all" sides.

Wait, really?!

[Silverionmox]

Actually, DF does know which side of a wall got engraved, it just doesn't have a way to visually represent it.  It also doesn't have a method of engraving the other side of the wall too, so the engraving is counted as being on "all" sides.

That's interesting. I wonder why Toady didn't at least add north, south, ... on the description.

The game already does this for Z-levels: there's the space for the level, and then there's the floor (and there should be a ceiling, too, but it's not implemented that way).

It'd be a bit problematic for the faux-ASCII display, though. That's my only major concern.

Should there be a ceiling, floor and four walls for every block, or just on in between two blocks?

[Derakon]

Using a system like this would mean having walls that are not directly associated with blocks; walls (and ceilings, and floors) would go in between blocks. So in order to tunnel out a given block, you would first break through the wall on one side, then carve out the interior. You could possibly leave behind the other three walls. For example:

[Impaler[WrG]]

That's exactly the solution I used for Khazad, I have grid of Cube objects which represent to 'volume' of the map but between each cube (all 6 sides) is a Face object which is shared by the two cubes its it between, only these Face objects actually get rendered (along with Slopes, Stairs and other things internal to the Cubes).  Cubes can be flagged as Open or Solid and if Solid they will have a material ID that will propagate to adjacent faces but the face can be altered at a later time and retain independent data on their new appearance such as smoothing, engraving and blood splatters.  Faces can also exist between two Open Cubes which could allow for 'thin' walls to be built that are between Cubes and are more in line with the thickness of things like doors.

I solve the issue that Derakon describes by triggering the creation of new faces at the time a Cube is marked as being 'opened', all the adjacent still solid cubes then create faces bordering the newly opened space, meanwhile the face that the miner was wailing on is deleted as it is now between two open cubes.  This has the advantage of not having any unnecessary faces existing in places they shouldn't be displayed.

I'm still working on the memory structure of all this and might fold the face objects back into the cube if it saves memory so long as I can maintain the conceptual split.  Also I have yet to consider how all this will affect pathing which could be more complex.

[Aquillion]

The game has no way to represent this in ASCII.  Therefore, it's a bad idea right now.

[Ampersand]

Not so fast. Theoretically, it can be represented in ascii, just not with the available character set. It would need to be expanded by, oh maybe twelve more characters to represent the wall combinations, and a way to display them when a dwarf is in an adjacent tile.

However, this concept does have it's usefulness. Being able to dictate from where a dwarf is to mine from could have it's uses in exploratory mining.

[inaluct]

It's definitely an interesting concept, but it sounds very difficult to implement. If we work out a system for it's display, I'll support it.

[Aquillion]

Not so fast. Theoretically, it can be represented in ascii, just not with the available character set. It would need to be expanded by, oh maybe twelve more characters to represent the wall combinations, and a way to display them when a dwarf is in an adjacent tile.

No.  Unless you want to completely abandon the ascii/tile system, you would need a separate character for when anything is in the space.  That is, if you had a dwarf, a goblin, a chair, a barrel...  anything, you would need twelve versions of each.  In other words, you would be multiplying the total number of tiles/characters needed by twelve.

That is not worth it.

[alfie275]

And you are atlesast doubling the number of ties, it's easier just to have a N S E W engraving for each tile so up to four engravings per tile all in different directions.

[Idiom]

You could do it with tiles, but not ACSII. I'd throw this in with the graphics overhaul.