Ainamacar

Either Sawyer can't talk about it in-depth because they're still experimenting with different weapon effects and nothing's set in stone yet, or he just enjoys being a tease. Probably a bit of both. Sawyer a tease? Never.

I look at it this way: We've had our soul stolen, are (presumably) doomed if we don't get one back, and are going after a reborn god to get it. PoE2 is BG2 inverted: this time we're Irenicus. I can freaking live with that. Plus, the average Dyrwoodan won't think the Watcher is a chump for being level 1. No, what they see is a person (or group) who recently rose from nothing to greatness who has had their soul sucked by a god and, perhaps uniquely in a trail of desolation, survived. Now the Lord of Caed Nua is alive, angry, and armed. Sane people won't mock the Watcher, they'll get out of the way. That is leaving a mark, no matter what the XP box on the character sheet says. Finally, I think Obsidian has the opportunity to do something interesting with the original companions. Namely, while some are present at the beginning (thus set back to level 1) others may be encountered later in the campaign in their high-level forms. Even if they were just NPCs or temporary companions that reinforces the continuity with the original story, and to me would strengthen the sense that the level reset is a vital part of the story rather than just a mechanical contrivance.

I cannot even concieve of how an RPG like PoE (or Torment or BG2) could be "too verbose." I wonderingly pondered the prodigious length of paradigmatic RPG classics like PoE, Torment, and BG2, but within this honored scope found nary a jot, word, or phrase the paring of which could yield (however faintly!) an overall improvement -- and it is truly beyond my ken to imagine such a thing. The problem with verbose writing isn't necessarily length as such, but a lack of economy. I'm not mocking you, because even though I disagree with your statement you expressed it concisely and sufficiently. The travesty I wrote, on the other hand, desperately needs an editor. Pillars wasn't nearly as bad as that, but in my opinion an editing pass with an eye for unnecessary things would have definitely improved it.

Take a look at the spreadsheet, the 50% from graze is taken into account. I'm very much OK, in the context of offense, with Dex granting less marginal dps than Might if there is an interesting tradeoff with status effects. As I understand it, most status effects are applied (or activate the separate attack to see if they apply) as long as an attack doesn't miss. Thus, reduced average damage for increased chance of applying a status effect. That is a classic tradeoff, and one that has to be managed carefully since in some games lockdowns make dps ultimately trivial. So, for me the question is whether the damage vs. status effect trade off is, on average, both significant and interesting. There is no objective "correct" balance for damage vs. effects, and in practice it can depend on play style. For example, some characters might go for all dps all the time, while others try to apply status effects much more frequently. One could play around with how grazes impact effect duration, for example. (I'm unclear on whether it does at the moment.) Someone might reasonably give up nontrivial dps if they can, on average, expect to apply debuffs more reliably.

When at the level up screen it does not appear one can cancel it and return to the game (no cancel button, Esc does nothing, etc.). I presume this is a matter of interface design, not a bug. Being able to cancel is very useful for when wants to see what is available at the next level without committing to leveling immediately.

Both I and a friend had the font problem with several recent Unity engine games (among them Wasteland 2, Hearthstone, Shadowrun Returns: Dragonfall, and Forced) before managing to find a solution. In my case the offending font was UNCL.TTF, but when I went to the Windows font directory it wasn't even listed, and some of the font management programs I tried were also unable to detect/delete it. The trick, it turns out, is to mark the directory as writable first. 1. Open a command prompt. 2. Run "attrib -r -s c:/Windows/Fonts" (or use your equivalent fonts directory) 3. Delete the offending font or move it to another directory. If it's not UNCL.TTF for you, look in the log and dump files for clues. 4. Run "attrib +r +s c:/Windows/Fonts" to return the directory to its original settings.

I don't think the point is making kiting invalid, it is making sure it has some tradeoffs. Remember, in the IE games if your hasted archer isn't completely blocked off he can waltz past 10 melee attackers while flipping them individually off in the face, and be fine. In other words, kiting was often *so good* you could succeed without actually being good at kiting.

Think this is a great way to approach one of the qualitative aspects of melee combat, or at least fantasy melee combat. I dabbled with a similarly stateful mechanic in a PNP setting, but the maintenance required at the table ended up outweighing its benefits. After all, given {k, m} combatants partitioned into two teams and assuming engagement is directed (i.e. engagement is not necessarily mutual for any pair of combatants), there are 2*k*m individual engagement states to track. Even though most of them would be trivially non-engaged, that is still a lot to worry about. Perfect for a computer, however, and as long as there is clear feedback from the interface the user should have no trouble seeing when engagement is a consideration. One could probably leverage such a system to build a lot of depth. Some possibilities might be: 1) Special engagement zones. Perhaps reach weapons engage at range but not right up close, while dagger wielders need to be glued to the target. Thus, different combinations of weapons will tend toward different equilibria in terms of effectiveness. A character dual-wielding a one-handed spear and a dagger might have a wide range of engagement at expense of a particularly deadly point, while someone with two longswords might want to stick carefully to a moderate distance. Depending on what the enemy is wielding this might lead to quite different considerations, and it would mean that a primary consideration for a weapon system is not just the target's armor but also the weapons they wield, which has the potential for more interesting tradeoffs. One could tell characters to focus on maximizing damage by engaging at their optimal distance, focus on minimizing damage by attacking from where the enemy's weapons aren't so effective, or any balance in between. This needn't be an exercise of position micromanagement, just let the computer calculate or move toward an equilibrium based on what the targets have and how they are told to attack, but give the player high-level control of what they would like optimized. Or possibly not in the case of raging barbarians, taunted/bluffed/intimidated characters, and so on. 2) Various melee abilities when creatures are mutually engaged, which is the essence of dueling. 3) Various abilities when only one creature in a pair is considered to be engaged. The notion of the sneak attack is often that the attacker has engaged the defender, but the defender cannot defend effectively. Ganging up on somebody would be ideal for the rogue, but a fighter or other character that learns to engage many creatures would eventually be less easy to harass in that way. 4) Smart ways of "passing" engagement between allies, or abilities that depend on allies both engaging the same target. 5) Other notions of engagement that rely on the same basic idea. For example, when can a rogue hide? Coming from D&D roots, usually the answer is when no one is watching them. That is a sense of visual engagement, which could potentially be leveraged for skills, spells, etc. 6) A primary utility of some summoned creatures might be as a means to create engagement, rather than to simply do damage. Since balancing summons is always difficult anyway, it might be nice if at least some were less about doing or soaking damage and more about creating opportunities for those things. 7) Elaborate traps could "engage" characters in a similar fashion, which prevents, limits, or locks-in the means the creature has for escaping the trap. If engagement is passed around creatively the party as a whole may have to adapt their escape strategy. (No idea whether this would actually work.) Anyway, I look forward to seeing where this mechanic is going.

