Open tukkek opened 4 years ago
There's a subset of this (Monster selection) that is common to Planes #91, Templates #207, Haunts #33, Temples, NPC Generation/Kits ... it would be nice to have a common abstraction pool that all procedural systems could drawn upon.
Once this is ready, the Deep Dungeon could be a linear, 1-20 levels of a random assortment of branches (1 level for each).
Here's a Branch architecture overview: any Dungeon instance can have a Branch prefix and a Branch suffix - which are functionally identical and serve the same purpose (to "spice up" a Dungeon), other than having a proper prefix and suffix name ("Fiery / of Flames"). With the interaction between two branches per branch dungeon, there's already more "free" variety and depth than many game's static approaches to Branches and with expanding Branch implementations over time, there's also potential for emerging gameplay, not to mention hypothetically limitless strategic scenarios.
Any Dungeon or Wilderness (other than Temples) can be a target to have branches and maybe even a good implementation start would be to convert current Temples to Branch dungeons (the one exception to the rule of each Branch Dungeon having two affixes). As such, you could have a "Drowning Keep of Flames" or "Evil Rugged Hills of Wind". The only limitation being no repeate prefix and suffix (it would functionally be the same as having one affix and defeat the purpose of variety).
Since Portals #91 aren't in the game anymore, they can be reintroduced as entrance and exit Features to Branches inside Dungeons and Wildernesses. On the World map, they would be largely clashing with Temples for Epic-tier content and also redundant if they are also generated inside dungeons and in endgame #269. It is important that inner Branch Dungeons are also fully generated at start-up, recursively. Branches inside Dungeons could maybe be mapped as a Tier lower than their parent Dungeon and for both Branches inside Dungeons and Wildernesses, they should inherit their parent's base type. A differentiated Portal image would probably be required to mark the exit out of a Branch.
Branches inside Branches should share one of its parent Branches for thematic and coherence reasons. Treating the initial floor as a lower floor of the current floor, inheriting some of its properties might also be something to experiment with, adding even more of a sense of "it's the same Dungeon but it branched in mysterious ways" - but it might not be worth the hassle if it's non-trivial to implement. It would also help absorb any Difficulty impacts when it comes to the Encounter table.
One exception to the "no overworld portals" argument would be higher-level Wildernesses. They aren't very interesting as-of right now (they're just more exporation-driven Dungeons with less features) and were designed more to increase the amount of low-level-safe content for early on. Any EL 15+
Wildernesses could be replaced seamlessly by World Portals.
For inner Branches, a cumulative 1-in-4 chance per Dungeon floor of featuring a Portal could be the best approach here, allowing for good amount of Branches but not infinitely recurring - and in this case, they could be deemed challenge areas, featuring a jump of +1d4 encounter level
(adding the strategic options of making lower-level content suddenly relevant, pushing builds to their limit if appropriately matched or "come back later to tackle this" if it proves too tough to clear).
Branch #many of the below are optional and would be processed mostly during the base Dungeon generation
String walltile
String floortile #with 2 branches and one base dungeon, that's 9 tile combinations even for identical dungeon/branches!
List<Template> templates #a random template per Branch is added to each Encounter's Monster
FightMechanic fightmechanic #both mechanics would be active in all Fights, if present, for maximum gameplay variety
List<Encounter> encounters #more encounter options on top of the base Dungeon
List<Class<? extends Feature>> features #commonplace Dungeon Features for the branch - promotes new content too!
List<DungeonMechanic> dungeonmechanics #things like the Temple of Air's wind throwing Squads around
Map fightmap #map to be used for fights and even Wilderness dungeons themselves - promotes new content too!
List<Class<? extends MapTemplate>> dungeontemplates # to use only those from branches if possible, see
See also #207 #272 #263
Hopefully this a high-reward approach with endless potential that leverages a lot of what currently exists in the game without adding too much complexity (other than interaction between already-existing features). New Branches content could become an "entryway" for adding new Maps, Mechanics and Templates to the game that trickle down seamlessly to the base game - perhaps even replacing Haunts at some point as you could generate them semi-dynamically from any Branches that feature a Map and a selection of Encounters!
If any Branch has a Template, the Mirror Feature could instead apply a template to a Squad member - similarly to Learning Stones, as long as the unit has positive experience. The best way to go about it would be to have a Mirror variant, visually and a whole new Feature instead in implementation.
One concern is that this would be at its best if there was a small chance only of such a Feature generating as even one is more than enough per Dungeon and having several would be a waste and even if all used, not interesting at all strategically (a whole Squad with one template is a lot less interesting than a varied one). Maybe generate them on Dungeon#generate()
, with a recurring 1-chance-in-4 per level? This would be very ad-hoc but much better than risking having a dozen per Dungeon, making them not only largely useless but also taking away from much more interesting Features that could instead be populating each level.
Having Branch#trap
would be a great way to drive content creation but the problem is that Traps are easier to generate procedurally (by types of Trap rather than instances). Having each Branch list a Spell#iscurse
and #isrune
would be more straightforward but it would make each Branch extremely tied to certain level ranges (around the Spell caster level, probably) which is also a no-go. Some sort of scaling between "cast trap X times" could be a way out but that's got issues of its own too.
All in all, having Traps and Spells tied to Branches, as much as it would help define a process for creating content, is probably not that great of an idea.
Branches could have a permanent Condition
as well - either giving the Squad or every enemy a buff or debuff at the start of battle and adjusting EL accordingly (doing both at once might not be a good idea as applying an effect to a 3-man-squad and 20 enemy units is hardly balanced). Even better, this could be a Mechanic subclass, as it's an easy way to create mechanics that doesn't require extensive coding and testing for every branch.
When applied to enemies, this is almost a Template so ideally affect players primarily (as buff or debuffs) as that is a novel idea that works as sort of a temporary template for player units (permanent while inside the branch only).
Some care might be needed to not overlap this with Conditions players may already have from other sources. One way to do that is to create a wrapping Condition that checks for the original one before applying and is safe to remove after every battle.
This page rates a magic spell trap as a CR 1+Spell#level
. Some metamagic feats may be "added" to increase or bypass saving throws if wanted. This would then modify every encounter level by being a "hidden unit" - hardly as simple as plus or minus to EL but a good starting point to determine balance.
It that's a buff to players, this is easier to determine as it's a one-time change to the party EL that can be translated to EL generation on a one-to-one basis, with no saves involved, etc. Doing this dynamically might be an issue though as the resulting ELs might be hard to predict and vary wildly (a Level 9 spell applied once to a typical EL1 group is a +9 to overall EL). The fact that units could die and scramble the calculation midway through is also a problem. The calculation could be done with an "average party of four" in mind but level is still an issue as Branches should not be tied to specific Encounter Level ranges (short of the flat EL bonus/penalty) - it would also botch balance if the player enters with 20 mercenaries other than the "average" baseline.
Another approach is to affect equal numbers of HD on both sides and have it as a EL+0 adjustment but that might not be balanced in practice (a level 9 warrior with a +1 buff may be more scary than 9 level 1 goblins with the same buff)... or the same with a certain number of "casts" per side.
Some concepts:
Swashbuckling branch of plunder: a branch for aquatic and neutral-or-evil humanoids. While a pirate Kit might be in order, a simple rogue/fighter combo would also do the trick. Mutator is guaranteed heavy storm and treasure should be a Pirate Chest with only gold coins.
Obvious Haunt choice would be the Sunken Ship.
Cultist branch: humanoids summon demons or devils. Some sanity/fear fight mechanics would be interesting.
FF14's Palace of the Dead has enchantments that are very interesting approaches to Fight mechanics (Floor Enchantments): very small changes to combat rather than intricate, unique full-blown mechanics.
While this is unbalanced to apply to both team of unknown size, they are also minor enough to count more as "tactical flavor" than actual mutators - and as such it's not too game-breaking to assume that they will at some points benefit the players more and at other times benefit enemies more (usually whoever has the most units will be the more affected).
This is a great philosophy for "quick and cheap" fight Mechanics that are easily applied procedurally across the board and even among themselves - with the caveat that they should all be fairly minimal in their impact.
Other sources of inspiration that can be down-sized to this scale:
Corrupted laboratory: a mix of constructs and devils (lawful evil). May be a sub-class of Forge/Foundry (planned).
Corrupted conflux: mix of elementals and demons (chaotic evil). May be a sub-class of Conflux.
Faded branch of shadows:
There is a Dark branch already. Check if this can be merged with any of missing characteristics there.
Mountain Ridge map could work as a "volcano bridge", with an entrance/exit added on the borders and by changing the outer blocked terrain with lava (flooded tile that deals energy damage to units standing in it). Similarly a "void bridge" could act similarly but with negative energy pockets (clouds) growing and shrinking and rotating, dealing pure damage to enemies inside it.
To further differentiate the maps, besides tilesets the extremes of the bridge should be thematic and distinct: lava bridge being blocky and sturdy while void bridge would be slick and edgy.
Desert mechanic: Logged. each turn without moving diminishes speed by a certain amount, making the next move cost more (up to a maximum of 1 full-action after 3 turns), which removes the condition.
Rodent branch of mice: generates large packs of rats (3d4
?), all leveled-up in the same Kit. Should be a way to enable any Monster to use any Kit that can be re-used elsewhere (in particular other overlapping Branches).
The Dungeon Feature can be a Rat Nest where you have a chance to attract a generated rat mercenary with food (something like $1) or else generates a brand-new Fight instead.
Dungeon Floor Tile can be corridors inspired by hamster cages.
Add Barton as a Dungeon name.
One way to implement the ever-present roguelike feature of dungeon branches would be by revamping Dungeon level encounters with a specific selection - first based on the Terrain the dungeon is in, secondly a random monster type, subtype, trait, template, etc, creating a subset.
Even as just the subset Terrain, one monster type and implied EL range, this basic implementation would be plentiful in creating memorable areas, unique and thematic in themselves - and also easily verifiable, as the the Encounters can be generated, validated and possibly discarded/replaced/expanded if it isn't fulfilling the amount of expected Encounters.
The best approach to number of traits (like monster type) would probably be the
1(+1 while 50% chance)
, as it would assure half of branches are very (even narrowly) well-defined but still allowing the possibility of pretty crazy combinations to be generated.As a first approach, it should be simple to simply replace an entire dungeon level as a branch level. Later on, they could be added levels (preferably smaller than the original and interconnected to other levels); isolated or connected sub-dungeons or even a rare Dungeon Feature!
The best approach would be to have self-contained Dungeons accessible via Dungeon Features, similar to Planes #91 in the over-World. That way, branches could possibility contain other branches, ad-eternum. If that approach is taken, it would be a good idea of allowing for a
Dungeon#parent
field, so that features that would lead outside could instead lead to one of the parent Dungeon's levels instead. Independent dungeons would also allow some flexibility as to how to stylize the Dungeon's theme - perhaps using the floor tile of a Terrain-appropriate map?Another important thematic decision would be how to name these branches ("are you going to enter the spider cave?"). It should be a mix of spoilery but not completely spoilery and also theme-appropriate without adding too much complexity. At first the obvious
[one trait] [smaller dungeon type name]
approach would be ideal but certainly something that can be further experimented on.As far as Dungeon Tables are concerned, a branch's top-floor level could take the middle-ground approach of inheriting their parent's Tables with 50% chance of wiping them instead (the other 50% being copy-and-randomize typical approach). This would allow for the average case of oddly-similar but still different, while also transparently allowing for 100% similar and 100% different approaches. The exception would be the Dungeon encounters, which at first should always be replaced with Branch encounters - but even those can be experimented with.