Naked Ninja said:
That's true, and indeed, bad design. Still, I think it might be because the AI isn't good enough to escape from prison by itself.
That's just rather silly. Clearly the standard way to get out of prison can't be escape. Any coherent system would have escape be a rarity, with serving out a sentence being the common case. In most cases where important NPC X got locked away, the PC would have to break
in.
In cases where it made sense for the NPC to break out, they could just break out automatically. There's no need not to include such escapes, simply because they can't be simulated in detail with the player watching. An AI solution is totally unnecessary in this case.
Their effort wasn't a remarkable success but they probably noticed the criticisms and will try to fix them in the next game. They might introduce new problems, sure, but I don't think it is fair to say they ignore the criticism.
Sure, but the frustrating aspect is how they go about "fixing" the problems. All too often, they don't look at root causes, but at symptoms. They then "fix" these symptoms (quite often introducing new problems), yet fail to address the fundamental issues.
For example, in a discussion on TES skill books, a junior Bethesda designer (level designer admittedly), identified this problem:
Problem: players tend to spend quite a bit of time activating every book on a shelf in the hope that he'll find one which grants a skill increase.
Solution idea: highlight the books that give increases so that the player can quickly identify and activate only those.
Directly from symptom to half-baked solution without the question "Is the fundamental mechanic actually a good one?" even getting asked. Personally I think it's an obviously pathetic mechanic, but that's not even the point: questions about the underlying causes need to be asked and addressed. This is one small example, but that type of problem-"solving" is clear throughout TES design.
If you went to a doctor seeping puss, and were given a hair dryer on your first visit, an ice pack on your second, and a portable freezer on your third, would you think:
Clearly this is a good doctor - on each occasion he addresses my complaints. The hair dryer to get rid of the puss, the ice pack to sooth the resultant burning, and the portable freezer to address the ice melting.
Somehow I doubt it. Such a doctor would probably be doing his best, but he'd be an incompetent fool nonetheless.
With specific reference to the AI, it's clear that the design is at fault. The attempt at creating a dynamic system is good to see, but the notion that it should be possible to do well without a radically expanded set of NPC-NPC interactions is absurd. Any simulation of a conventional world that allows NPCs to attack and kill each other, but has no system for diplomacy/negotiation, is doomed from the start.
For example:
some article said:
One character was given a rake and the goal "rake leaves"; another was given a broom and the goal "sweep paths," and this worked smoothly. Then they swapped the items, so that the raker was given a broom and the sweeper was given the rake. In the end, one of them killed the other so he could get the proper item.
What's the problem here? That the wrong guy had the rake? That the system is absurdly brittle? That the violence threshold was too low? That the only solution available to an NPC is ludicrous?
You can tweak/fix your way out of this specific issue, but it's not going to address the root causes. This is entirely predictable without needing to write a line of code - never mind get to testing. If you can't offer an NPC some reasonable means of conflict resolution in 90% of cases, then you can't do dynamic conflict resolution. To think that you can isn't ambitious or laudable - it's stupid.
I also take issue with this:
You're assuming you CAN sit down and map them all. I have programmed AI systems, and my experience is that because of their limitations it becomes a choice of how much independence you want to sacrifice to ensure the system is stable and predictable. Limit it a lot and you ensure it won't freak out, but you limit it's ability to adapt (the scripting end of the system). Give it more free reign and you increase it's capabilities but also increase the chance of it going fruity.
Of course you're right that there'll usually be some tradeoff between freedom and stability - but that's not to say that most situation types can't be anticipated, and designed for. You don't need to map out all the possibilities - you need to anticipate the important classes of possibilities, and adapt to them. So long as you can deduce that e.g. "Where X is an even number, Y is true", you don't need to cover every case of "X is even" individually. With respect to Y, all that matters is that X falls into that huge class.
There's no simple general formula for this kind of qualitative design/balance/anticipation - it takes skill. However, the fact that you can't either do it perfectly or systematically in most interesting cases, doesn't mean that it can't be done at all. You'll always need a lot of testing and tweaking - but by far the most efficient/cheap/versatile place to do that testing is in the initial design (/requirements) phase. Problems anticipated early are hugely simpler and cheaper to fix than those discovered late in development.
Leaving most testing and analysis until late in development is foolish (I'm presuming that they are knowingly not thorough early on - maybe they think they are, but are just crap). A software architect who adopted a "We'll throw some reasonable-sounding ideas together, and test things later..." attitude, would probably get fired. Such an approach to game design is no less sloppy.
Naked Ninja said:
Here's hoping they iterate and improve that tech.
Here's hoping they stop with the mindless iteration, and start some rethinking/redesign.