Thin walls: dealing with the difficulties of a tile-based system

Game Talk The Drawing Board
1

Currently, every wall is an entire tile wide, from military bunkers walls to smart car panels & windows. Obviously highly unrealistic, in order to fix it, we would need a large number of changes, and it could be hairy… but it seems like it may be doable. so, a rough proposal…
new tile values for each direction, and flags for those values, I can think of a few; there are probably more. [OPAQUE](not sure how this would work with diagonals),[MIRROR], [BLOCK_MOVE].
standard thick tiles would basically act like one that has all directions filled with the same flags. This sort of system would allow much more realistic vehicle shapes, and more realistic durability differences. it works best with stacked tile modifications. vehicle floor, makes it walkable normally, vehicle walls block movement and attacks in their respective directions
A very bad example:
___
|@#| here we have a very small car, like a smart car, just 2 tiles wide by 3 long, with 4 seats and (2) trunk tiles. the lines are either
|##| doors, walls, windows, or windshields that have been placed on top of the same tile as the seats and trunks, which have in
|TTT| turn also been placed on the floor.

adjacent tiles that block the same cardinal direction would need to somehow block the diagonals between them (East on top of East would need to block the SE of the top and the NE of the north.)
I know it would be a big change, and people may not like it. It would certainly make some of the sizes and distances of things better though.

2

I’m sure your intentions are for the best; but you’re not talking about ASCII, aren’t you? You’re discussing tiles, and visual interpretation.
I’m sure you’ve heard of Heroes of Might & Magic. The series feature a Map Editor for every instance of the game. One of the expressions I’ve picked up from there are the transitional tiles. So if you have a stone desert that turns into grassland, there are a couple of transitional tiles to fill in that gap. Furthermore, if you drew one tile on top of another (like you should be), you can make a transitional tile for dirt, and an actual indoor-tile; when you do so, you can draw your wall right on-top…

…but don’t expect to walk over walls in video games, because that’s not gonna happen. :slight_smile:

3

I’ve read the OP twice and still don’t understand what’s being suggested.

4

I think Cat09 is suggesting that all tiles have more attributes so that instead of one tile representing one thing with one attribute (blocked/unblocked and so on) it could have ‘blocked from the South (so you can’t enter the tile from the south)’ but be open from other directions.

Unfortunately, the way the game works (all tiles are just converted from ASCII which is one tile per space) this isn’t going to work without a heck of a lot of work and without creating literally 100s of new items.

Sorry Cat09, this is one of those things which the engine wasn’t designed for and would require a whole rewrite.

5

Yeah, I know it’d require a rewrite, but there wouldn’t need to be all that many more items I think, you’d simply apply a given structure to a part of a tile. ie: apply sheet metal wall to north, north-east, and east.
as for display, ASCII is definitely a real constraint in this instance, since it must be centered, so to speak, on it’s "tile"
with graphics mode, it’d be more like: take metal wall side, and rotate for whatever wall is covered, draw over whatever is underneath that wall, say, concrete floor.
processing-wise, it’d VASTLY increase required calcs, however, that would be somewhat mitigated by the fact that you’d have more game compressed into less tiles. buildings, cars, fences, etc would take up less space, and so you have less tiles to work with for the same amount of content.

I don’t really expect anything like this to actually be implemented, however I think it is important to look at profound changes, so as to not miss things that may have some merit in some part of them.

6

[quote=“Cat09, post:1, topic:5733”] ___
|@#| here we have a very small car, like a smart car, just 2 tiles wide by 3 long, with 4 seats and (2) trunk tiles. the lines are either
|##| doors, walls, windows, or windshields that have been placed on top of the same tile as the seats and trunks, which have in
|TTT| turn also been placed on the floor.

adjacent tiles that block the same cardinal direction would need to somehow block the diagonals between them (East on top of East would need to block the SE of the top and the NE of the north.)
I know it would be a big change, and people may not like it. It would certainly make some of the sizes and distances of things better though.[/quote]
That’s not a 2x3 car, that’s a 4x4 car. (actually the last row is 5x wide??)
This is exactly the point, we don’t have characters to draw, “Player with walls to north and west”, it’s simply not possible within the drawing framework we have. If we were to discard curses (which we’ve stated many times we are NOT doing), we could maybe draw walls on the edges of tiles or something similar, but as you point out, that would require rewriting at least half the game, you might as well start over at that point.

