MReed

For easy, normal, and hard there are specific groups of enemies in each encounter, and they aren't (necessarily) cumulative. In other words, you get a totally different mix of foes for each encounter in each difficulty mode. In PotD, you get them all, although some consolidation occurs (you'll only get one copy of a named foe, for example).

Off topic: [For the record: I don't support combat XP] And players who use this mod will hit max level a third of the way through the game, then complain that the game is too easy. Unlike engagement, this really isn't something that can be modded into the game, at least not without an enormous amount of work (reducing all other XP rewards to ensure that leveling occurs at the expected rate, basically) On topic: I tend to agree that there are a significant number of backers that are looking for NWN 3 (at the very least, this explains the reason that some are supporting engagement) -- but I suspect that these backers will be disappointed with the lack of mod support and the lack of multi-classing / prestige classes (reducing character customization options). Nevertheless, I don't see any reason to believe that the game will at least be as good as, and quite possibly superior to, other RPGs released in the past 2-3 years -- but that's as much an indictment of the low quality of PRG releases during the past three years as it is praise of the quality of this game.

In practice, I don't think this would be feasible. See http://www.wizards.com/default.asp?x=d20/oglfaq/20040123i -- in particular, the portion of making all of the OGL content "easily accessible" to the end users. As a developer, meeting the terms of this license would be difficult, at best.

Ah, the old "Sainted developers (praise be unto their names) are all knowing and would never, ever, under any circumstances make an error of judgement". Two observations: 1) This argument is, quite obviously, not going to convince anyone to change their position on engagement (pro or con). 2) While some (heretical, mind you) actually do believe that the sainted developers (PBUTN) might make judgement errors, especially with a feature that they have invested a significant amount of resources in and represents a major innovation in the way RTwP games are made, nobody disagrees with one simple fact: The sainted developers (PBUTN) are most certainly omnipotent -- no amount of feedback from this forum can force them to change their beloved engagement model against their will. Given that you aren't actually arguing in favor of the merits the engagement model -- merely defending the honor of the sainted developers [PBUTN] -- and the sainted developers (PBUTN) are hardly likely to pay attention to the concerns of mere mortals, it is unclear to me why you are posting in this thread. Can you explain?

Why would others who oppose engagement post to threads when Sensuki is making the same points that we would have made, but in a much, much better way (with gameplay examples and so forth)? And why would we post to try to rebut arguments when Sensuki (the person who made the arguments in the first place) is highly likely to rebut on his own? And why would we make "Me too" posts when there is that handy "Like This" button on every post where we can indicate our agreement with the points being made without having to clutter the thread with posts with zero information content? Gee, I wonder... For the record, though: I oppose engagement, although my reasons are slightly different than Sensuki's. His opposition is based on how it changes the feel of combat for the player -- my opposition is based on the fact that it encourages (and likely outright forces) a primitive, simplistic AI for foes. But in any case, we both feel that engagement is bad, although I'd be willing to accept a massively nerfed version based around snare effects (rather than damage).