Very informative update, thank you! I think the three-tiered inventory sounds wonderful, and I like that it permits gear strategy at both the intra-encounter and inter-encounter detail without needless micromanagement, while also permitting people to pick up everything if they want. Sounds very slick, although I hope there is some reason why items effectively "teleport" back to camp. I'm not totally sold on some of the special class abilities ("escape" in particular, since I have difficulty buying blanket immunities without a pretty strong in-world justification), but the overall philosophy of flexible class progression with variable complexity buy-in sounds great. And the wizard's familiar sounds quite wonderful, although finding the sweet spot between too weak and too powerful for "extra" agents like familiars and summons has always been challenging. Finally, I think the weapon system sounds pretty solid as long as switching to the "optimal" weapon type doesn't become a tiresome chore. That can be done by making the difference between weapon effectiveness not that strong, of course, but that obviates the purpose for the distinction in the first place. And if the difference in effectiveness is very noticeable, it may become uninteresting and rote. The inventory system allows some strategy in this regard, but pretty much every fighter worth their salt will have one of each type if possible, so I think switching weapons in combat to the "best" type should not always be optimal. For example, if switching weapons takes time one must weigh the possibility of delaying the initial attack or suffering from momentarily lowered defenses. Thanks again, my favorite update thus far!

Thanks. I'm thinking that I may take some time at Christmas/New Year's to make something like that. Ideally, a version with character abilities, rules for determining item properties, and expansions on the existing mechanics wrapped up in a nicer package. We'll see. And I'm not really a fan of item lotteries in this sort of game, although the details matter a lot. If the outcome depends on very few "rolls", and especially if they take place in a short span of time, then the power of crafting may depend more on the player's attitude toward reloading than to the crafting system itself. (I don't hate that reload-heavy playstyle as such, I dislike systems that have wildly divergent outcomes depending on playstyle.) The degree to which the random outcomes depend on character skill is also important. Too much and only specialists will be able to use it effectively, too little and crafting is just a weird store. Finally, there is the issue of consequences. I enjoyed the wizard stronghold crafting quests in BG2, which were chance-based, because they presented the character with meaningful tradeoffs to consider. In the end, of course, I'd gladly accept a crafting system not in my preferred style if it is executed with some inspiration. If crafting is just busywork, even if it's ignorable busywork, I'd rather it be cut or reduced to the simplest form of input->output. Thanks for your thoughtful comment!

