Quote:

Randomness is only a component to prevent that wonderful game aspect called 'camping'. Similar seeds control probabilities of patterns of quests (again adaption scripts tailoring quests to fit the current plot environment and the local situation factors). I think I talked about this elsewhere - plot entities that are dynamic/have behaviors ( prefereably affected by player actions to some extent, if not by DMs guidance as the game goes on) and which have areas of effect/influence. Factions, gods, whatever rationalization drive the main plot which spawns lesser regional plots down to individual quests. The dynamics of the plot entities pushing at each other constantly stirring the environment (hopefully in a logical way that the players can judge and reason the patterns).

Camping can be effectively prevented using deterministic methods - for example repeatedly killing bandits in an area increases the repulsion factor for bandit spawns in that area. Increasing the value of trade passing through increases the attractiveness. The chance of bandits spawning is a factor of the aggregate attractiveness of the area for them. Random chance is reduced (although it is used for precise variations in the spawn event such as location within an area and precise numbers in the spawn group) and a more dynamic system can then be presented - that obeys rules a player might expect, which gives a sense of life to the game world.

Quote:

Depending on what kind of world terrain there is, the precanned terrain seeds (or local generation at the time the quest is being built up) only need be predefined to the extent of guaranteeing the required path options (and the rest left til later - ala 'lazy evaluation' - to fill in the final details (contours etc.. might actually be the lessor ammount of data in a rich detailed world.)

Forcing generated terrain to conform to a predesigned set of paths is doable, but requires more complex generation algorithms - certain geographic features would have to be detected and 'cut' if paths intersect them, or additional features might need to be added - for example rivers might require the automatic placement of a river (object) or ford (terrain modification), dependant on the specific type of feature and/or defined path. This sort of thing might be better left to a designer to implement and have path-to-impassable features flagged as a warning on the terrain segment, indicating a designer's input is required.

Quote:

Having a wider number of quest types (some maybe required for general advancement -- including single player quests) might also force more generalization -- yet if a player wanted to specialize, a large world system could also be able to provide matching quests to challenge those with those higher skills (preferably ways to be challenging without some lame doubling the monster count or upping the trap's difficulty coefficient).

I agree. UO had a couple of places where a decent lockpicker was very handy to have around. More situations where a characters skills are called on would be good. Player skill as well can be tested through the choices they make tactically - at present in MMO's mobs are typically stupid. They don't pull back and regroup, or counterattack. They don't patrol. They frequently just stand stupidly waiting on a spawn point for a player to aggro them. Complex AI isn't really required (or indeed practical for the large numbers of mobs a server might have to handle) but at least some form of behaviour is required.

Quote:

One thing I though that they could have done in UO (without too much work) would gave been requiring players to travel to different parts of the world to seek out 'instructors' for each skill (for GM at least). It was a shame all those places on that realatively large map and no reason for players to go to them (in the early days I explored every part of the map possible just to see what was there.) Make higher skill advancement itself a source of potential quests...

Absolutely. There are all sorts of mechanisms that can be used to implement this - Bloodspear has a mechanism which allows faster progression when under the tuition of a more experienced character using the teaching skill. Whilst mastery *can* be reached on your own, it's a lot easier to learn from someone else.

Quote:

Reputation summary on a pulldown off the avatar. Recent achievements listed and retaining only the greatest of the older ones. Badges/tokens of honor??? Complex game theme oriented titles/ranks. Bards singing your praises when you walk into town??? NPC behavior being altered towards great/miserable achievements... Achievements only reported if witnessed or if trophies/proof were brought back.... Official recognition.. Membership in the group/party that made the 'achievement' as a different kind of reputation....

We avoid having 'trustworthy' character identification on the avatar. Lying, cheating, spying, stealing and robbery are all valid and game-legal actions - if someone wants to hide their identity, or present a false one, there are mechanisms to do so. Of course, there are also mechanisms to see through the lies.

Quote:

Why not explicitly in some cases??? Depends on the specifics. Joe Blow killed the dragon menacing the town .... no more dragon attacks for now.. Jack Blow robbed and killed the kings nephew, a bounty is read out against him.

Yeah, these are cases where there really isn't anything between action and result. There's no choice but to explicitly report them.

Quote:

I think a mechanism more complicated than a tree is needed (script logic with states and probably fuzzy logic type partial changes/influences). The interactions/results of simultaneous quests on a local situation are too complicated and probably too rigid if they are built independant in a predefined tree. External factors can change and may shift a quest significantly (many quests wont be completed in only a few hours...), though remoteness can alleviate that.

Trees are perfectly adequate. Implementing fuzzy decisions at tree nodes is the way to go - doesn't stop the overall structure being a tree. Procedural event generation based on world state is what I think you're talking about here - that is to say event chains which aren't necessarily related directly, but that may trigger other events.

Quote:

Maintaining a stable game world state might be the job of DMs inserting plot adjustments (preferably without being too arbitrary or heavy handed). Designing a game system to automaticly do so in a more openended (yet cohesive) world mechanism is prohibitive. Give the GMs the tools to impliment those changes gradually without tedious detail rewriting, as well as incrementally expand the available templates (quests, terrain, plot entiries, NPC behaviors, etc...) to continually improve the players game experience.

Having GM's online all the time to do this is really expensive. As far as the system *can* be automated (and I am in no way saying it will require no supervision at all) it should be. Standard (fetch / escort / destroy / recon) quests should be designed in such a way that each is constructed from interchangeable chunks, allowing variety between quests of the same type, and chaining to other quests. I agree though, that tools for rapidly building quests should be in the remit of any RPG codebase.

Quote:

'Trees' to me denotes precanned/predetermined precalculated options (inflexible/limited by being calculated before other factors/influences appear). You have to have a 'tree' of coded result states (a template) but I would want those results to be more like flavors of results (ie Success/Failure) which are then synthesized/realized in the actual end situational state. More complicated results are possibly determined by different success/failures of the quests sub-situations ( ie- you kill the dragon but dont get the princess who was inadvertently killed too). Exact results (in a richer game) are dependant on a multitude of situational factors that cant be predicted (the king who sent you was deposed, is your achievement simply canceled??).

Trees can produce flexible results, and can be generated procedurally (a wolf might have a different tree of potential reactions to a bandit) - I'm referring to the data structures at quest-relevant points, not the paperwork or logical flow of the event itself. In any regard, you require an absolute determinisitic method to resolve logical states as an event (or quest) unfolds. This is best held as a series of yes/no flags that are re-evaluated when required. State trackers are created when a relevant entity is generated, and removed when no longer required. It is not a requirement that the end of the logical path for the event be reached for events to have an absolute effect on the game world - modification of these state trackers does that automatically.

Let's examine your example: A quest from the king to kill the dragon and rescue the princess. We'll assume that killing the dragon is a national quest (worthy of reward no matter who the head of state is) and that the

Let's identify the states that must be tracked. First, that the dragon is alive. This would be a pre-existing state, not directly related to the quest itself. Second that the player has entered the dragon's cave. Third, that the princess has spoken to the king, which is a good indicator that she's back safe. Fourth, that the princess is alive. Fifth, that the character speaking to the head of state (not king!) has accepted the quest. Sixth, a combined state indicating the quest is complete: ((princess has spoken to king AND dragon is dead) OR (princess is dead AND dragon is dead) OR (dragon is dead AND head of state != king)).

First, the player accepts the quest from the king - the player is loaded with the quest ID. Without accepting the quest the player might not be able to claim the reward. Alternatively (and I think a better choice) this state can be omitted and a simple check on proof of dead (the dragon's head) being given to the head of state could be used instead. Note we're separating the head of state from the king - the two are not necessarily the same entity at the start and end of the quest.

The player toddles off and finds the dragon's cave. We'll take it as asleep. A tree comes into play as the player enters the cave - a simple one - if the player sneaks, the dragon has a 25% chance of waking, if the player walks normall a 50%, and if the player charges in 100%. The tree is activated when the 'player has entered cave' state changes. We'll assume the dragon wakes and attacks, rather than evaluating an AI tree based on the player. The player has entered cave state resets, so the tree can be re-evaluated the next time a player enters the cave.

In the fight the dragon toasts the princess - the princess is dead state is triggered. The player kills the dragon - the dragon is dead state is triggered - which will cause attacks on the kingdom to immediately cease, as the attack event relies on the dragon not being dead.

On returning to the kingdom, the king is still alive - the player talks and a tree is evaluated:
First, that the player has accepted the quest - true.
Second that the dragon is dead - true. A partial reward is due.
Third that the head of state is the king - true. Evaluation continues.
Fourth that the princess has spoken to the king - false. No reward.
Fifth that the princess is dead - true. No reward (possibly punishment!)

At this point the precise result of the quest is known - whether the player is due two rewards for completing both criteria, or whether they're due a reward and a time in jail for killing the dragon but getting the princess killed!

Quote:

Within those 'flavors' there might be alot of optionals and partial results and invalidations/cancellation of tree branches (and added new ones? - via smart templates substitutions) resolved via analysis of outside influences that have changed since the quest began (a good one is that another party snuck in while you were fighting the dragon and stole the loot/proof/princess OR someone did a spell that changed the dragon from an evil one to a good one)-- could you predict that, should you have to map them all out ahead of time??

The states that alter during gameplay are not necessarily evaluated all at once - although in the example above it isn't very clear, as most evaluation in the example is in conversation, and we set very definite goals. Fuzzy logic can be used in state assessment - for example, a measure of the dragon attack frequency (it's been delayed sufficiently for the quest-giver to believe the dragon is dead). Conversion of the dragon's alignment would alter the attack frequency in this case. It's a question of the states that need tracking - and this is a question of good design, either in the procedural mechanisms that generate them or in manually designing state criteria. Everything will eventually boil down to a simple boolean assessment.

Quote:

Depending on how flexible the players powers are , can you possibly map out all the consequences ahead of time, IF you want to have quests more complicated than the usual 'fetch' or 'deliveryboy' or 'bounty hit'. You might say that you can cascade simple quests to achieve that (if all done ahead of time?), but will they meld cohesively and flexibly if one quest stage's wide output result space isnt mapapble into the next planned stage's input space (or if you try, you have to map out the combinatoric explosion, in full detail... AND it may never even be used!! AND you have to save it all somewhere!!! ) The trees might exist within one 'stage' but there could be a large number of distinct results each leading to a properly fitted next stage (isnt it more efficient to built the next stages tree with the specific result of the earlier stage???)

Sure, its a question of what states you wish to evaluate, where you place the state assessments, and the results of the assessments. Abstract states are somewhat easier to link in general than definitive states. Using specific results rather than states to link stages is not a particularly good idea - as you've mentioned, the flow of events may require more than one assessment tree. Portions of the trees can be removed as relevant states are removed. The whole point of using a tree is to limit the states that need to be evaluated.

Quote:

The smart scripts methodology (your 'force fit') would do these quest 'stage' recalculations at the appropriate time. BUT if you are looking for more feasible use, smart scripting to shape 'precanned' trees for simplex quests can still be done to vary the quest patterns and make it 'fit' the current situation more organicly.

No, our 'force fit' is a purely physical thing - we use it to adapt route tables and / or geometry, but it has little to do with scripting or event generation directly, with the exception of placement of 'sets' into the game world, which again is mostly done by designers, since our world is generally fairly static. Examples of things we would place are bandit camps, campfires and other 'small' temporary objects. Things as large as keeps would usually be placed manually. I was referring to placing actual objects in the world (such as trees (plants)) and adapting the meshes to the existing terrain.

Quote:

I was talking about most of the quests (including complex ones) being automaticly generated and run. The DMs' intervention would be to pereodicly give some 'intelligence' to the high level factions driving the main plot, by guiding general orders/actions that trickle down thru the more automatic reactions/behaviors of the sub-entities (Orc Nation move west!! -- abstract high level actions) Another is filling in the flowery descriptive crap that explains (possibly obtusely) why things are happening (rantings of the mighty leaders, etc..). The GMs could intervene with a battery of interesting 'influences' (new enemies, quirky events, arbitrary acts of gods.... )when the game is stagnating or getting out of balance (players are doing too good and need more substantial challenges in the world against them).

Yeah, we have something similar, but a lot of the balancing acts are arbitrarily generated in the design. Whether this works well or not under a real player base has yet to be seen. If it doesn't we can turn it off easily enough.

Quote:

How do you playtest the game ahead without subjecting it to a real load of players??? You cant. Making a mechanism that allows the GMs to easily reallign/fix/compensate much faster than the in the previous 'more static' games AND do more specially staged events --- with an automatic system that can absorb the inevitable goofups (Oops, the Orc Nation half wiped out by overly zealous meteor strike from Olympus -- no matter, the Trolls will move in to fill the Vacuum) I posted before about 'abstract' entities with spheres of influence and behaviors that guide lower entities positionings/stances which in turn shift the balance of quests/random encounters, etc...

No, the best you can do before beta is statistical analysis and prediction - assuming certain behaviours will occur based on experience with other games.

Quote:

Programmers would do the new quest pattern/template generation (subject to adaquate testing of course) and then be deployed into the set of those available for the games automatic mechanisms (on all servers). The hierachical nature allows replacement/additions at the highest quest pattern level as well as at the lowest detail generation option lists.

Erm, not quite sure what you mean there. We have 'quest chunks' that take certain states as triggers and resolvers. These are held in lists for most of the main areas in the game, and select or place appropriate NPCs, objects and 'sets' when active. NPC groups can also place 'sets' as the move around (notably bandit camps). Selection of location is by category and location (an inn, a hovel), selection of NPCs by primary role (NPCs are more specialised than players) and location.

Quote:

I was refering to the programming of templates (script logic) not being the job of DMs, but of real programmers. The GMs create instances to which the templates are applied (building the undelying patterns is out of their scope). The GM editor design would have a wizard like interface to expedite their task (pulldowns/sliders/textbox/radiobutons/checkboxes,dragNdrop etc..).

We have a superclient application that sounds similar. The overall flow of a quest should not be confused with the tools to build it. I agree that providing an effective toolset is within the remit of the programmer, but the actual 'decision making' of the quest is too often determined by the quest itself - in our dragon and princess example, the implementation of the gamestates and areas for checking is the programmer's job - but what states are altered when a player enters an area are the remit of the designer. Certain states (like the live/dead state of an entity) are obviously updated according to fixed rules and so do not require direct designer specification.

Quote:

The DMs generally would also not set up specific quests for the game, as the overall design is for differentials between good and evil or faction sides, or other power structures/motives to be detected and THEY create the opportunities for player quest activities. Quest instances could be created by GMs similar to the process for objects/events/situations, but the game mechanism takes care of that most of the time.

Yeah, we do this by filtering quests through a player hierarchy - we apply broad scope quests at the top of the tree (what we term 'Regents') such as 'conquer a certain town', and allow the specifics of how that is achieved to be decided by the players themselves - players can act as simple quest-givers (generally in the supply / escort / destroy way) with varying scope as you go down the hierarchy. Broadly then, our mainstream quests are 'event-reactions' as far as players are concerned. Fairly simple AI is used in the absence of players at requisite levels in the hierarchy.

Quote:

When the GM is setting up a special/specific event (situation), alot of the potential attribute options would be automatically assigned by default by the scripting system -- inheriting themes and other local flavorings so that a GM does not have to manually insert all the tedious multitudes of data and linkages between objects that define the physical/behavioral/relational specifics of objects and entities. (Especially for a game world complexity a magnitude higher than any current one.) This is effectively what the automatic worldbuilder/quest system will do without supervision, but GMs can override or do the same peration manually when nessessary. I keep mentioning 'hierarchical' when I talk of templates, and this would apply to the GMs 'editor' mechanism. Entire sets of attributes can be assigned to an object by assigning the object a template sub component, which itself is a scripted template that will searchout and fetch relevant information to build the object (and may in turn have its own sub-templates). Effectively they are building blocks that are smart enough to fill in their own details and adapt themselves to their intended environment and are usually built of other smart building blocks (divide and conquere, reuse, etc..) which can create a combinatoric variability that so many of these games lack.

Obviously, certain objects or entities in the world can be defined to react to certain gamestates in certain ways - to have their own decision trees. These must still be originally defined by a designer, as must the gamestates in the first place but can be reused or tweaked as required.

Quote:

I was thinking of quests being staged like a play -- act 1 might be the part dealing with killing of the dragon (deal with the king with the logic tree 'contract'...), but a follow-on chained set of consequences to form a mini-storyline building on the results of act 1 (so if you couldnt kill the dragon the first time(some players might), the next 'act' is where you get the hint of that missing scale on its belly...OR depending on your game, if the Princess gets killed in act 1, the Angel with the 'Wish' allowing you to turn back time and save her could be act 2). Compound quests with multiple option substitutions of follow-on 'acts' (stages) would greatly expand the uniqueness of the game's quests. And for my mechanism which does 'lazy evaluation'-like last minute building of a quest's terrain and props it helps system efficiency (probably a good thing when the 'act 1' results might branch many ways and subsequent acts might reach to 5 or more....)

Yeah, this is an idea I was working with to some extent as well, although I use state responders to generate 'reactive' behaviour. For example - the dragon being attacked will increase it's overall aggressiveness. If it isn't killed, it will most likely go on a massive killing spree itself, or perhaps it's attack frequency on the kingdom will go up. Because most behaviour is determined by many fuzzy logic inputs it's difficult to predict behaviour, but behaviour always has a reason. Evalutation of fuzzy logic chains based on many world states is a lot easier than building a 'strong' AI for each creature, and has a much better result than the simple aggro radius that is prevalent in MMOs at present.

Compound, and cascade quests are two very logical building blocks - and have been used in tabletop adventure modules for some time. It's always good to generate a quest chain that has several activities, or modifiers on how tasks should be (or shouldn't be) accomplished. It's easier and more realistic to specify that fighting will fail the quest, than to specify exactly which form of subterfuge will succeed - and it should be the environment, not the quest itself that dictates the precise method.

Say we have a guarded (pre-designed) compound that the player has to retrieve an item from. The item may be spawned there when the quest is generated (not when the player accepts it), or maybe a clue to a new location (a compound in a different city, or maybe the item has been taken by other thieves which will need tracking).
It's surrounded by a wall, and has a single gate, at which two guards stand.
Perhaps there's a link to the city's sewer system in it, giving another possible point of entry.

By default:
The player can attempt to fight their way in, can attempt to stealthily climb over the wall, or could distract the guards by starting a fight somewhere, or could fast-talk the guards. Perhaps the guards are already distracted when the player arrives - as 'live entities' they should react to whatever is going on, in a similar way to the dragon (by player there I meant ANY player or more correctly, character).

None of these require any contrived or designed mechanisms on the part of quest, all are dictated by the characters involved (the guards and how susceptible they are to distraction or fast talks) and the environment (potential points of entry). It's an ideal candidate for automatic placement as an event-generated quest.

Yet still, it presents numerous solutions to a problem, which means that a variety of character types stand a chance of completing the quest IN DIFFERENT WAYS, without a very complicated set of scripts for the quest. Adapting the ideal to a procedurally-placed 'stage' is simple enough as well - let's assume the item has been stolen - a clue could be left pointing to a bandit group that is roaming - the actual item (at generation time) is placed in the inventory of a suitable, nearby leader of that bandit group. The item could be bartered for, fought for, or pickpocketed - all simple character to character interactions that should exist as part of the general system anyway.

I disagree that decision-making AI needs to be so CPU intensive to model flexible interactions between environments and characters. I think relatively simple statistical determination merged with fuzzy logic evaluation for characterisation and behavioural modelling is viable, and providing the relevant statistics and input gamestates are easily accessible that it should be quick enough.

I breifly scanned through most of the post in this thread, so if my rant here is redundent please ingnore it. The problem I have with this line of thinking is that the programmer doesn't HAVE to do everything. What I mean is player generated content. I think this is the games will have to go to give the variability players desire and resources available. Some of the best dungeons around for Morrowind are from the modding community, but for MMO's check out EVE Online. They're making what I think are steps in the right direction. The entire economy is player driven - two thumbs up. Also there's player generated missions, granted most of the missions right now are just fetch or kill missions. It is being expanded to much sometime this month. They're skill system ... Well, that's enough free advertising - let's just say that the game implements many novel ideas that work pretty well together.

I'm out

Quote:

The problem is (assuming we have a world as large as we've talked about) do you have to preplace all those quest sites AND then protect them from being ruined by other players not involved with the quest (forts with 2 guards are just ripe for being harvested by higher level chars before the questing player ever arrives). If you get rid of the freeform play and lockout other parties you could have quest areas prepared (holo deck system is easiest this way -- you can even run parties doing same scenario in seperate bubbles...) I myself consider that too contrived (I liked the way UO was, just was disappointed at how empty/under-utilized/lack of imagination so much of it was...)

What you refer to as the 'holo-deck' method is actually called 'instancing' - a singular instance of the required area is specially created for the pc/group doing the quest - this works well with abstract linkages (a shuttle ride to the corvette in starwars galaxies) and does provide a lot of fun for the group involved. In situations similar to SWG, it doesn't particularly ruin immersion since the instanced quest environment is totally separate to the main game world.

Within a contiguous world though, I agree with you, it sucks. I disagree that quest sites need to be 'protected' once created. With a relatively rich world, with a sufficient number of 'interesting places', selection of location for quests can be performed based on a 'through count' of players in an area - if the area has not been visited in some time, make it a candidate for selection. Another possible solution is simply to make acceptance of the quest a requisite for finding a key item (other people simply don't know where to look)- if the guards are already dead, and the place ransacked, it simply doesn't matter.

Personally, I'd prefer that even the item can be taken. Players can then attempt to track it down and barter for it if the reward is good enough. This introduces a certain level of reliance on good player-to-player interaction and also necessitates some form of item tracking for those special items - for example a sage in a town may have been used by the player that took it to identify the item - they'd remember the item, and who had it. When asked, they provide a clue for the seeking player. 'Proper' treasure hunts like this are something that aren't often put into games - current MMO's pander to the player a bit too much, providing waypoints to items / NPCs (with the exception of SWG where the waypoints are frequently horribly bugged) and otherwise spoon-feeding the 'plot' of the quest. I'd prefer to make the player *think* about what to do, rather than tell them like a 3 year old.

This sort of thing simply isn't viable for a mainstream product (reliance on the player base = possible frustration = loss of revenue from crybabies) but I think it has the potential to be a lot of fun. The only problem occurs when the required item is in the possession of a player that is never logged on at the same time and they're keeping it in their inventory. There are a number of mechanisms that can be used to encourage (or indeed discourage) the hand over without being too kludgy (faction standing etc).

Quote:

Im aiming at a much higher level of AI to get away from the dependence on tedious hand built content (smart editor and adaptable objects) to simulate a more realistic world (procedural generation and quests, high level GM interactions) and have its elements react to player interactions more flexibly (behavioral AI). I expect game companies to be doing more of the kinds of improvements that you refer to, but their shortcommings will eventually be seen. The things I refer to are a ways out yet, and will take alot of time to develop and be proven before they are adopted.

It's the Holy Grail indeed. I just want a nice cup, not a plastic beaker.

It's been about 5 years now since I've even looked at MMORPGs (played EQ for about two years) and it appears that nothing has changed. There's too much money to be made and lost by companies, so it's unlikely they'll try something new.

I don't think any MMO will ever satisfy me the way single-player or multi-player can, but if I had things my way, I would make the player become an extension of the character, whereas I think current MMOs make the character an extension of the player.

I guess I'll check back in another 5 years or so. :)