I don't think "gut" is the right word -- as I pointed out, in a 1x1 engagement, the player would not be able to successfully escape. True, they wouldn't take an AOOs, but they would still take normal attacks and be unable to attack in response. Even with a minor (10%) deflection bonus, they are still going to die, it will just take a little longer. Now, even a half-way competent player will rarely be flanked (the AI, almost certainly, won't flank the player except by accident), but the player is still required to bring up a second party member to gain engagement (against all foes for the person who is trying to retreat) and suffer normal attacks while attempting to withdraw, and withdraw in a direction that doesn't result in any of the foes ending up in flanking position. I suspect that these conditions will be unachievable during many practical play scenarios, especially when it is the fighter (tank) trying to disengage, which would be the most common scenario. I agree that it nerfs the engagement metric quite firmly, and it strongly favors the player (because the AI, almost certainly, won't be able to exploit any of the new features except by accident), but it leaves enough of the engagement mechanic in place to achieve its primary goal, of deterring certain forms of kiting (to the degree that it can achieve this goal, which is a wholly seperate discussion).

To clarify a couple of things in my original proposal: * ""A" forgoes all offensive attacks" really should have been ""A"'s recovery time is paused". * Any character who has engaged a foe but is engaged by nobody can move towards or around (+- 180 degrees from a vector pointing from the center of the character's avatar and the center of the foes avatar) any foe to which they have engagement without any penalty -- in particular, this means that: * The moving character's recovery timer is not paused * The movement, does not break their engagements (unless the result of the movement pulls the character out of engagement range of one or more targets -- only possible if the character can engage multiple targets) The purpose of the second is to ensure that in a 1x1 situation the character who moves first is at a disadvantage (his/her movement will break engagement and pause his/her recovery timer, but the movement of his/her foe will do neither of these things). If this change wasn't made, it would encourage kiting, defeating the whole purpose of the engagement model in the first place. The most likely reason for attempting to withdraw is due to damage -- the deflection bonus (& immunity from AOO) is critical to making this a valid option. As Sensuki has pointed out (and I fully agree with him) the high risk of damage when you attempt to disengage with the current model renders movement in this case impossible, and spending valuable talents for something that will only come into play when you are already in a bad situation, rather than something that will help you all the time is a poor strategic decision. The deflection bonus also makes sense from a realisim point of view -- if all you are doing is trying to avoid damage and you are retreating from your foes, you should be harder to hit. Instead, I would propose that Graceful Retreat should eliminate the movement penalty and replace it with a +10% movement bonus, increase the deflection bonus to +25%, and allow the recovery timer to run at 50% of its normal pace (so a 3 second recovery would be a 6 second recovery while withdrawing). It would still be a questionable choice for a talent, but perhaps benefit builds that are designed around flanking attacks. Note that while I've described it as "fighting withdrawal" in the original proposal, "fighting maneuver" is perhaps more accurate -- you don't have to use this to move away from a foe, so you could use it to reposition to gain flanking attacks (for example). The modified engagement model also synergies nicely with talents / abilities / effects that make it harder for a character to be flanked as well, which provides another path for a player to increase their ability to escape from combat while still being useful in other cases and is passive, so it will be there when you need it (vs, say, Knockdown or stun effects).

I believe I have a solution that will satisfy all parties (except myself) in this discussion: When a fighter A is engaged by one or more foes (X, Y, Z), it can still move without incurring AOO's by executing a "fighting withdrawal" if: * "A" is not flanked * "A" drops all of his/her engagements * "A" forgoes all offensive attacks (this is normal when moving anyway) * "A" accepts a 25% movement penalty * "A" gets a minor (10%) deflection bonus to all attacks from targets that have engagement with him/her. This sort of movement would be the default when a character is engaged by someone else and a movement order is given. An <alt>+click (or similar) would be required to invoke normal movement in this case. if the character is flanked, he/she would adopt the orientation that minimizes the number of flankers and accept the AOOs from the remainder. The UI should warn the player when this will occur -- the most obvious way is to turn the mouse cursor red (instead of the normal white) when a movement order would result in unavoidable AOOs. Scenario: The PC's party consists of: Fighter A Fighter B Healer C There is one foe, Z (which can hold engagements with up to three people at once) At the start of the combat: A is engaged with Z Z is engaged with A B is engaged with no-one C is engaged with no-one A is damaged and would prefer to withdraw. To prepare for this withdrawal B moves up to the front lines and establishes engagement with Z. State: A is engaged with Z B is engaged with Z Z is engaged with A Z is engaged with B C is engaged with no-one A left clicks near C and starts a fighting withdrawal. Since there is only one foe, there is no difficulty in ensuring that he/she is not flanked, so all the conditions are met. State: A is withdrawing, so can no longer engage with anyone B is engaged with Z Z is engaged with A (but getting no benefits, due to the fighting withdrawal) Z is engaged with B C is engaged with no-one Z attempts to pursue -- since Z is still engaged (by B), he/she must also execute a fighting withdrawal. Again, with a single foe there are no flanking concerns. A is withdrawing B is engaged with Z (but getting no benefits) Z is withdrawing C is engaged with no-one A is no longer engaged by anyone -- therefore, the restrictions imposed by a tactical withdrawal no longer apply, and he/she can move full speed. A is moving normally (toward C) B is engaged with Z (but getting no benefits) Z is withdrawing C is engaged with no-one A can now easily out-run Z (as Z is still suffering form the 25 % movement penalty). B, not being engaged by anyone, can easily keep Z within range, making normal attacks against a foe that cannot strike back. Z will be obliged to stop pursuing A and attack B, which is the desired result. Obviously, this is a very simple scenario -- but it should make movement in combat a reasonable option once again.

Such skills already exist -- the concern is that these skills fall into one of two camps: 1) Useful for other purposes (e.g. Knockdown, Stuns, and the like) and are likely to be used long before the player realizes that disengagement is necessary. 2) So narrow in focus that nobody (should) select them -- giving up talent that will allow you to kill an opponent in exchange for a talent that allows you to withdraw safely is simply not a good choice. Some people argue that skills in the #1 bucket are good, because they force the player to make a hard decision on whether or not to use the skill early or save it in case withdrawal turns out to be necessary at a latter time. The "no engagement" group believes this isn't a valid dilemma because the correct choice is always to use the skill early in the hopes of avoiding the need to disengage at all. YMMV, of course.

It was normal (the stream is split into two parts -- http://www.twitch.tv/paradoxinteractive/b/588467303 is the first part, and the difficulty selection is at 13:07). Sawyer did indeed give advise, but (and with the caveat that I didn't watch the entire stream) it was mostly along the lines of "If I were you, I'd save the game here" and "You should use your abilities" -- pretty basic stuff. A complete newbie playing BG1 is very likely to die at least once during the prologue, after all (the ambush in the barracks is likely to be fatal, especially if the player missed the combat tutorial).

It is worth point out that the Twitch stream (http://www.twitch.tv/paradoxinteractive/b/588477048) indicates that a novice player starting from the beginning will not find the game unduly difficult.

Just for grins -- here is a script file (meant to be used for a fighter class party member) for BG 2:TOB. To be clear, I didn't write this, I extracted it from the eSeries [edited] scripts that can be found here: http://forums.gibberlings3.net/index.php?app=downloads&showcat=25&sort_order=DESC&sort_key=file_submitted&num=10&st=10. efighter.txt

Except what you really meant to say was "Iterative over all visible foes and find the foe with the lowest stamina..." which requires a loop. Alternatively, "Find lowest stamina" could be a hard-coded function, but what if you want to look for the friendly unit with the lowest deflection bonus (to cast a buff on them)? You don't need much more than if ... then ... blocks to implement a reasonable AI, but you do need a bit more.

This is exactly how the Infinity Engine scripts work -- you have a long list of conditional blocks paired with action blocks + a chance to execute. So you might have <pseduo-code> "If my health is greater than 75% and I'm not currently engaged in melee combat then 50% of the time attack the closest target". You can have any number of conditions that you want, but only one of the action blocks will be performed (the script exits immediately if it finds a true conditional block and the RNG check passes). To point out the obvious, we have just been discussing the inadequacies of the AI in the infinity engine games, so... I tend to agree that trying to write overly complex AI scripts is counterproductive (although perhaps useful in certain cases -- enemy party AI, for example) -- but the simple <condition> -> <action> blocks that was used in the IE games is inadequate to implement tactics such as the following: * If there are friendly melee units closer to the enemy than I am, then * Wait up to 10 seconds or until at least one friendly unit has engage a foe in melee combat, then * See if a path exists that will allow me to engage a currently unengaged target -- if so, start following that path * If I haven't tried to cast an AOE damaging spell in more than 60 seconds, then * For each AOE damaging effect that I have (most powerful -> least powerful) * Find the best X,Y target for the current AOE effect, considering only damage to foes, then * Reevaluate that target taking into account damage to friendlies, then * If revaluation results in a score reduction of more than than 25 %, and the damage to foes exceeds 100 points, then * Check to see if the party contains an AOE spell that will mitigate the AOE's effects to friendly units. If so, then * Cast (or request another unit to case) the protection spell and re-evaluate the AOE after it has been cast. * Cast the AOE spell Obviously, these are incomplete fragments, but you get the picture -- these aren't by any means "genius-level" AI, but far more robust (and, just as importantly, easier to implement) than the simple scripts possible in the IE games.

With the engagement model that is implemented today (or anything resembling it), the only valid strategy for melee-only (or melee-dominated) foes is "Move towards the nearest foe and attack it continuously once engaged until it dies" (e.g. strategy 1). Any attempt to engage an arbitrary foe ("squishies") will lead to engagement (& associated disengagement attacks) by the fighters, which will almost always block the straight-line path. Avoiding this problem leads back to implementing the 3 critical functions that I mentioned earlier. You are absolutely correct that the Infinity Engine AI is poor -- and remains poor (but better) with third party mods to improve it. The reason is the scripting language -- you can't perform a simple loop in an IE script, much less determine the range between yourself and a particular foe. I'm fairly confident (although I hope that I'm wrong) that the scripting language in PoE is going to be similarly limited -- certainly if it isn't, then none of the AI in the beta even makes a gesture at using the additional functionality. Going way off topic (although, honestly, is there much left to say about the engagement implementation?): The following features are absolutely essential to build halfway decent AI (& none of them exist in IE scripting): 1) Loops 2) Arrays (that you can loop over, that can be of arbitrary size and persist between script executions) 3) The ability to determine the range and bearing between any two objects in the area map. 4) The ability to generate a path to move an object between two arbitrary points, and the ability to modify that path after it has been generated by adding intermediate waypoints. 5) The ability to quickly and thoroughly evaluate the benefits and costs of using an AOE effect at some arbitrary X, Y target within the area based on standardized criteria. 6) The ability to quickly and thoroughly identify the arbitrary X,Y coordinates where an AOE should be activated based on standardized criteria ("most damage to foes", "most damage to foes - damage to friendlies", "most foes CC", "most friendlies healed - foes healed", "most foes killed - most friendly's killed", etc.) 7) The ability to designate an action as the "best found so far" (which will be executed if the script times out) while still allowing the script to run additional logic to search for a better action. The ability to quickly and easily transmit complex (multi-variable) messages between different script instances, to allow co-ordination of activities. 3-6 need to be implemented as primitives, rather than allowing the AI designer to create their own, for performance reasons -- any interpreted langaugage (which a scripting language is going to be) will be very, very, very slow in comparison to the C++ / Java / C# that are compiled into the engine to begin with. Since the above functions will be called many, many times during the course of a reasonable AI script, and time for executing the script will need to be tightly limited, it makes sense to "hard code" them. #7 addresses this problem in a different way (by allowing a complex script to be interrupted if it is consuming too much CPU time). Nice to haves: * The ability to define user defined complex data structures and store them in arrays (e.g. C "structs" or even C# / Java "classes") * The ability to spawn additional AI threads, with the script executed defined at runtime (for example, to coordinate the activity of an encounter group in a way that will persist even if any individual foe is killed) Might be useful, but could live without: * The ability to identify when the game has been paused (by the player) to allow more complex / deep analysis to be performed, with the results cached to be executed once the game is unpaused (very, very hard to leverage on the AI designer's part, but potentially very useful) * The ability to "see" obstacles in the walkmesh for the area, so that the AI can take these into account in its decision making (again, this is very hard to implement) * Implementation of the "fog of war" for the AI (where the AI's knowledge is limited to the information that is in the combat log -- it will only know that a foe is fire resistant after it has tried to use a fire effect on it, but afterwords will automatically take this knowledge into account).

