frnsys/highrise

change how stairs work

Opened this issue · 2 comments

the way stairs work right now is a pain in the ass. they don't neatly conform to the grid layout system (due to their angles) and the rotation stuff is driving me nuts

it would be better if stairs themselves conform to the grid system.

couple ideas:

  • specify cellHeight separately from cellSize. we won't have voxels proper (i.e. x == y != z) but I think it will be ok?
  • or we keep cellHeight as the same as cellSize but allow a steps to be a special objekt (or maybe eventually all objekts can do this) and have a non-cellSize height

the latter option sounds better since it interferes less with the existing system, and i think eventually we do want objekts to have varying heights. then we specify the max height an agent can "step on to".

so saying we go with the latter, what's the best way to specify their placement?

ideally they are somehow specified as part of the layout matrices.

one option is to, as part of layouts, specify where a staircase starts and ends and then automatically interpolate/generate the staircase between them

but then it's not clear which starts and ends connect to each other...

more sketching/brainstorming:

staircases are effectively lines, so we can maybe infer which endpoints connect like so:

# floor 0
1 1 1 1 1 1 1 1
1 1 > 1 1 1 1 1
1 1 > 1 1 1 1 1
1 1 1 1 1 1 1 1

# floor 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 < 1
1 1 1 1 1 1 < 1
1 1 1 1 1 1 1 1

however this assumes that the staircase connects to the immediate next floor, which may not necessarily be the case.

so maybe we have to specify instead the floor num its supposed to connect to:

# floor 0
1 1 1 1 1 1 1 1
1 1 >1 1 1 1 1 1
1 1 >1 1 1 1 1 1
1 1 1 1 1 1 1 1

# floor 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 0< 1
1 1 1 1 1 1 0< 1
1 1 1 1 1 1 1 1