No worries, I didn't take that meaning. I actually laughed when I read your first sentence. Yeah, the more I think of it the more I tend to agree with you on this point. It depends on the fiction of the game world, of course, but usually magic and the natural have sharp conceptual difference. If so, having the same crafting representation for both doesn't do a good job of supporting that distinction.

The interface isn't pretty, but it is functional. Like I said, I wrote it as an experiment for myself. The interface allows 3 actions. 1) Select a source (Click on a hexagon with a hollow circle in it. The hollow circle of the currently selected source is white.) 2) Add a component to a source. (Click a component from the list on the right-hand side. That component is associated with the currently selected source. This can be changed as often as one likes until a path is added from that source, at which time the component of that source cannot be changed.) 3) Add a path (Click on a hexagon with a solid white circle in the center. What paths are possible to add depends on the selected source and its associated component.) That's it. I grant, I should have stated this explicitly in the first post. A failure of documentation, at the very least. Ehh, it's a board game serving as an abstract representation of the underlying magical reality of crafting, not about the physical tasks needed to do the same. It is no more right or wrong than using a dice roll to determine if a sword hits instead of using the mouse to control the sword directly. Each gives a different sort of experience -- each can be designed well or poorly, and each can implemented well or poorly. I don't mind if this particular abstraction isn't your cup of tea, but there are many ways for a thing to make "logical sense in relation to the activity." In this case the "activity" could be shaping unruly magic forces to a particular magical purpose rather than shaping steel. Yes it does. "Enchanting" may have been a better description given the specific elements I described. Nevertheless, one could define the "elements" to refer to non-magical concepts if desired. As for going for a rune-based design, that's a perfectly reasonable way to approach the problem. I had toyed with a similar idea, by assigning elements to components themselves and then defining more elaborate interactions between specific elements that occur when sources of different colors are joined. I went in a different direction, but I'd like to see a mock up of what you mean. (And since schematics define source geometry, there is a "rune-like" aspect to them, but that's neither here nor there.) The main thing I want is a way to join compelling strategic management with the tactical aspects of the minigame. If your runes conception would work better, I'm all for it! If no one finds a minigame that does these well, I'd cut the whole idea.

Well, that crafting has a clear goal (i.e. a predetermined resulting item) and requirement list (a predetermined list of exactly what is needed to make a given item) is an assumption, not a necessity. For example, in my idea item schematics might determine an item's fundamental properties and the geometry of the sources, but additional effects might depend on precisely what components are used in which source. Suppose the screenshot showed the process of building a +2 bow or something. Whether that bow does extra fire damage, increased accuracy, can shoot through cover, etc. might be determined by the components used. So if you try to craft a bow +2 you always get a bow +2 (as long as you connect the sources), but designing a bow +2 that fires insubstantial flaming arrows and doesn't require ammunition might depend on whether the components you have that would add those properties are sufficient to actually connect the sources. With greater character skill one would have greater freedom to create both more powerful items, but also to manipulate the board so you are more likely to be able to create the specific item (i.e basic item properties plus special properties) you want and/or using less powerful components to do it. My opinion is that whether a mini game is fluff or not depends on the consequences on the larger game. For example, a lockpicking minigame generally has no outcomes other than "door unlocked" and "door remains locked", possibly in some combination with "alarm sounded" or not. Anything that results in one of those 2-4 outcomes behaves more-or-less identically regardless of what has happened before or what will happen later. Minigames that aren't fluff offer an opportunity to interact with the game world in unique ways. For example, the X-Com games have both the tactical game and the strategic base-building game, and each impacts the other. Even if one is emphasized more than the other, the other one hardly counts as "fluffy" if the consequences are there. I think a crafting minigame has the potential for rich strategic impact, and if it doesn't then it should be cut as a minigame, going instead for the simplest thing that achieves those outcomes. A crafting minigame with collecting fixed components to make fixed items doesn't really achieve that, no matter what busy work is done in between. I'm going for something where the connection between the input components and the output item isn't fixed, and the minigame mediates the details of what can be built with what components, and gives the player a meaningful decision about how to spend them. Not saying that I succeeded, but I hardly think the basic idea is necessarily fluffy.