To be productive though, it might be possible to have “implied but not drawn” walls for vehicles in particular, which seem to be the main pain point at issue here. I’m not totally sure how that’d work out or look, but it’s at least possible with the tools we have.

7

[quote=“Kevin Granade, post:6, topic:5733”][quote=“Cat09, post:1, topic:5733”] ___
|@#| here we have a very small car, like a smart car, just 2 tiles wide by 3 long, with 4 seats and (2) trunk tiles. the lines are either
|##| doors, walls, windows, or windshields that have been placed on top of the same tile as the seats and trunks, which have in
|TTT| turn also been placed on the floor.

adjacent tiles that block the same cardinal direction would need to somehow block the diagonals between them (East on top of East would need to block the SE of the top and the NE of the north.)
I know it would be a big change, and people may not like it. It would certainly make some of the sizes and distances of things better though.[/quote]
That’s not a 2x3 car, that’s a 4x4 car. (actually the last row is 5x wide??)
This is exactly the point, we don’t have characters to draw, “Player with walls to north and west”, it’s simply not possible within the drawing framework we have. If we were to discard curses (which we’ve stated many times we are NOT doing), we could maybe draw walls on the edges of tiles or something similar, but as you point out, that would require rewriting at least half the game, you might as well start over at that point.

To be productive though, it might be possible to have “implied but not drawn” walls for vehicles in particular, which seem to be the main pain point at issue here. I’m not totally sure how that’d work out or look, but it’s at least possible with the tools we have.[/quote]In Dwarf Fortress, when navigating the overmap, the player sometimes is unable to go in some given directions due to buildings or terrain. When the player is in position where his movement is limited, a little 3x3 window pops up in the corner, showing where he can and can’t go.

Depicting such walls at range is a different matter, in all likelihood, but if it’s used primarily for cars - could cars have “outside” and “inside” versions of their graphics? I.e. when you look at a van from the outside, you don’t see its 3.5L V6 engine, the lighter under its driver’s seat, and the meth lab in the back. You see the boards, the quarterpanels, the doors and the windshields. This “outside” view of the car is what determines how things from the outside interact with the car, so why not use it? Once the creature “steps inside” via a door or a broken panel, the “inside” of the vehicle now determines the pathfinding, and the creature can interact with stuff on the inside.

So a typical tiny car would look like this from the outside:

code┌┐
++
└┘[/code]

And like this from the inside:

HH[/code]Engine parts up front, seats in the middle, trunk in the back.
Wheels would be part of the “outside”, so that a wheel can be smashed without entering the car, while the engine would be “inside”, and would only start to get damaged when the panels surrounding it are destroyed.

Think this could work?

8

That’s possible, makes my head hurt trying to map out the interactions though :stuck_out_tongue:

9

I think it could definitely work, but I’m not sure about if it’d really be desirable. In RL games you kinda want all the in formation you can get without having to wander over to everything (which is always the most time consuming action). For instance, if you had what you suggested in place and you wanted to find a whatever you’d have to go inside each car to check. That’d be considerably more time consuming and for no real benefit other than a bit of immersion.

10

