Quote:

Original post by Anonymous Poster You are talking about a AI plot controller (which directs all the non-player events -- runs the background world). Events and quests (and faction orders/directives??) would then be generated appropriate to the world situation and the results of these quests (player actions) would be aggregated with the AI controlled stuff to then change the power balances(, etc..) and define the new world state. AI goal/task planners could be used to do this and a hierarchy of control objects (world...local scope) to run the different abstract levels of behavior.

Hey, you are gettting really close to the underlying design of my dream game that I've always wanted to create here! (the reason I started posting on GameDev is to get the will to get it going). I was hoping this thread was going to go that way...

Quote:

Of course this still requires ALOT of scripts (code) to run the goal-task-solutions and the evaluation functions that examine the world state and decide what should be done (select strategy/tactics). The mechanisms is general so must handle a broad spectrum of possibilities and requires significant amounts balancing/testing to create a stable/functional world. (Remember this is AI independant of the game mechanics) This is magnitudes more work than having a static 'superplot' to work around and to script auto-generated quests within much smaller/simpler limitations. Pre-canning is always easier (thats why most games have done it so far).

I'm not sure about this. Obviously it's a lot more work than a standard pre-designed linear plot, but if you're comparing your smaller auto-generated quests to the world changing ones, then I'm not sure. The difficulty is how the world and the possible interactions are represented for the AI to work with.

Quote:

I still think that it will be more cost effective to have a GM who monitors and directs plot (and intelligently compensate when things get too out of balance). The AI would take care of the day to day flow of world, but the GM oversight could direct plot at a high level.

Well, possibily, but as superpig says, that's not much good for non-MMORPGs (which is what I'm interested in making).

Quote:

Original post by superpig Quote: Original post by Anonymous Poster Of course this still requires ALOT of scripts (code) to run the goal-task-solutions and the evaluation functions that examine the world state and decide what should be done (select strategy/tactics). Well, maybe. I'm still thinking that such scripts, if required, could be largely generated on-the-fly. It's an artificial game designer, if you will.

You must be refering to the scripts (generated ones) that would be unique instances to run a customized 'quest'. Yes a script builder/compiler would be useful for that (to minimize runtime load).

But I was thinking of the 'scripts' (AI code) that do the building. They have to analyze the situation and then define what components and theme make up the quest's mini-plot. Then scipts are built the directives that setup the needed props/npcs/terrain and fill in parameters (select behaviors) of the NPCs/monsters involved. Finally there would be some directives that defined how the results of the quest would modify the world state (ie- Orc domination factor - 10 and clear their 'ownership' marker for that world area).

There are other AI scripts that maneuver abstract control of the various factions and do strategy (make world state changes follow a logical pattern as if 'intelligence' was guiding events). There could be a coarse level that might not be too complicated, but then at more local levels (where players can see the effects) the number of details to change ibcreases and the way they fit into the local area have to make sense (ie- a castle assault requires specific unit deployment versus a world level 'abstract' thrust into this map area..)

---------

Quote:

Quote: The mechanisms is general so must handle a broad spectrum of possibilities and requires significant amounts balancing/testing to create a stable/functional world. Well, stable/functional is not necessarily desired. If the player goes to destroy the colony's fusion power plant, or assassinates the king, chaos should ensue, society should unbalance.

I was thinking of 'solutions' that match how the game mechanics work. (ex- when the enemy has such and such assets in an area, what are the comperable assets this faction needs to deply (and how). ) Different situations take different tactics (often more than one possible choice). You dont want some overly simple decision making logic just throw its entire army at an enemy location. (How big is the tactical logic of something like Warcraft -- then converted to be more generalized ...)


--------

Quote:

Quote: This is magnitudes more work than having a static 'superplot' to work around and to script auto-generated quests within much smaller/simpler limitations. Pre-canning is always easier (thats why most games have done it so far). I'm not convinced, but I guess I shouldn't open my mouth again until I've tried implementing it myself [smile]

Well the 'magnitudes' part is true if we are comparing the precanned scripts that most of the games like Half-life, Return to Wolfenstein etc.. employ, where you are led by the nose thru a series of choreographed scenes.
A generalized behavioral system is alot more work (even when it has solution templates that are reused for similar situations). You have to handle ALOT more cases to react to what the player might decide to do and deal with the consequences (way the world balance might shift).

Quote:

Original post by Trapper Zoid Quote: Original post by Anonymous Poster You are talking about a AI plot controller (which directs all the non-player events -- runs the background world). Events and quests (and faction orders/directives??) would then be generated appropriate to the world situation and the results of these quests (player actions) would be aggregated with the AI controlled stuff to then change the power balances(, etc..) and define the new world state. AI goal/task planners could be used to do this and a hierarchy of control objects (world...local scope) to run the different abstract levels of behavior. Hey, you are gettting really close to the underlying design of my dream game that I've always wanted to create here! (the reason I started posting on GameDev is to get the will to get it going). I was hoping this thread was going to go that way...

Ive been working along those lines for the last couple of years. I keep getting sidetracked into associated areas lie server-cluster intercommunications (and client), graphic representation (3D and terrain areas), abstract vs realtime behavior (most of the world to operate abstract and just the areas the player(s)
are in are full detail -- requiring rolling out chunks with their own local data heaps...), and a custom script language compiler/interpretor (now mostly abandoned in favor of Macro assisted C code).

The planner/goal/task/solution system would have inheritance of behaviors (the templates I often mention). The task selector/prioritizer is pretty ugly because of the added complications of 'opportunistic behaviors' -- which requires constant reevaluation of the local situation. The solutions are really finite state machines (with retry/reevaluation paths). The absolutely worst part will be the evaluation functions which analyse the situation and measure probable success versus cost and risk (with allowance for uncertainty being handled). The functions will use attributes of the object (like a Caution factor for risk and a Greed factor for cost vs. payoff) as part of the evaluation.

And as is normal for AI, the engine part is only 10% of the work -- the other 90% is developing the data (scripts) that match the particular game mechanics and specific game environment (the actual game world).

The game I am building for is an world exploring game (so throw in sidetracks of auto-generating terrain + quests). Even employing various 'infinite universe'
techniques, there is alot of custom data patterns that are needed for the scheme to generate a coherant world 'auto-magicly'.

You know the thread is getting slightly off topic. But the simple question for the amount of work you guys are talking about is how central do you want the game's random quest generator to be to the game as a whole. In MMO's they are important, but they are not central to the game. In a game like Shadowrun where the sole purpose is to do mission after mission a quest generator would need to be very powrful.

Quote:

Original post by robert4818 You know the thread is getting slightly off topic. But the simple question for the amount of work you guys are talking about is how central do you want the game's random quest generator to be to the game as a whole. In MMO's they are important, but they are not central to the game. In a game like Shadowrun where the sole purpose is to do mission after mission a quest generator would need to be very powrful.

Good question! This might help clarify the different directions everyone seems to be going on here!

For me, since I'm going on the design I'm presently bubbling over in my head for the game I'm ultimately aiming to make, the random quest generator practically is the game, so I'm not phased from the fact that the whole game design has to be built around that fact.

However, if you've got an existing game design and are looking to bolt on some random quest generation to that, then your initial list of simple one-off quests (with the occasionaly reoccurring theme and bad guy), while less powerful and extensive, would nevertheless be a fine addition to your MMORPG design. And of course, would be a lot less work to implement! [smile]

Quote:

Original post by Trapper Zoid Quote: Original post by robert4818 You know the thread is getting slightly off topic. But the simple question for the amount of work you guys are talking about is how central do you want the game's random quest generator to be to the game as a whole. In MMO's they are important, but they are not central to the game. In a game like Shadowrun where the sole purpose is to do mission after mission a quest generator would need to be very powrful. Good question! This might help clarify the different directions everyone seems to be going on here! For me, since I'm going on the design I'm presently bubbling over in my head for the game I'm ultimately aiming to make, the random quest generator practically is the game, so I'm not phased from the fact that the whole game design has to be built around that fact. However, if you've got an existing game design and are looking to bolt on some random quest generation to that, then your initial list of simple one-off quests (with the occasionaly reoccurring theme and bad guy), while less powerful and extensive, would nevertheless be a fine addition to your MMORPG design. And of course, would be a lot less work to implement! [smile]

A simpler method would be the Chinese Menu style of randomization.
Mixing different quest details and using combinatorics to make quests different
each time.

There would be a large number of quest patterns, each with a custom set of potential substitution.

For each one of a number of quest patterns there would be a preselected list of
appropriate quest givers, locations, bad guys, loot types, quest items.
Verbage/storyline text specific to the quest pattern would have formletter fill-ins (more than one dialog pattern could exist -- a list of them allowing some variation).

The mechanism does not need any logic particular to each pattern as the preselected detail option lists would already be appropriate to the quest.

The mechanism is easily extended by extending the lists.