Not the most immersive interface...that's putting it gently. And thank you, I enjoyed thinking about potential game mechanics and coding them up. The code is released under an MIT license, so anyone who wants to can play around with it.

I've been pondering how to make a fun crafting minigame with strong strategic and tactical elements, that rewards players for crafting without making it necessary to super-specialize, and that puts less stress on the in-game economy. Well, I decided to try out an idea and ended up programming a prototype. You can get it here. It's implemented in Python and requires the matplotlib and numpy libraries to run. (Installation details are in the zip file. I wasn't originally intending to share, or else I probably would have written it in something a bit more convenient.) Here is a screenshot and a summary of the idea, which is basically a glorified Euro-style version of connect-the-dots. The basic goal is to connect all the magical sources (represented by circles) within the larger grid by building paths between adjacent spaces. The path is represented by white lines between spaces that emanate from the sources, and valid moves are shown by white circles within spaces. The sources themselves are powered by crafting components, so the game is an abstraction for "connecting the power" among the various components to create a new magical item or effect. The grid spaces are colored, representing different magical "elements" which affect affect how paths may be grown. Currently these generic elements are: "air" - light blue "earth" - brown "fire" - red "soul" - yellow "water" - blue In addition, there are magical "walls", represented by black, to which paths may not be added. These magical walls represent unforeseen difficulties, and are only displayed once a path is adjacent to it. Crafting components are listed on the right-hand side of the screen. To add a component to a source simply click on a source (the circle will turn white) and then click on any of the components. The properties of the crafting components place additional restrictions on how paths may be placed. In this prototype every component has 3 properties: 1) A strength, which determines how many times a path may be added from this source. Every time a path is added using the selected source, the remaining strength decreases by 1. The current/maximum strength of the selected component is displayed in the center of each source, and the maximum strength is displayed in the upper left hand corner of each component. Once current strength reaches 0, no more paths may be added using this source as the active source. 2) A list of elemental sympathies. Sympathetic elements mean that, when adding paths, the player is forced to choose a space containing one of these elements if possible. If no such move is possible the sympathy has no effect. Spaces containing an element sympathetic to the selected source/component show a "+" in the center, and these are also summarized in the list of components. 3) A list of elemental antipathies. When using this source/component, these elements are impassable, and show a "-" in the center, and also summarized in the list of components. The wide variety of crafting components reflects a desire that most items shouldn't have a specific recipe of required components. Rather, any set of components the player can use to connect the sources is sufficient. One may change the active source at any time by clicking on a different one, and the properties of its component applies to all possible moves from a path connected to that source. Even as multiple sources become connected, only the component properties of the currently selected source are used to determine what moves are possible. The game ends once all the sources are connected (a crafting success) or when no more moves are possible (crafting failure). (Note: the software currently only detects crafting failures if the strength of all sources is 0. Other failure conditions are not tested for.) One may swap which components are associated with which sources freely until at least one path has been added using that source as the selected one, at which point the choice of component is fixed for that source. This program serves as a prototype and proof-of-concept. The intent is that a fuller game would include many more special events triggered by reaching specific spaces as well as special character abilities used to help connect the nodes. Examples of special events might include one that reveals all other special events within 3 spaces, or which adds an additional source (with a special effect for the crafted item) to the board. Examples of character abilities might include destroying walls, temporarily changing component properties, changing the element of a space, increasing a component's strength, or adding an additional source somewhere on the board. Finally, it is expected that item properties will be determined from a combination of considerations: those fixed by source, those fixed by component, and those determined by special events. This basic format is also, in principle, compatible with implementing item upgrades and disenchanting. ------- A few brief things I didn't cover above: 1) My intent is that "schematics" largely define source geometry and the basic effects for items. These could be found, purchased as character skills upgrades, and occasionally discovered spontaneously in "breakthrough" events while crafting. 2) The rules are determinstic, possibly aside from initial state of the board. Even then, I think it is in the spirit of the minigame to only determine that setup once per crafted object. 3) Most items would not rely on unique or specific components, mitigating the frustration of not being able to make an item because some specific thing wasn't found. (Or, even worse, was found and sold.) Items useful for crafting can be identified as such because they are largely generic. 4) Every playthrough would be a bit different, with the exact kinds of components found shaping the types of items that are most efficient to make, but usually not making any specific item impossible. How, if at all, does this idea move toward the goals I outlined at the start? 1) A character with a high crafting skill will be able to craft an object using relatively less powerful components, but a character with low crafting skill will, in principle, still be able to craft some good things if they are willing to invest their best components into it. Therefore, characters that do not hyperspecialize may still have the opportunity to make some very good equipment, and it gives the player a meaningful strategic choice about how to expend components. 2) The game has some interesting tactical properties, in my opinion. The specific path taken in early moves has a large impact on what moves are available later. In particular, sympathetic elements are very interesting because they are very predictable at the start, but as the path grows longer it becomes more difficult to reign in. As events and character abilities are added this depth should increase. 3) The difference between an optimized path and a sufficient non-optimized path should be relatively small, because the geometry of sources puts some firm lower limits in place. (Interesting fact, the shortest path between sources is the Steiner tree problem for graphs, which is NP-complete.) Thus players who choose to optimize and those who settle for a more brute-force approach should not, I hope, be vastly separated. 4) In the game economy, novice crafters probably take a loss when making common items, for the benefit of making items that are not available at all. As one improves one can get away with using less valuable components to make a given item, eventually enabling a gain. It is also much easier to rationalize a non-fiat economic equilibrium in a system that alllows for both gains and losses. Alright, I've said more than enough. Do try the program if it looks interesting to you. Thanks for reading, I hope you'll be able to draw some inspiration even if this isn't your cup of tea. Comments are welcome.

