feature complete platforms/doors

[yaelatletl]

• [x] Trigger by direct User Interaction (By pressing "use")
• [x] Trigger by switch Interaction
• • [x] When switch is pressed
• • [ ] When switch is active
• • [ ] When switch has deactivated
• • [ ] When another platform has begun moving
• • [ ] When another platform has stopped
• [ ] Trigger by stepping on platform
• • [ ] Platform trigger delay (for M1 strats)
• [ ] Crush damage
• [ ] Move along platforms
• [ ] Ignore world collsions, do not ignore player/enemy collisions
• [ ] Signals
• • [ ] Platform stopped
• • [ ] Platform started
• • [ ] Platform enabled
• • [ ] Platform disabled

[hhas]

Some notes about visual language:

MRC will need two classes of door:

• gameplay doors, which replicate original M1 doors on maps

• eye-candy doors, which demark new cosmetic rooms that branch off the original level layout, making environments feel large and purposeful for players who wish to explore the Deimos world fully but which do not impact gameplay and can be ignored by those who just want to run and gun along the original routes.

Simplest way to distinguish between them is for gameplay doors to open vertically (this way they preserve all their original behaviors, including crushing) while eye-candy doors slide or swing.

We will need concept designs for doors. Most Deimos doors are 1x1WU which allows us to standardize. Some are 0.5x1WU, e.g. the access hatch to the service tunnels. I cannot recall offhand where there are larger doors on later levels.

Aesthetically, I am using “Habitation”, “Science”, and “Engineering” as loose Environment categorizations corresponding to the 3 original Deimos texture sets. That being said, we can freely mix and match textures within a map; e.g. while the start of Arrival is “Habitation”, the service tunnels may be classed as “Engineering”.

While we only need to implement a couple doors for Arrival, we should plan all door designs now. We’ll need to prepare design sheets before we approach Bungie, so they can see how we intend to redecorate the other 26 levels. And by doing them all at the same time, we achieve final consistency when everything’s fitted together at the end.

M1 doors tend to be extremely simple in appearance, usually 1-poly. That’s something I improved on in Trojan, with recessed grooves and stripey borders. For MRC, we can afford to build door components with door frames included. Frames not only make doors look more visually interesting, they also simplify mapmaking as the frame covers any imperfect joins between walls and doors.

We can also build “locked” vs “unlocked” vs “inert” (dummy) status indicators into doors and/or door frames, e.g. small red/green/off lights, thereby indicating to players if a door that buzzes when TABbed does so because it’s locked (i.e. the player needs to unlock it) or because it never opens (because there is no map on the other side). For instance, of the first two doors in Arrival in the brightly lite anteroom, the west door (into the landing bay) cannot open, whereas the east door (into the exit room) is openable only once the player unlocks it (from the other side). Thus the landing bay door’s indicators would be off and the exit door’s indicators would be red. The service tunnel hatch (in the pattern buffer room) would have a green indicator, i.e. it can be freely opened by the player at any time.

–

As to platforms, best split those into a separate task as they will have their own set of requirements and changes to consider.

[yaelatletl]

yeah, in this case we talk mostly about the doors/platforms code-wise, they will be the same in the core, and we can integrate the features you just mentioned on top of it

[hhas]

Codewise they’ll be similar but not identical. e.g. We want true platforms/elevators, with open volume below as well as above, which will require obstruction detection underneath as well as above the moving ledge.

The simplest way to develop platforms is to create the Door class first, then duplicate that class and rename the duplicate Platform. We can then work on the Platform implementation independently and, if it ends up being 95% identical to the Door code, refactor into common base class plus 2 subclasses as the end.

…

Before we start implementing platforms we need to go through all maps, identifying all of the doors and platforms that currently exist, and categorizing them according to size, type, and gameplay role in a spreadsheet. That will tell us what we can build as standard reusable meshes and code, and what will be bespoke one-off scripted events. There are quite a few M1 door and puzzle platforms which have NOT aged well which we’ll want to replace with modern puzzle designs.

For example: We can replace Colony Ship’s notorious platforms with mobile ceiling cranes for lifting cargo containers, requiring the player to pick up and maneuver containers to form a floating suspended “walkway” from one end of the room to the other, which they can then run across to the exit door. This honors the spirit of Colony Ship without inflicting the original’s atrocious gameplay mechanics on modern gamers.

…

Fortunately, we can ignore platforms for Demo. There’s only 2 minor elevators in Arrival’s service tunnel. We’ll replace both with ladders, which will look a lot better and eliminate user frustration waiting for silly lifts to arrive.

For now, let’s just focus solely on getting common doors and door behaviors right. Arrival has 2 standard types of door: hab doors (1x1WU) and service hatches (0.5x1WU). I will do some visual designs today.

Also take a look at Wheeels’s Door classes, which implement basic behaviors such as direct vs remote triggering, keycard activation, animation sequences, and collision detection. There may be better ways to build doors (I am no Godot guru) but it’s a useful reference to start from.

[Chaerulea]

Reportandome

[yaelatletl]

@hhas About the doors/platforms, we have designed them in a way that these will be useful for either, will be able to fine tune their behaviour however we need/please and will allow us to just drag and drop three nodes at most, then the mesh can be whatever we want and it should work just fine, don't worry much about it