I think it could definitely work, but I’m not sure about if it’d really be desirable. In RL games you kinda want all the in formation you can get without having to wander over to everything (which is always the most time consuming action). For instance, if you had what you suggested in place and you wanted to find a whatever you’d have to go inside each car to check. That’d be considerably more time consuming and for no real benefit other than a bit of immersion.[/quote]True. On the other hand, you already can’t see items inside furniture containers, for the exact same “immersion” reason (and because it’s easier on the item finding functions’ performance, I’d imagine). It makes to sense to immediately see what is inside a closed metal-door fridge, and similarly you shouldn’t see what is under the car’s hood or in its trunk unless you’re at least right close to it (i.e. the 'e’xamine action).

Some kind of system for visibility should probably exist, though. You wouldn’t see items under a car’s seat, but you could probably see the seat through the windshield, and monsters should see when someone’s driving a car past them - though I think they should really attack the vehicle itself first, by virtue of “it’s moving, it might have food inside” instinct.

11

is it theorhetically possible to do a second draw using either tiles, or curses output, where you overlay an extended characterset line that is on the edge of the tile?

The inside vs outside view does seem like a pretty good idea, and (may?) use some of the same code my proposal for fixing the creatures invading your vehicle when turned problem http://smf.cataclysmdda.com/index.php?topic=6031.0

(ps: my little diagram was only meant to be representative of an Idea, as i’d need to post a ms-paint picture in to actually show what I meant, don’t pick on it :P)

12

Theoretically possible in tile mode, not possible in curses mode.
In tiles mode I always wanted to just draw the whole vehicle THEN rotate it, but that doesn’t adress the ability of monsters to attack through the cracks.

13

I had actually had the same opinion for having the vehicles be… cohesive, yet representing it with a separate coordinate plane entirely and translating to the main map coords. that won’t really work though with the curses limitations…

are the main reasons for retaining curses purely aesthetic / preference? or are there technical reasons as well?
if not technical reasons, (people will hate me for mentioning it but…) would it not be possible to simply make a 1:1 curses tileset standard?
I’m not even sure whether I think it’s a good idea, but I felt like I had to throw it out there.

14

No hate Cat, but as a long time player of roguelikes and user of consoles I would be more in favor of (read: less against) removing tilesets than vice versa.

Personally I can’t think of any convenient way to make thin walls work, and the inconvenient methods sound like a ton of work rewriting stuff, but I’m far from the best coder around.

15

[quote=“Cat09, post:13, topic:5733”]I had actually had the same opinion for having the vehicles be… cohesive, yet representing it with a separate coordinate plane entirely and translating to the main map coords. that won’t really work though with the curses limitations…

are the main reasons for retaining curses purely aesthetic / preference? or are there technical reasons as well?
if not technical reasons, (people will hate me for mentioning it but…) would it not be possible to simply make a 1:1 curses tileset standard?
I’m not even sure whether I think it’s a good idea, but I felt like I had to throw it out there.[/quote]
There are too many reasons to list, both asthetic and technical.
The high points are:
ttycast (webcasting) and ssh (play on remote servers) require curses. There are ways to do both with graphical programs, but they’re far more complicated.
glyph-based display has a certain asthetic to it, that’s subjective, but it is a really big deal.
requiring tiles means requiring at least one tileset to be maintained forever, glyphs have no maintenance overhead. This is extra important as no one on the core development team has ever been a tileset creator. It’s not that there’s anything specifically keeping that from happening, but that’s been the case in the past.
Everything in the game assumes a simple grid-based layout, this constraint means we can write highly optomized code, and makes the code much easier to understand.

16

so, I’m a little unsure about why a glyph to (glyph tileset) translation would be undoable, if less efficient than direct glyph display.
a simple y=(tile that looks like y) type of logic, adding a virtualization layer in between the game and the display, which allows you to potentially rotate for facing, draw 1 item overtop another, etc.
it wouldn’t require any dev overhead as you’re simply displaying a (visual) letter, just as you do now, so there would be no aesthetic problems, so long as the display is working correctly it should look exactly the same.
it’s moot since the webcast / remote play stuff is still there

as for pathing, is there a flag in for [untraversable]?

17

I’m not totally sure I understand what you’re saying…

You cartainly can map glyphs to tiles instead of integrating tiling support directly into the game, but I’m not sure what that buys you, the limitations we’re talking about such as only being able to draw one glyph or tile per square would still be there, and the code would be rather bizarre, which is why we didn’t go that route.
I’m not sure what makes you think it would be possible to build rotation or multiple glyph-per-tile support into such a scheme, it doesn’t sound feasible.
There is a kind of untraversable flag, which is a tile having a move cost of 0. That includes transparent tiles.

18

(i’m not trying to push the idea, simply re-explain it)

so, no changes would need to be made to the system as it is currently, except for a tileset that displays a graphic exactly the same in appearance as the glyphs, then you get to the potential benefit: removal of the glyph systems constraints(by doing away with it), allowing you to write a pre-display segment of code that considers values on tiles, etc allowing you to pick up things like:
facing, lighting and shadow (even on text - only), a pile of items could literally display a jumble of the characters used to display items,
the allowance for graphics offset, displaying a “|” in the middle, left, right, even rotated for top, bottom or horizontal, or a big “Z” for a big zombie.

19

There are already “tilesets” which are basically prettified ASCII.

20

Got you, use a tileset to emulate a text display, but with more capabilities.
i’m still not sure what that would buy you, out of the points i listed the only issue it completely adresses is one(asthetics), and it partially adresses a second (tileset upkeep).
you’d still have to discard the rest of the benefits of a glyph-based system in order to realize any features like stacking, sub-tile features, etc.