Unhappily, switching targets doesn't fix the problem, and generally makes matters worse. In the "stick with a single target even if it seems to be futile" scenario, you at least reduce the volume (and perhaps eliminate altogether) the attacks from the target that you are pursuing. In a 1:1 scenario, this leads to a draw -- in a 1:many scenario (where "many" = NPCs), this may result in a win, if you can corner the PC. Even in a many:1 scenario, the PCs other than the target are limited to ranged attacks only, which tend to be less damaging than melee attacks, at least drawing out the encounter. In the "switch targets to the nearest foe if you aren't able to attack your initial target" results in "ping-pong" behavior in the many:1 scenario ("many" = PCs, here) -- PC "A" starts fighting opponent "Z", but when "A" is wounded he runs away. "Z" switches to the nearest target (which the player can control with a high degree of accuracy -- "B"), "A" heals up, "B" runs away, and "Z" switches back to "A". The net result is that neither "A" nor "B" is ever seriously threatened yet can still use their (more effective) melee attacks rather than being limited to ranged attacks. I don't believe the inability to heal health (v stamina) damage is sufficient to change the math in this scenario, although it does make it somewhat less attractive. Note that the second form of "kiting" is how the AI works in Infinity Engine games, and is exactly what Sensuki is looking for when he wants to engage a foe with two PCs, then withdraw one (for healing), re-engage, then withdraw the other for healing. The "correct" solution requires an AI that is capable of the following: 1) It has to be able to position units under its control to make retreat unattractive (e.g. by engaging a foe so that you are between him and friendly units, ensuring that the most important targets end up in the "center" of a grand melee) 2) It has to be able to "pass off" responsibility for killing targets between units based on PC actions (a wounded unit that is attempting to disengage should be allowed to do so if and only if another unit will be able to engage). 3) It has to be able to predict (with some degree of accuracy) the movements and plans of the PC so that it can influence them (rather than always following the shortest path to the PC, it may be better to move away / perpendicular to the PCs predicted location to take advantage of terrain / other NPCs to pin the PC into place) I'm not sure it is possible to write an AI that can do the above -- I'm very confident that Oblivion has no plans to attempt it in this game (if they had, some shadow of it would have been implemented by now).