Voting has pretty much ceased (52 votes at the time of writing), and I think we can safely summarize the results. These, of course, should be taken with the usual internet poll grains-of-salt due to the highly self-selected nature of participants, etc. That said, there were no votes for "Other", so we can have some confidence that the responses adequately capture the basic spectrum of opinions. The desired degree of comprehensibility is fairly evenly split between those who don't care so long as they can make a sound decision, and those who want at least the basic math of the game (if not more) to be understandable, with half of the latter satisfied even if only the basic system is easily understandable. Only 10% of respondents specifically want to avoid difficult to understand elements entirely. That suggests the path that would make the most people happy with this aspect (about 75%) is to implement a system in the neighborhood of "Marginal" and "Substantial", with robust in-game feedback for the sizeable number of people who want that. The nature of that feedback, however, is not subject to any clear consensus. (I personally find this the most interesting result.) About 2/3 want some degree of information, but each of the six options is in the same ballpark. When comparing basic vs. substantial by summing over all the none/somewhat/largely options we see that basic information has a slight edge. Likewise, when comparing dependence on character skill of none vs. somewhat vs. largely by summing over the basic/substantial options we see that None has a slight edge. I don't think that edge is statistically significant. The only significant result I see is that the number of people who want at least some impact from character skill is about double those who want it not to matter at all. The 23% of respondents who don't want any explicit information will probably have to deal, especially given the result of the first poll. The best bet might be to make a game option that offers No explicit information, Basic information, or Substantial information while also implementing a few interesting character abilities. There are two important requirements I would impose. First, a casual player on the Basic information setting who takes no information-related character abilities must have enough info to make sensible choices. Second, the game option must not make the character abilities irrelevant, and so they should provide qualitatively different information. A natural split might be to have the gameplay option concentrate on the detail of known information (like turning "Badly Damaged" into a specific number of hit points), and the character options to grant exploitable world-based information that would otherwise not be available. An example might be a "monster knowledge" ability or subsystem which could be used to support a very lightweight "called shot" system that would occasionally enable a player to take a special action, show a future enemy action, show what an enemy is casting, etc. It should avoid things that are easily circumvented based solely on player knowledge (like the "track" skill in many games that is pointless on a second playthrough or just by reloading). I don't know, just an idea. Finally, the third poll shows a clear preference (among those that care at all) for not sacrificing functionality for understandability. Based on the first poll the small set of core mechanics had better be both highly functional and understandable, but beyond that well-tuned mechanics are the greater priority to the majority of respondents. I don't find that particularly surprising. Thanks again to all those who voted, hopefully you and Obsidian have found it informative.

