-
-
Save sandstrand/5491b134a44789296bf0382d64afec24 to your computer and use it in GitHub Desktop.
local dungeon_styles= { | |
{ | |
-- tower of hera | |
-- palette = 'dungeon.tower_of_hera.1'; | |
tier_introduction = 3, | |
tileset = 'dungeon.tower_of_hera', | |
floor = { | |
scope = 'room', | |
{ | |
high = { 'floor.a.12.high', 'floor.a.6.high' }, | |
low = { 'floor.a.13.low.' }, | |
p = 0.75, | |
}, | |
{ | |
high = { 'floor.b.12.high', }, | |
low = { 'floor.a.13.low', }, | |
p = 0.25, | |
}, | |
}, | |
wall_pillars = { | |
scope = 'room', | |
{ | |
socket = { 'pillar.4', }, | |
socketless = { 'pillar.4.socketless' }, | |
} | |
}, | |
drapes = { | |
scope = 'room', | |
{ nil }, | |
statues = { | |
scope = 'room', | |
{ 'statue.1', p = 0.25 }, | |
{ 'statue.2'}, | |
}, | |
wall_statues = { | |
scope = 'room', | |
{ 'wall_statue.6' }, | |
}, | |
barrier = { | |
scope = 'dungeon', | |
{ 'barrier.1' }, | |
}, | |
hole = { | |
scope = 'room', | |
{ 'hole' }, | |
} | |
big_barrier = { | |
scope = 'dungeon', | |
{ 'big_barrier.3' }, | |
}, | |
stage = { | |
scope = 'dungeon', | |
{ 'stage.1' }, | |
}, | |
entrance = { | |
scope = 'dungeon', | |
{ 'entrance.1' }, | |
}, | |
entrance_statue = { | |
scope = 'dungeon', | |
{ 'entrance_statue.4' }, | |
}, | |
music = { | |
scope = 'dungeon', | |
{ 'dungeon_light' }, | |
}, | |
destructibles = { | |
pot = 'entities/vase', | |
stone1 = 'entities/stone_white', | |
stone2 = 'entities/stone_black', | |
}, | |
}, | |
}, |
-
I think the preferred patten is a combination of key-value properties and a list of unnamed items:
{ scope = 'room', { ... }, { ... }, },
-
Are distances even required for displacement? East-tiles, for instance, could be east-center aligned.
-
p
-values should be named as such.p
could default to1.0
. -
Destructibles don't have any candidates. Is this deliberate?
-
I don't mind
nil
, but I think it's better use to have it in place of a patternid rather than an entire set of candidates. That way you could havep
-values for tile omissions.
Updated:
- p-values named p
- removed names for candidates
- nil now in table
I'm not sure how we should work with destructibles since the candidates would be entities rather than tiles in a tileset.
Can tiles be aligned as you describe? It is not an attribute which can be set for a tile in the tileset.
Is there any chance you want to left-align an east oriented tile? In that case I believe an alignment property or coordinates are needed.
I can't think of any such case.
I think we are ready to start implementing this. I've pushed a new tileset (dungeon.tower_of_hera) to the 0.4_gfx branch in my fork. I have not pushed any updated mappings.lua since i'm not sure what will break by doing so. Better to just lift the code from this gist.
Gist above updated to fit tileset better.
Made a pull request to develop with the new tileset but without mappings.lua
Somehow my comment about displacement yesterday got lost, but I managed to recover it from an old tab. Here goes:
The only information that's needed for positioning relative to the placeholder is the sizes of the placeholder and candidate tile pair as well as the direction of one of them. In the case of an east-oriented candidate: positionTopLeft(candidate) = positionTopLeft(placeholder) + vectorTopLeftToMiddleRight(placeholder) - vectorTopLeftToMiddleRight(candidate)
. If the placeholder and candidate have the same size, the top left corners will overlap. If the candidate is smaller it will be pushed to the right and centered within the placeholder.
No rush with destructibles.
Edit: Fixed math.
Then we need not declare displacements. Updating
How's floor
supposed to be interpreted? For each room (or dungeon, depending on scope), choose a candidate. For each room (always, independent of scope), choose a high and a low floor from this candidate? In that case, maybe the floors of most styles should be dungeon scoped? Or is there a better interpretation?
Right now I am aiming to procedually create all the dungeons in alltp and that does not require the extra versatility but I see no reason to not prepare for more custom dungeon styles by allowing the scope to be defined as you suggest. I also do not see any reason to not remove names of candidates.
A syntactic question: If we name scope, can we still omit the names of the candidates in the same table?