Additional patterns can be added (the more the better). Patterns can be split into multiple variants (and thus better customized)




The simple quest system would require:


A quest selector that decides which quest pattern to use when a quest is to be built.

A quest giver -- either a NPC who is always present or an incidental NPC who goes is temporary. A temporary NPC has to be placed somehow.

Dialog needs to be created and assigned for Questgiver to supply the quest info.
(and maybe for 'boss')

A quest trigger mechanism to activate things like the payoff after the quest succeeds. (If on MMORPG, could be used to trigger quest destination activation only for the player with the quest.)


Each quest pattern would have a prespecified list of locations appropriate to it. (ie- get information quest destination is a tavern or inn or library etc.. and a rescue the hostage destination would be orc camp, evil wizard castle or troll lair). The world should be large enough to have many locations where quests can be played out -- so the player isnt going into the same castle every time a 'castle' quest is generated or into the same warehouse where the gangsters have their base. Most sites should be in a neutral state
when not assigned to a quest -- empty so that when a player wanders around eploring

A way to place opponents and props (bosses/mobs, traps, loot, etc..) in the quest destination. (maybe place some obstacles along the way to the quest site)
Most 'monsters' have simple behaviors (ie- kill the player) so simply placing them at the quest destination will be good enough for a simple quest system.
The bosses may have some dialog (or just a 'big statement') they give before the mayhem starts. (Boss 'talk' data would be assigned similar to setting on questgiver).



Data tracking what quests are in progress and what assets are assigned to them is needed to prevent two concurrent quests being in the same destination place etc..

Some statistics for 'last used' might be useful to tag specific quest options to keep them from being used again immediately.