Just how easy to understand do you think PE's mechanics should be? This is a complicated poll because I think it's a fairly complicated issue. As mentioned in the recent update the designers are not constrained to use a d20 or similar math because the game doesn't have all the playability restrictions of a tabletop RPG. Nevertheless, having a system that can be largely understood without aid can help the player quickly make informed decisions both in play and while building a character. I generally dislike CRPGs that hide or obfuscate their mechanics because it leaves the player guessing about decisions, when at the very least I would expect the character to have some intuition about his or her own capabilities with respect to a challenge. There is also an inherent subjectivity to this topic because what counts as "easy" math varies quite widely in the population. I am personally comfortable with a large degree of mathematical complexity (that being inherent to my day job) but that doesn't mean I want a game that uses Bessel functions, or even a lot of division. Besides, complexity naturally results as different mechanical elements come together, so simple "elementary mechanics" can lead to rich outcomes. That said, some math is numerically but not conceptually complex. Something like the normal distribution (i.e. Bell curve) is pretty easy to understand conceptually because it has so few parameters and they have a very intuitive interpretation. So while the math is hard in some respects the fundamental concept is contained in two parameters, and math on the parameters is easy. Therefore I imagine a computer game could use it extensively without becoming incomprehensible. YMMV. Please note when taking the poll that when the game is providing information, I'm specifically asking about information given to the player before taking an action. Things like the probability of an attack hitting, and so forth. Displaying the actual math performed to resolve a task (e.g. showing what the "dice" rolled) is a separate issue, although I certainly hope the game makes that information available if desired. Here are my choices, with comments. 1. What degree of unaided mathematical "comprehensibility" do you want in the rules? I chose "Substantial", because I think the core mechanics should be understandable to pretty much anyone that puts in a little time, and because complexity should generally be emergent, rather than inherent. If the crafting system is more inherently complex I'm less worried because generally that is a rare event. However, the relationship between attacks and defense should be much easier to understand, because some form of that is probably the single most common event in the game. Even if the game provides that information explicitly (perhaps when mousing over an enemy) I think the math should be simple enough that I can make a reasonable guesstimate without doing that. After all, if there are 15 enemies I don't want the math to be so complex that I actually need to mouse over all of them to make sure I'm not making a terrible decision. Finally, an understandable system helps a lot when it comes to determining character progression. The basic effect and magnitude of a feat/perk should be understandable when taken, not only when it is used. Few things irk me more than when an ability says something like "improves your basic attack" and then gives me no information on which to judge whether the improvement is significant or not. If the system math is very complex the situation is not much better even if the exact effect is given, and even if the game provides very informative feedback during play. I also think this is a good match for a game inspired primarily by IE games, which I think mostly falls under this category. The elements above are part of what I appreciated about those games. A large change here, while not inherently bad, strains (but by no means breaks) the resemblance for me. Others may feel differently. 2. To what degree should the game provide explicit information about possible results of an action? Should the degree depend on character skill? I chose "Basic, None", although my opinion about whether it should depend on character skill isn't fully settled. For people who don't want to learn the math, something like this is extremely useful, and for me the real question is how much information should be provided. As much as I love diving into statistics, I feel that is generally better outside the game. I think the main goal should be to give players about as much information as one might expect the character would have. For depending on character skill, I have mixed feelings. I love the idea of making a game that robustly handles what a character knows, and conveys that to a player, but I think a really good implementation of that would be both difficult and not necessarily in the spirit of the IE games. Moreover, something like the Awareness perk from Fallout 1/2 really changed the feel of the game for me. Not necessarily in a bad way, but I always felt it was inelegant that it was basically a switch. An analogy might be to karma/alignment/reputation systems. A really simple alignment system doesn't add much to the game, and can in fact encourage some ridiculous gameplay. A sophisticated reputation system, when it is finally implemented, can really add a lot to a game. I'm not sure designing an equivalent system to translate character knowledge into player knowledge is what I want the developers to spend time on in PE. 3. To what degree would you be willing to compromise system function to ensure it is mathematically "comprehensible" without aid? I chose "A little". It's always a tradeoff, but I'm willing to tolerate a few more trouble spots to help global understanding. In addition, it's my opinion that understandable systems are generally easier to make work in the first place. The designers are human, after all. I didn't vote "non-issue" because I think it remains an issue when building a character, in complex tactical situations, etc. It mirrors my feeling about calculators: they are useful tools, but not a replacement for understanding. If you got this far, thanks for reading. I hope this will foment a productive discussion.

