Endgame #269
Comments
|
For the infinitely-scaling Planes, it would make sense for them to be either very long Dungeons, which already have the infra-structure to somewhat maintain and somewhat vary the initial floor's Lore as presented to the player's consideration or establish a similar architecture for Wildernesses (inheriting Dungeon Tables) - this would entail very long runs of the same theme but the player should be able to choose to go back to the Tower once per level or even enter a completely different (also |
|
Given that Dungeons and Wildernesses are permanent for as long as wanted, it would be fun to have the Tower's portals refresh in random intervals (say a 1 in 7 chance per day each) - this allows the player to come back out and in again at their own leisure but still working on a clock if he wants to go deeper. It would also add extra benefits to unlocking new Transcendent Doors, as having to go through previously-cleared levels that have been cleared of rewards but facing the same Encounters as before might not be very appealing so players with more unlocked Doors would have their portal choices refreshed more often with choices to begin runs anew. |
|
Given all the fields in Branch that can be modified, shouldn't be too much of a hassle to give players end-game exclusive items that allow them to set up their own Custom Branches (perhaps as a third branch for most endgame Branched Dungeons)? The main question would be how to introduce that as interesting, strategic, limitless gameplay: should players need to collect a bunch of ingredients (wilderness example: Map type + branch 1 + branch 2 + template + chest type + ...); or simply add/replace a branch to a Dungeon; or do you add individual items (like a new Reward type); or do you find entirely custom Dungeon Keys...? Regardless of mechanics, a fundamental question is whether these items are part of a setup which then generates a Dungeon ahead of time (makes more sense) or whether you apply them to an existing portal which is then regenerated (requires less UI work for the setup process). Perhaps the most interesting idea is to have procedurally-generated custom Branches, that inherit one of the main types ( The Craft UI #197 could be borrowed to fit custom end-game Branch crafting. A player would start with a typical Branch key (possibly pre-randomized to a small extent, ie. Another idea for "corrupt" Keys is having them pick at random from 2 different branches so you could end up with a Whatever method is used, there is also the question of scaling: should these Keys be static (have a level) or dynamic (endgame Dungeons are generated according to current Squad level). Either way, endgame consumables could be used to make branches harder or easier according to a player's desire. Keys are probably not a great name since it clashes with existing items - but still doable as Astral Keys or something else fluffy. |
|
Expanding on the previous comment, an interesting approach would be to have a Library and Books - which would work as the aforementioned Keys but on a permanent basis instead, being susceptible to consumables/crafting as Keys would. This would allow players to pick-and-choose which content to play and alter, perhaps creating a more engaging endgame that way. The initial Books could be Planes, with each Plane featuring fixed entrance to Branch Dungeons, which can be added at will to a Book through the right consumables. Every time a Book is altered, it is generated again from scratch with all the previous and newly-applied fields. On a plane or its Dungeons, there is a 1-in-4 chance per floor that Ross, The Traveler spawns. He's a one-time Feature that hands the player Ideally as a 2.0+ feature, the Books would be shown as scrolls and their features would be text-based rather than listings of features - so a Book with the title "Dense Forest of Water" would have a sentence saying "Partially submerged, aquatic creatures thrive in this region" (instead of a simple "Branch: Water" display). The best way to approach this would be to have A major open-question here is balance: is each book a fixed level and if so how to create appropriate challenges? Is it dynamic level each time the world is generated and what is preventing a player from getting in with a smaller party then out and back in with a more powerful one? Can the player affect the challenge level through endgame crafting consumables and how should that work? |
|
As far as endgame crafting consumables go, an interesting idea would be to "craft" unique bosses or encounters to be found in a Plane. It's a bit off-track to implement and as far as in-game logic goes (if it's an encounter on the encounter table, does it happen multiple times, then why is it a unique NPC, etc)... but still an interesting concept that could generate cool interactions and goals. |
|
The way to scale Books would be to have EL go up by 1 every time a player adds a customization to one of them (thus regenerating the book). This allows players to self-regulate their pacing while allowing content to "infinitely" scale. The difficulty would be shown at the end of the book as a note: "Entering this world is a moderate challenge for the current party. Adding a new paragraph would mantain it a moderate [make it a difficult] challenge." Players should always be able to get brand-new books, clear book from doing end-game content but ideally you should also be able to clear a book in case you lose a party member and the content becomes to hard to continue progressing as-is. This is probably better done through some crafting item as not to bloat the basic interface more than required - ideally one of the uses of a given crafting item. |
|
If books are to be used at end-game, it might be interesting having each "page" be a chapter of a larger book - in other words have a "book of books" (a page being a book in the nomenclature previously discuss). This would allow for a lot of interesting avenues towards exploration and progression, with a mix of generated and static (previously generated) content as pages are added and rewritten as new characteristic/features ("paragraphs") are added. This also solves the problem of "what if the player loses power and can't complete end-game content anymore" as each page could be a certain difficulty, with later chapters being harder - making adding new chapters and refining old chapters to a tee the main end-game loop, except being able to do it with multiple books at a time (or focusing on only one if the player prefers that over min-maxing). Technically speaking, whenever adding a new page to a book, at least the previously-last page would need to be regenerated to guarantee a Portal is created to the new page's content. Maybe this could be avoided by doing something like dropping the new Portal (or replacing a an unimportant feature such as Decoration or a specific new placeholder feature type) into the previous Map and randomly "undiscovering" 50% of that map (including the new Portal tile) as to not break immersion that the player would know where the portal is beforehand if it falls on a previously-explored area (although if he's "writing" the area, that might not be such a problem). If the Placeholder route is used, it would also make more sense that both the player and the in-game characters would known beforehand where the Portal would be. One problem is that adding new pages but having to play through each of them to get to the latest one could quickly become a chore. One way to try to avoid that would be to add not only a guaranteed Portal to the last area but also have a chance to add a new Portal to any previous area or maybe one guaranteed Portal to at least one of the previous areas. This would allow players to "hop" from the beginning page to later pages through those "shortcut Portals", alleviating the problem while keeping consistency. |
|
Achievements: challenges and artifacts as an end-game system. Achievements are a big part of how some people interact with games and it would be nice to have a system for that built into the end-game. As a roguelike, Javelin can also leverage semi-procedural Achievements per-playthrough, even if that's only selecting from a pool to generate something like 20 achievements per playthrough, or organizing them in a tree structure that players can plan and plot through as an endgame roadmap. As such, the game could keep track of "lifetime" achievements and "playthrough achievements" that nudge players to get out of their comfort zone and build towards facing Epic-tier content that they might not do naturally without an ad-hoc driving force. Both types of achievement are one and the same: completionist players can just tick all the boxes to get their "platinum" badge and/or engage with challenges as endgame. Rewards should also match the difficulty of challenges: in the 'tree" concept, nodes could be both challenges and rewards so players can uncover and navigate accordingly. In a way, challenges would be the end-game equivalent to quests and perhaps those could be leveraged as well (when generating an endgame scenario, its quest equivalent could check for goals to generate procedurally). Something like "complete 2 goals to have a reward spawn in this map" checklist per page of a book, with the first goal and reward seen beforehand (lets the player decide if they want to engage) and second goal initially hidden (drives the player towards some risk since half the work is done and the reward is "just there"). The "2 goals 1 loot" (lol) format also allows postponing the reward so that it can be significantly stronger than normal encounters or even a single challenging one. One way to leverage this would be to categorize every Dungeon Feature into the current quest types (implying a non-functional Feature subclass hierarchy for organization only):
With these categories, every end-game Dungeon Feature can be easily looped and given to a consumer that will produce Challenges to draw from, after an endgame area is generated. They can easily be sorted by If a per-page format is used, it allows for utility rewards that let players tune their own challenges and rewards - things like "this book now has 20% more creatures" (cloned at random at the beginning of any encounter) or "all creatures get upgrade x", which increases the challenge and rewards naturally and are easy to implement as Mutators. As such, a The per-page format could also allow the player to reset their challenges and rewards in the same way that pages would be reset, as well as skip challenges in favor of later ones. Major points to avoid with this idea:
Perhaps a good balance would be for the "achievements" to count only as the material rewards (Artifacts, for example). This would mean something like only one new "achievement" per Branch released - it doesn't solve the containment problem but definitely gives it a hard limit. This can be paired with "static" achievements like "complete x/y achievements in a single playthrough" that can be one-and-done-forever deals. "Get to a level X dungeon floor". On the topic of chaseability, here are lazy but good-enough examples for other games:
There is no reason why both of these can't be (quite easily) implemented as a single endgame gambler feature ("Altar of pride and accomplishment"), with both modes available to the player. It also needn't be said that this would be a core feature not only for completionists but every player too: got an Artifact that doesn't really fit your build? Go with #1. Really want a specific item that would be perfect for your party? Then option #2. In this case, we are stretching the definition of Artifact but there's really no reason not to have it mean "any one Epic-tier Item". As Artifacts are extremely rare, being able to use any item in the Altar would make much more sense - but that does leave the question of how to handle Artifacts proper, as they don't usually have a price value associated with them. Perhaps one idea is not to use Artifacts at all but unique Epic-tier Items as Artifacts. For the non-material artifacts, they could likely be given in the form of endgame crafting reagents (and probably not as achievements as they would tend to be very procedural). This would mean challenges can leverage a gold pool of two challenges (plus one moderate for finding the spawned reward as a treasure from) but not divided, rather chosen by the player in an either-or scenario while perpetuating the end-game loop itself. In the end, none of this really could or should be defined before having a working endgame and seeing how it plays from a purely functional point of view and properly assessing its strengths and weaknesses. However, it doesn't hurt to keep it in mind throughout, not only for how important completionism is for some players (and how it can deeply make the game more strategic by proposing fun, interesting challenges players wouldn't want to do without a reward associated to it) but also because it can be a major component of the endgame systems as well. |
|
Transitioning into Endgame, Artifacts should be removed from Temples and into Branches (one-to-one or one-to-none). Instead, Temples would provide an Ascension Key, each of which progressively unlocks access to Endgame features (for example: one craftable Book per Key, with the first key allowing access to everything else in endgame). There is ample space for Epic-tier Items to be generated as usual (and expanded too) normally in Endgame dungeons. Artifacts should be a Challenge reward, on something like a 10% chance per Page per depth deeper than 2, or EL higher than 20 (so something like Some of the existing Artifacts might need to be revised for this new Context. |
|
An end-game Shop would probably be required as World Shops are not designed for that level of power or gold-sink necessities of Epic-tier and beyond - while I believe very expensive Items already exist and could be introduced as needed also. Epic Items would still be very much available while exploring end-game areas, as well as NPC vendors inside them but that might not be enough and expecting the player to leave, travel the World map and struggle to spend gold is hardly ideal. Of course, a solution would need to be tailored to the state of the game once endgame is implemented. One idea would be to have a demi-god vendor available as soon as endgame is reached that will hang around with extremely expensive items (even by Epic-tier standards), knowing that the player is one of the few clients that can afford him (even if rarely). When he completes a sale, he will leave for a week or so to approach other clients of the same caliber and return later with a half-refreshed stock. Perhaps NPC vendors and purchase opportunities in the World are enough but having a true Epic-tier-exclusive vendor as a guaranteed ultimate gold-sink could be necessary. He could also facilitate the hiring of high-level creatures at exorbitant prices (like a year worth of daily wages), as new hires are one of the best ways to gain power at end-game, as much as normal progression is and also for the necessity of replacing fallen members. |
|
The endgame could (should?) have an emphasis on free-form party composition, theory-crafting and progression. A lot of this potential is granted:
However, the crux of the question here is: how to promote anything other than fully resting a party and always bringing your own entire roster into endgame content? This is not only often the best way to play the campaign but some of that content directly aims towards mass-combat making it harder (or at the very least less fluid) to bring a typical party of 4 into combat against an actual army. Here are some ways to gently nudge the player towards experimentation and problem-solving:
However, this may be too subtle and some heavier handed ideas can be experiment with - hopefully always through incentives so that no playstyle is penalized (if a player really grows attached to a specific party or only wants to solo, they should theoretically be able to). These are very artificial and should be considered carefully, favoring more elegance:
One example of a solution would be: have the vendor also offer timed missions, with a set number of unit slots available, perhaps even specific units required (of if not units directly, certain slots that can only be filled by a subset of units like "spellcaster", "agile", etc). These missions would take longer than normal content but remove said units from the roster (for a week, for example). This could even be a way to integrate Haunts and other non-Dungeon content as those are harder to generate procedurally. Javelin's end-game could be only an extension of the campaign, offering more long-term scaling within the same parameters as the game World but that would be a missed opportunity. The World tries (to some extent) to be a simulation/sandbox but the endgame can drop the pretense and be more gameplay-focused and theory-crafting intensive. |
|
The previous comment brings an interesting idea of "transcended" character (which is thematic enough). Perhaps the rarest end-game currency should be a Transcendent Ruby used for:
Keeping note of which This is a cool idea for many reasons, including the making of "timeless legends" within a player's history with the game, the achievement of making permanent progress in the endgame even if a player loses the game... this would be like the endgame's endgame in a way. Problem with that is having updates break what can be a long-term time investment by players, as supporting model upgrades would be a prohibitive time, energy and technical debt for the project. Maybe the way to handle this properly is when a schema change is detected tell the player "this save game is incompatible, go back to the old version or start from the beginning yes/no". |
|
On the topic of incentivizing different end-game compositions, a good way to enforce this with the OGL ruleset is through alignments. For example, if different guilds or gods offer challenges to do some content in a floor but only if there every unit shares at least one alignment axis with them (neutral in any axis will count as equal long one of the is neutral) is a way to perform allow for a mode of play that is not too limiting or restrictive, with nine different variations built-in and that works in tandem with planned endgame content. For example: when engaging with endgame content, each God can offer one of a couple challenges. The true-neutral god of balance can bless this run with "casts Heroism on all units of whichever side has less units in the field" (randomly chosen out of two alternative blessings/challenges) or the god of protection will cast mage armor on any wounded unit. This can affect every run without modifying content (only in-battle Mechanics) and the player can choose from a list of options - but only if the alignments are respected, so he may need to drop certain units to get the desired effect. Chaos-good gods can convert gold to items randomly, etc. A UI should allow players to "apply this modifier, confirm that these units will be removed from this run' as easily as possible. Every time a run is completed: if a blessing is being offered there is a 50% chance to drop it, and if a blessing isn't offered there is a 1-in-4 chance that one will be generated. This aims for two possible blessings per run, tending to be more than that in practice (and with a reliable 50% chance that the blessings will remain for next run so player can plan accordingly). The problem with this math is the possibility that no blessings are generated (or none that interest the player) but that is acceptable as it's strategically interesting to bring your full roster sometimes too and try to optimize that particular scenario (during and later). Maybe there should be a secondary goal to make blessing interesting too so that players will always prefer doing it. One example is each god being tied to a particular chest type. With the blessing, select a new epic item from the pool. In each fight, convert 10% of the gold reward into a "donation" towards the god. After the run, the player can use that donation to redeem the item if it's meet its value, or gamble on a chance to get it. If they don't gamble or if the value in donations is over 100%, it is kept for the next run (or blessing and item reward generated). In fact, the gold conversion could be 100% instead and completely replace end-game shops with this. Technically it should be easy to allow players to select multiple blessings per run, as long as at least one unit meets all criteria. This could promote "good-only" team for example but with only 2 blessings at-most per run as a target it would mean only one choice every other run and with gold being useless if the only shopping option is through this system, it would actually decentivize players from doing that - or at least having both a "good" and "evil' team, which is fulfilling the purpose being discussed here in previous comments - and if there lawful units on both sides, they can join each other when a lawful blessing is available, allowing (thematic-enough) intermingling. This should probably be domain-based rather than god-based #205, as long as a decent balance of domains-alignments can be found. |
|
Avatars: end-game craftable Feature that is similar to a Boss but instead generates single-creature combat of epic level (probably by applying every preferred instead of only one, until the CR target is reached). The reward can be an Item that permanently upgrades the stats of a creature or similar (see #343). Monsters are picked based on their alignment ("Avatar of Domain") and powered up the page's EL for a Deadly encounter. If one avatar cannot possibly by powered more, add more avatars (or maybe start with a To distinct them from other inhabitants, maybe add a background to the monster Image. It can be generated procedurally and on-demand since it's just combination of the monsters image a background halo. |
|
Static endgame challenges are important, rather than only scaling procedural content. This ties with the idea of trophies as well. It's probably way too soon to think about things like domain-based Avatar fights for EL levels 15-20+ but they are an example of such a thing that can be procedurally generated. They can even be further scaled with Avatar tiers, if the game ever reaches a point where EL30+ is wanted and feasible. They can be procedurally generated but are static in the sense that a player can measure their progression through end-game in. They are also a far simpler approach to trophies. |
|
To have a little more depth and theme in each book, every new page could inherit some or all properties from the previous page. For example, if a page has a limit of one Branch property (let's say Template T, Mutator M and Feature F), those could carry over to the next page once it's unlocked - or maybe the next page is generated automatically by reaching the previous-last one, with some of those properties and the rest open for crafting. This adds more strategy in prioritizing which books to craft and what to focus your crafting materials in. It also enforces more of a theme to pages in a given book rather than each page being a blank slate. Strategy-wise it gives more long-term impact to choosing to invest in which pages of which book. Do I fill-out previous pages' missing properties or build a strong last page so that 50% of the modifiers will carry-over. Or do I spam the same modifier on every page, if a The UI should help in this regard in some way. The simplest way would be to prioritize empty page properties first and last page before previous ones. Going for immersion over min-maxing is the best approach, so sensible UI defaults is a good tool here. This would basically make each page its own custom Branch, with new pages being generated off of previous ones' fields. |
Javelin could have an end-game location in the more traditional "infinite content" action-RPG sense. The initial concept would be a place called "Tower of Transcendence" or something similar which would have 7 doors and behind each a Portal #91, starting at Encounter Level 20. These portals would themselves have other portals nested inside, each a level higher with each step deeper - challenging the player to go as far as possible with each run and return to safety and training as a strategic choice.
An implementation approach that could override both Portals #91 and Branches #254, these portals could be Wildernesses variants - which are perfect for exploration and mix of open-world/dungeon gameplay, with tons of contents from existing Maps (with basic tile swaps); custom map generation or even using Haunt maps/monsters/Templates #207. Wildernesses can easily be expanded to generate deeper Portals and are already fully implemented in the codebase (including saving functions).
Actually having both Wildernesses and Dungeons would be ideal as not all Features are shared between both.
The Tower itself would also be a Dungeon/Wilderness albeit a static one with fixed layout and no Random Encounters.
The way this could realize #242 is that the player could gain access by finding a Transcendent Key but then only one portal is available for each run - finding more Golden Keys would unlock extra doors permanently and as such give the player more strategic options of how to approach each run depending on his composition. The strategic element would probably come in the form of having a full (or partial) Lore listing of the contents of each Portal's destination - allowing the player to both focus-farm rewards (#256) and avoid particularly harsh Monster/Kit/Templates for his particular team composition and weaknesses.
For this idea to be effective, the portals would need to: 1. show the relevant Lore ahead of time; and 2. be generated daily or weekly to provide that "infinite strategic gameplay".
The Lore feature could also be leveraged for a "scavenger hunt" (as those found in JRPG randomizer ROM hacks) in preparation for end-game. By customizing how
Dungeon#loreworks for the endgame Location, it could show where to find the Transcendent Keys - not only in Dungeons like most Lore notes but even as a grand Arena prize or epic Haunts, etc. The Lore Note instances could even be hidden, one or two, inside the locked Transcendent Doors, so that unlocking each door gives another clue or two towards the next Key.The text was updated successfully, but these errors were encountered: