Print

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

[alfie275]

And the water would look really wierd with new system, as the edge tiles would store the same amount as middle tiles and dwarfs would have to check for collision between tiles ( I suppose they would any way) which is basically the same as tripling the number of tiles without having extra room for more dwarfs.

[Silverionmox]

And the water would look really wierd with new system, as the edge tiles would store the same amount as middle tiles and dwarfs would have to check for collision between tiles ( I suppose they would any way) which is basically the same as tripling the number of tiles without having extra room for more dwarfs.

Water would look less weird! You could have waterfall curtains, instead of waterfall blocks. You could make a gutter by removing the floor, but not full squares of rocks, etc. The edge tiles obviously need to store less fluid (just one level, probably) if they are to help verisimilitude. It makes matters more complicated to program, and possibly for the player also. So the question is whether it is worth that much effort.

[LegoLord]

Has anyone ever thought that it might be possible to have something represented by two tiles, one overlapping the other?  It could look clunky, but if it was used primarily for marking a side of a tile, it shouldn't look too bad, right?

[Footkerchief]

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:

This is one of the major difficulties -- issuing dig commands will get much more complicated.  You'd have to have a "remove wall" designation for each of N/S/E/W.

[Silverionmox]

Possible ways of dealing with that:
- Assuming that the narrow space is to be dug out whenever it is between two designated squares
- Separate designations for mining with and without removing the in-between walls
- counting the narrow space as a space for the purpose of designating (eg. start designating on square 1, move 4 times to the right: now 3 squares and the two narrow spaces between them are designated).

None of these are elegant. If limited to an arrangement to make narrow constructions on the edge of squares, the benefit would still be available for the placement of grates, windows etc. Plantlife (eg. vines on the wall) and maybe water would be able to fit into that as well.

Maybe it's possible as a property of squares, rather than meddling with the space-time continuum?
eg. This is a smooth felsite floor. There is a -green glass window- installed on its east side, a *felsite grate* on its north side, and a *felsite grate* on its west side. There is a =felsite seat= installed here.
It would display as just a chair. Those grates etc. would block movement, of course; I don't know whether taking that into account for pathfinding would be trivial or a tangle.

Another option: adding a facing direction to placed objects. This comes with its own repercussions..

[Derakon]

I believe tapestries are in the goals somewhere; they'd need something like this to be done properly.

[alfie275]

Or just have anything that is in wall tile and viewed have a north south east or west position, then allow 1 object for each position ie. 2 engravings and 2 tapestries or 1 engraving, 1 taperstrie and 2 painting ec.

[Solifuge]

I think it might be best to keep the "Facings" simple. You only need 3 bits of Facing Data per tile in most cases; one Under Facing (the Floor), one Side Facing (along the left edge), and one Top Facing (along the top edge). As you added other squares, that squares Facings would fill in the spaces between the old tile and the new tile. You could also remove facings on the outer edges of the map, as they won't matter:

Code: [Select]

Example:]
▒║▒║▒║▒║▒
═ ═ ═ ═ ═
▒║▒║▒║▒║▒
═ ═ ═ ═ ═
▒║▒║▒║▒║▒
═ ═ ═ ═ ═
▒║▒║▒║▒║▒
═ ═ ═ ═ ═
▒║▒║▒║▒║▒
To help keep them simpler, consider the Walls the actual contents of the tile, but allow Facings and Floors to exist between them in special cases, modifying interactions with the Walls, or the spaces they stand between. They could depict Constructions, like Tapestries, Fences, Doors, Windows, grates, etc. Perhaps when fluid piping is implemented, pipes could exist as constructions built in Facing layers between walls. Facings could also depict certain special Natural Features; as Brooks are depicted as Natural Floors composed of water, Waterfalls could be similar Natural Facings made of water.

In regards to issuing Digging commands- when issuing a mining designation, you could have 2 options:
1) Use the area-selection method already used, which would also take into account the Walls and Faces.
2) Select a point of origin, and then navigate along the path you'd like to dig with the keyboard. You can select individual walls, faces, and floors to dig through this way.

[alfie275]

This would change things so much it would probably be after the main release anyway.

[Aquillion]

I just don't like it, even aside from all that.  Even if we could represent it graphically, it would hugely complicate a massive number of things.

Tiles are intuitive.  Either a space is stone or it's open.  Having paper-thin walls between tiles makes everything a lot more complex.

[Solifuge]

Don't think about them as tiny walls between walls. Think of them as spaces for adding things to each wall's face.

Here's a graphical diagram representing the idea:


The cubes at the top are 1 unit of Wall, with individual facing information. The Rough Stone Wall can have individual facings smoothed, including the floor.

Below that, you can see more advanced Facing ideas, like a Constructed Tapestry at the end of a hallway, or a constructed Door that behaved more like a real door, rather than some giant square portal.

[alfie275]

Well that makes sense but what about walking on the tops of walls, maybe a whole tile wall thickness, much like the layers in Little Big Planet.

[Solifuge]

I'd imagine units couldn't move on Faces, but only on the Tiles themselves.

By adding in Facings, you could handle certain constructions, such as Fortifications and Doors (which don't support a floor above), much more elegantly. It also would solve the issue of falling on a Fortification from above: currently, falling on a Fortification or Door from above forces the program to shunt you in a random direction, and treat you as though you had "slammed into an obstacle". By making these constructions into Facings, they would still inhibit movement through them, but since they'd be Facings of an empty tile, falling from above would only allow you to land Inside or Outside the Fortifications, instead of atop them.

Example:

Code: [Select]

  ═ ═ ═
 ▒+▒+▒+▒
║++++☺++║
 ▒+++++▒
║+++>++☺║
 ▒+++++▒
║+++++++║
 ▒☺▒+▒+▒
  ═ ═ ═

Legend:
'▒'      - Wall
'☺'      - Archer
'═', '║' - Fortifications (in the Facing between Floor and Open Space Tiles)
'+'      - Floor
' '      - Open SpaceThis shows what "Facing-Style" fortifications may look like atop a Guard Tower.

[Sunken]

I agree with thouse who fear that adding faces as independent entities would complicate the setup too much. IMO, facings should be restricted to being (immaterial) properties of the matter that is in the tile. A fortification would still be a stone tile, but in addition it is stored which directions are open to fire through (or to let liquids through). Stone smoothing would be an independent bit for each face of a stone tile; engraving would be an independent pointer for each face of a stone tile (going to an engraving object). Digging away the tile would destroy all those properties, of course.
Graphics-wise, the default would be to have everything look like it does now; you'd have to examine a wall tile to see which sides were actually engraved - but that could always be changed later if the information is there.

As for ceilings and floors, they could be handled the same way - a floor tile is a 'thin' stone slab stacked between the main 'cubes', and can have properties (such as being smoothed, engraved, bloodstained etc.) independently on its upper and lower sides.

The programmer could gradually alter tile properties from applying to a single block, to applying independently to its faces, and that would make the changeover much less painful.

[alfie275]

It might be wise to wait till we get isometric (rotatable of course) view before starting to do this.