I think it is all about incentives. In my opinion a good system lets optimizers optimize without falling apart (and there are many different flavors of "optimum"), and lets casual players progress without (usually) ending up in a hole they cannot dig themselves out of. The incentives should be such that behavior we might consider "abuse" are actually not the best course of action, without actually preventing those behaviors. Note that I'm not talking about modifying save files, at that point a person has entirely opted out of the metagame, and if they want to do that so be it. (I love Shadowkeeper, and hope we'll see its equivalent for PE.) Something like the save/reload process, however, is part of the metagame and is thus within the scope of the conversation. The main issue, in my opinion, is when the incentives for the characters within the game to act a certain way are drastically different from the incentives set up by the game system from the player's perspective. I don't think we should artificially prevent players from taking actions that might be "abuse", we should instead modify the incentives to respect game mechanics and game world in the first place. Consider resting again, as most of you have done. In most RPGs resting sets the party to its maximum possible strength. Thus there is an obvious incentive to do so from the perspective both of the game characters (who don't want to die) and many types of players (who want to win decisively). However, the incentives on the side of "not resting" are divergent. For the characters (who don't know they're in a game) resting would usually introduce all sorts of hazards and consequences. For players, however, typical implementations have meant all the hazards and consequences are a reload or two away from not existing, and so resting introduces no tradeoffs that matter to a certain kind of player. The solution isn't to ban resting or save/reload, it is to have using those abilities maintain the incentives the party itself faces, and perhaps put in some gentle metagame consequences. Here are some ways to address this particular example: 1) Determine ambushes on the condition of the dungeon, not randomly at time of rest. For example, if the enemy has scouts, let them use them. The ambush itself can still be random, just preserved across saves. 2) In-game consequences for resting besides adjusting party power, and which make sense within the world. If the enemy knows the party is out there they may call for reinforcements, leave the area, dig in, or otherwise react in a sane way. This needn't be complicated: in many cases it could be as simple as the enemy spending resources to improve its defenses, or sending the women and children away with the valuables, etc. That puts the incentives for the player more in line with the incentive of the characters. Moreover, even if the characters don't value the enemy's "loot" the player probably does, so the metagame offers a tradeoff between immediate power and loot. 3) When it makes sense the consequences of resting should not be known immediately. The point isn't to take a sledgehammer to save-scumming by tossing in all sorts of "random gotchas", but to keep the knowledge and incentives of the players on the same page and thus provide a more engrossing experience. In other words, save-scumming is usually a symptom of a problem with the game world, not a problem in and of itself. 4) Consider designing elements of the system such that it isn't always the case that resting sets the party's power to maximum. For example, maybe there is a "desperation" or "resolve" mechanic that makes the game play a little differently after a long time without resting. This might make the party more powerful in some ways, even as it is also weaker in other ways due to attrition. The point is, the game mechanics can make it so that resting isn't necessarily the best decision in terms of raw party power. This sort of thing should have a compelling reason to exist within the game world, though, or else it is as transparently artificial as arbitrary limits on resting. All these examples try to harmonize the metagame with the game world, so we can embrace both on their own merits rather than pitting them against each other. If done well I think this obviates the conflict between "protecting players from themselves" vs. "trusting the player to exercise self-control" while actually enhancing the game itself for both types of player. As game design goes, that's the kind of optimization I want to see.

I prefer no hard level/XP cap, but would make XP gained dependent on the challenge's difficulty relative to party (not character!) strength. As the PCs gain power the amount of XP gained by a given challenge decreases, and the greater the party power the more severe the reduction. Similarly, an underleveled party that succeeds at a signficant challenge will gain a lot of XP at once, but gain less on future challenges than if they had skipped this big challenge. This dynamic allows a lot of flexibility with balancing the party with the environment, because whether the party is over-leveled or under-leveled they are nudged over time toward the XP an "appropriately powerful" party will have. Furthermore, as long as parties that clear identical material (but not necessarily in the same order) end up with similar total XP the system also balances them with respect to one another. Finally, scaling XP gained allows one to make the leveling progression very simple, like 1 level per 1000 xp or something like that. One can do almost the same thing by using fixed xp per challenge and changing the xp needed to level in an ever-increasing manner (like in AD&D and therefore most of the IE games), but this eventually requires huge numbers, and is especially challenging to pull off if the minimal path and the completionist path have wildly diverging total xp. For example, suppose half is required and half is optional material: if you want to make sure, without using a hard level cap, that the completionist is at best a few levels ahead of a person taking the minimal path, then you need to make sure that those few levels require half the xp in the game. Then, in the sequel or expansion, you start with high numbers and it just gets worse. The other advantage of scaling XP gained is that it can take party composition into account more smoothly. Our IE predecessors have mostly mishandled this. In BG/BG2 soloing, for example, is relatively satisfying because you get lots of extra XP to make up for having no other party members. Then you hit the level cap and not only do you have most of the game left, but by the time you reach the end your "party" is roughly 1/6 as powerful as what the developers assumed when designing the content. So the level cap really only "worked" for a specific party composition, not all allowed compositions, in addition to all the other issues with caps. In IWD2, by contrast, XP is scaled relative to strength so things could have worked well. However, the scaling was actually determined by average character level, which is a measure of average indivdual strength rather than overall party strength, and so in practice it only really worked for full parties and even lacked the grace period that made using smaller parties in other IE games work OK up until the characters hit the XP cap. I consider that to be a major oversight in IWD2, especially since it could have been largely mitigated by revising a single calculation.

