Experimental dungeon layout for rifts

[immortius]

Overview

Introduces an experimental dungeon layout for rifts. Places rooms as branches, with major rooms separated by connecting rooms. By default there is a major room every 3 rooms along the branches, and at a major room there is a 50% chance of a second branch.

Usage

To test, modify a key with the command: /wotr riftKey generator setPreset wotr:dungeon. The size of the rift is currently determine by tier, with no limit although 16 seems to be plenty. At some size performance will tank/memory will be exhausted, but this is true for large finite rift layouts too.

The generation can be further finetuned with:

• /wotr riftKey parameter wotr:dungeon_rift/branch_rate <value> - how many branches from each main room, with fractional parts being the chance for an additional branch. Defaults to 1.5
• /wotr riftKey parameter wotr:dungeon_rift/main_room_interval <value> how frequently main rooms (3x_x3) appear. Main rooms appear immediately after the portal room, and then every nth room as determined by this value. Defaults to 3.
• /wotr riftKey parameter wotr:dungeon_rift/max_depth <value> how many rooms out from the portal room the branches will generate. Defaults to the tier of the rift.

Future Work

There is undoubtedly a lot that can be done to expand or improve this approach. For example, adding terminator rooms, improving the room pools, better randomisation of branching, optimisation of generation. The logic behind selecting an placing a room is fairly basic - more could be done here though it will add complexity and cost. Gameplay-wise having objectives inserting only into main rooms may be interesting. Having exit portals or teleporters between terminating rooms may also help prevent backtracking if that is an issue too.

[ImplementsLegend]

There's no vertical limit to the placement of the rooms so rooms can break through bedrock.

In other layouts this is prevented using RiftShape, maybe consider adding one.

There is also no simple way of explicitly adding specific rooms which could normally just be their own LayoutLayer.

Is there a reason why this can't be a layout layer instead? That would solve both problems.

I guess there might be some benefit of storing the rooms in a hashmap (to conserve memory) instead of a larga array as the other layouts do so maybe this should be split into SparseLayeredLayout and BranchingLayoutLayer.

[immortius]

Is there a reason why this can't be a layout layer instead? That would solve both problems.

I briefly considered doing a Layout layer, but it wasn't clear how this approach could mesh with other layers. Assuming the portal room continues to use the PredefinedRoomLayer, how would a branching layout layer discover the portal room to branch from? What would the layer do in the presence of multiple rooms created from other layers? It was simpler to do as its own thing, especially since I don't know if it is something we'll want to keep.

Admittedly I'm muddling through things a bit, since there is no documentation.

There is also no simple way of explicitly adding specific rooms which could normally just be their own LayoutLayer.

I don't feel that approach would work anyway because the room wouldn't necessarily end up along any of the branches (assuming using a PredefiniedRoomLayer with fixed coords). Would need a different approach, unless I'm missing something in how layers work? Since this is PoC I don't think it is needed immediately.

I guess there might be some benefit of storing the rooms in a hashmap (to conserve memory) instead of a larga array as the other layouts do so maybe this should be split into SparseLayeredLayout and BranchingLayoutLayer.

I mostly used a hashmap because I wasn't going to try and touch the array approach, since it is entwined with the finite rift layout. It would probably be good to encapsulate it into its own class.

I'll probably just add some height checks to canPlace for now. If there is desire to continue with the layout after play testing we can look at refactoring it further.