A probability/frequency factor for each pattern type could allow the programmer to control the frequency of particular quests types (ie - lots more kill the nasty in the forest quests versus much more infrequent 'go kill the dragon' quest.


Quest patterns may have a attribute to indicate what plot stage they are appropriate for (early game, middle game, end game) and/or what player character level they are appropriate for. The quest selection mechanism could this filter out quest patterns that were not appropriate.


I suppose something like XML could be used to organize the quest data and option lists. Of course the named idetifiers have to be matched up to game objects
(ie- 'BIG_ORC' on a quest patterns badguy list will have to be matched to a particular monster object type (and specifics) in the game).




Pattern:

Hero go to LOCATIONX and recover the ITEMX from BADGUYSX for a reward of REWARDX.

LOCATIONX = { AbandondeCastle, CaveOutsideTown, HermitsHut, DesertedGraveyard }

ITEMX = { ImportantLetter, PreciousRing, MagicBean, KingsSword }

BADGUYSX = { BigOrc & BunchOfOrcs, EvilWizard & KillerBats, BanditChief & BunchOfAssasins, EvilCyborg }

REWARDX = { ClueToBigQuest, BunchOfGold, TreasureMap, HardyHandshake }


4x4x4 = 64 combinations from just one pattern...

Oops, 4x4x4x4 = 256 (even better...)

Thats just 4 option lists and you could add several more 'options' to increase
the number of combinations.


So have 16 different patterns each with thant many combinations = 4K somewhat different quests.


A higher level of organization: area could be added to the mechanism.

Each 'area' could have its own set of quest patterns (allowing better customization)

(ie - Small Hamlet (level1) has its own quests different from the quest patterns
in Capitol City(level2) )

Quote:

Original post by Anonymous Poster Pattern: Hero go to LOCATIONX and recover the ITEMX from BADGUYSX for a reward of REWARDX. LOCATIONX = { AbandondeCastle, CaveOutsideTown, HermitsHut, DesertedGraveyard } ITEMX = { ImportantLetter, PreciousRing, MagicBean, KingsSword } BADGUYSX = { BigOrc & BunchOfOrcs, EvilWizard & KillerBats, BanditChief & BunchOfAssasins, EvilCyborg } REWARDX = { ClueToBigQuest, BunchOfGold, TreasureMap, HardyHandshake } 4x4x4x4 = 256 combinations from just one pattern... (added in your correction here)

That's pretty much a simple summary of what I think could be done as the easier MMORPG approach.

However, the problem with a too simple approach is that this isn't really 256 different quests, it's just one quest wearing different hats. If the quest seems exactly the same for every combination, just with different tilesets and animations, it won't solve the bigger problem of how to dynamically generate interesting game elements.

Quote:

Pattern: Hero go to LOCATIONX and recover the ITEMX from BADGUYSX for a reward of REWARDX. LOCATIONX = { AbandondeCastle, CaveOutsideTown, HermitsHut, DesertedGraveyard } ITEMX = { ImportantLetter, PreciousRing, MagicBean, KingsSword } BADGUYSX = { BigOrc & BunchOfOrcs, EvilWizard & KillerBats, BanditChief & BunchOfAssasins, EvilCyborg } REWARDX = { ClueToBigQuest, BunchOfGold, TreasureMap, HardyHandshake } 4x4x4 = 64 combinations from just one pattern...

I tend to disagree here. I see at most with this simple set here. 4 quests, maybe 16 depending on how dramatically different the change of bad guys will be to your game. All of them are Item Retrieve quests. The only real difference is the map. After playing COH I can tell you that there really is no difference between trying to find a gun rack, a stack of dynamite, or even computers. Its just different window dressings for the same thing. The reward does not change the quest at all. Its like saying you have a larger variety of bad guys if one gives you 50xp and another gives 58xp with no other changes.

However you are right, the simple menu system is infact what I have in the original post. However I went for a larger perspective than you did in your descritpion. In fact you're description above, could be easily incorporated in the main idea.

Some things that I definately feel need to be incorporated into a random quest generator, are as follows.

Unpredictability. The player should never feel 100% confident that the quest they get will work like they have planned. This is why I incorporated the surprise element of Step 2. If your player is sitting there and says "I've got another (insert quest type) here...this is what I need to do" then I believe as a developer you have failed. Thats not to say that the quests should be put together so hap-hazardly that they make no sense, but that the player should never be left to feel complacent.

Connection. One of the biggest problems with Random quest generators tends to be that they are, well, so random. I know this is an oxymoron, however, the point is that depending on how you get your missions, there should be at least some tenuous connection between a few of your quests. Thats not to say that EVERY quest needs to connect, but some stuff needs to connect. It gives the game a taste of continuity.

As for numbers...

I listed 6 very general goals in the OP. If you combine any number of those goals together to form one quest you get a large number of quests...don't quot my number because statistics was never my strong point... 720

If you do at least two variations one where the goals are done in a chain of dungeons, and another where every one is done in the same dungeon, that's 1440 quests.

If you toss in variations of how to do the quests, say about 5 different types. (stealth, kill all, mine-field, etc)that gives you 7200 quests. Now toss in the chance of tossing in a random surprise in the middle of a quest (i.e. replacing the quest with one of the others), and that bumps your number of quests up to 5,184,000. This is without talking about map options, rewards, or even specific targets.

Quote:

Original post by Trapper Zoid Quote: Original post by Anonymous Poster Pattern: Hero go to LOCATIONX and recover the ITEMX from BADGUYSX for a reward of REWARDX. LOCATIONX = { AbandondeCastle, CaveOutsideTown, HermitsHut, DesertedGraveyard } ITEMX = { ImportantLetter, PreciousRing, MagicBean, KingsSword } BADGUYSX = { BigOrc & BunchOfOrcs, EvilWizard & KillerBats, BanditChief & BunchOfAssasins, EvilCyborg } REWARDX = { ClueToBigQuest, BunchOfGold, TreasureMap, HardyHandshake } 4x4x4x4 = 256 combinations from just one pattern... (added in your correction here) That's pretty much a simple summary of what I think could be done as the easier MMORPG approach. However, the problem with a too simple approach is that this isn't really 256 different quests, it's just one quest wearing different hats. If the quest seems exactly the same for every combination, just with different tilesets and animations, it won't solve the bigger problem of how to dynamically generate interesting game elements.

Thats why you then have a number of patterns. Each pattern could have 'logic' associated with it to change its form completely - like:

A treasure hunt that requires gathering a set of different items (some from other quests) or pieces of information.

A simple exloration/ pilgrimage quest (go someplace and return alive)

Deliver the item.

Fetch an item.

Find an item/object/location.

Find an item/object/location and destroy it.

Search out an NPC and do the quest give by them.

Build something somewhere (for games with buildables)

Earn/get X amount of money to purchase a goodie.

Attain a certain level of skill (or other char development)


Compound quests of one or more of the above patterns - quest chaining.

etc...


Unfortunately a game cannot do what its not programmed for.

Depending on what you call 'interesting', it may only be produced by
specific and extensive custom scripting which costs lots of $$$ and thus
only a small number can be included in the game. They really cant be
generated randomly and should be reserved for the main plot line and the simpler random ones used to fill out the required gameplay hours.