Well, if your only goal is to prevent kiting, this is pretty straightforward: You can detect when kiting is occurring by comparing the ratio of attempted attacks by the NPC vs. the number of attempted attacks by the player. If this ratio goes outside of some arbitrary bound (say 2:1) over some arbitrary period of time (30 seconds), the gods are angered, lightning strikes all the PC character's, which prevents all PCs from (but not attacking or performing other actions) for the next 60 seconds and imposes a hefty deflection penalty. I'm not suggesting that as a legitimate solution, but if the developers really want to prevent kiting, this would do the trick.

I read a couple of reviews myself (thanks for mentioning that they were out), and the 3-4 reviews that I read made it clear that there is no reason to pause the game, use the tactical view, or even use active skills on Normal mode. One pointed out that on Hard or Nightmare these features were indeed required, so YMMV.

That's rather amazingly broken, Sensuki -- but I have to ask, why aren't your fighters suffering disengagement attacks themselves when they retreat? I'm pretty sure that the intent is that they should, and that would tend to resolve the issue. In regards to Kjaamor's comment: The whole purpose of the beta is to point out and suggest solutions to broken mechanics, which is exactly what Sensuki is doing. If you disagree that the current implementation is not broken, that's one thing -- I disagree, but that happens -- but it appears that your position is "It's broken, but I'm sure Obsidian knows about it and will fix it in some mysterious way that I don't care to speculate about, but will be perfect in all respects". If that is your position, then I have to wonder why you are participating in Backer Beta discussions at all.