Why not give potions a half-life (i.e. use exponential decay) which determines how long they last within the body and interfere/interact with other potions? At the very least this avoids the unsightliness of cooldowns. Potion spamming might still be possible, but it would also be a less-than-optimal use of resources and thus not in the player's interest. This could also be used to implement Witcher-like notions of toxicity, but with a more flexible mix of strategic and tactical consequences. For example, suppose some potion has a half-life of 10s. Immediately after imbibing the effectiveness of any new potion might be 0%, after 10s it would be 50%, after 20s 25% and so on. The computer could handle the countdown effortlessly, of course. After a minute or so this particular potion will have negligible impact on any new potions imbibed. Other potions might have a half-life of an hour or 1s, and thus have a very different impact on play. The effect of multiple potions in the body at once on future potion use could be determined in various ways, such as using the one that has decayed the least, or some mathematical combination of all those still present. An alternative use for exponential decay might be an alteration of the toxicity bar from the Witcher. Each potion might increase toxicity by a given amount, and its contribution to total toxicity would decay over time based on the specific potion. The side-effects of toxicity act to prevent potion spam, while the half-life merely determines how toxicity decays rather than how effective potions are. Potions with strong strategic impact might have large toxicity and long half-lives. Potions with strong tactical impact might have large toxicity but short half-lives. Potions with low toxicity and short half-lives would be effectively spammable, but these are probably potions of limited utility. Many other variants and tweaks are possible, of course. Why exponential rather than linear decay? This is a common pattern in many biological systems (about 95% of drugs at therapeutic concentrations follow this pattern, although not alcohol), so although there is no requirement for the same in a fantasy world it might lend a touch of verisimilitude. More importantly, I think it makes for more interesting decision-making. For example, consider three systems which impose a penalty on the effectiveness of future potions. In the first the penalty is 100% for 10s and then drops to no penalty (effectively a cooldown). In the second the penalty starts at 100% and drops 10% per second to no penalty after 10s. In the third the penalty starts at 100% but has a half-life of 1.5s, so the penalty is approximately 1% (essentially gone) after 10s. The cooldown doesn't introduce any interesting decisions. The second system introduces a meaningful trade-off, but the nature of the trade-off is constant with time. That means that it is difficult to make a trade-off that lasts a long-time without also imposing a very strong penalty on short-term use. Furthermore, in a situation where a player might want to spam potions, the most interesting tradeoffs are made if waiting a little while can provide a sufficiently large benefit. After a certain point the pressure is off and it hardly makes a difference whether the penalty on an additional potion is (for example) 20% vs. 10% anyway. A penalty with exponential decay has its largest changes in effectiveness nearest to when the last potion was used (when such changes are most likely to be interesting) and a long tail of relatively small changes that can be used to enforce long-term limits without making short-term potion use pointless. Consider also the availability of potions. If they are plentiful, cheap, and useful the optimal use of the cooldown system is button mashing or otherwise using them as quickly as possible. In a system with meaningful tradeoffs this is almost certainly not true. If potions are extremely rare then there is not much difference between the three systems if the characters almost never imbibe more than one. However, in games where potions are rare there is such a strong incentive to "save them" for fights or days when they are needed that, in actual fact, on those rare cases a character wants to use a potion they probably want to use several. So whether potions are rare or not the system should probably be built to be interesting and balanced assuming multiple potions are used in a relatively short period of time. This also makes it more flexible for use in games where the actual number of potions available could vary widely due to player agency via completionist/hoarding tendencies, access to crafting, etc.