I have no strong preference one way or the other, but I want to re-emphasize the point that Ink Blot made: Other skills will unlock dialog options that will result in XP rewards (over and beyond what is accessible via the "ARGH! Attack!" option). This may take the form of new quests, extra rewards for completed quests, or simply a straight "Wow, that's an amazing insight, professor!" type choices. Obviously, quests unlock would only apply to side quests (critical path quests must be un-lockable for parties with any sets of skills), but side quests are likely to make up ~50% of the XP available in the game, so... In theory, at least, adding trap / lock XP is actually necessary, to ensure that maxing out the mechanics skill offers the same XP rewards as (say) maxing out the Lore skill. It is obvious that there will be many more opportunities for gaining trap / lock XP but one assumes that the rewards per instance will be much lower, so it is possible that a skill that appears in 3 dialogs (awarding 50k XP in total) would be balanced with mechanics -- if the total amount of XP available by unlocking every lock and disarming every trap is 50k. It seems very unlikely that Obsidian has gone through this level of effort to balancing the addition of trap/lock XP in the game, at least not yet (since it was just introduced), but it isn't impossible... Just my two cents.

It is irrelevant -- you cannot upgrade your pledge any longer. You'll be able to pre-order the game at some point in the near future, though.

Per earlier developer comments, you'll be able to add custom companions via the adventurers hall at about the same rate that you meet "standard" companions. Whether or not this will be enforced with a hard limit (you simply can't hire adventurers until certain flags have been set) or via a soft limit (you probably won't have enough money to hire companions until you meet the "standard" companions) is unknown.

Given the nature of the current feedback, if I were them (which I'm most certainly not), I would be planning on waiting at least a week, and maybe two, in the hopes that: 1) The amount of emotion involved in the discussions will have been reduced 2) With more playtime, some players may see the point of the innovations that have been introduced -- or, if that is too much to hope for, at least have more reasonable suggestions as to what needs to be changed. I definitely wouldn't expect individual OE folks to be responding to the type of threads that are currently active, as any reasonable response would amount to pouring gasoline onto a ranging fire.

I suspect that both of you are correct: The game was pitched as a game similar to the old Infinity Engine games -- but the developers never really wanted to do that. A more accurate Kickstarter would have been for a game that "...will reinvent the Western RPG genre, leading to a second 'Golden Age' of RPGs". Of course, that Kickstarter likely would have been considerably less successful... How to resolve this conflict? I don't think there is a good answer -- the best Obsidian can hope for is to continue down the path that they have chosen and hope that by the time the full game is released that the original backers will have accepted the new mechanics as (at least) acceptable or are no longer participating in discussions (to avoid negative reviews). That seems like a long-shot at this point, but there are still months to go until release. The alternative is to try to redesign the games mechanics from the ground up -- and it seems very unlikely that the budget will cover such a major redesign at this point.

Yes, that's the largest issue.