I'm trying to design a system to manage missions for my third person shooter. I'm hoping to use xml to store the mission data but i'm not sure about the best way i could design, store and manage missions. Missions will likely be composed of multiple objectives ie get to certain location, kill guards, infiltrate complex, steal item, return to sender. Does anyone have any experience or advice about the best way to lay this out.

It really depends on your game and how linear the missions are going to be. You'll want to break your mission down into a sequence (list, graph, tree) of goals. Each goal will have certain success criteria, depending on your game state. So I'd start from there - create a class to compare the current world/player state against a set of criteria (kill all guards, gather 100 potions, etc) and determine whether or not your criteria are fulfilled. Make sure that class gets updated properly when the player does something. Then create a goal class consisting of criteria. Then create mission class consisting of a series of goals.

Programming and design are easier to digest in small chunks - start from the base and build up from there.

At my previous job, we used scripting languages to control mission flow. The scripting language we used was called LUA. Each mission would have it's own script file (eg. mission1.lua,mission2.lua etc.) that would get loaded when that particular level was loaded.

I would second the hard-coding. However, if you don't want to hard-code, then you have to provide entities that your control XML file can talk to, and game events of various kinds.

For example, perhaps you can place "objects" and "trigger zones" and "target NPCs" in your game editor. Give each of these a name. You can then write XML something like:

<Mission title="Kill the guard, Find the box, Return home" init="kill guard">
<State id="kill guard">
<Trigger src="Guard.Died" target="find box"/>
</State>
<State id="find box">
<Trigger src="Box.Pickup" target="return home"/>
</State>
<State id="return home">
<Trigger src="HomeZone.PlayerEntered" call="Game.Win"/>
</State>
</Mission>

For a Trigger XML entity, the "src" would specify a name of an object, and then the name of an event that should be fired for the trigger to be true. When Trigger has a "target," the action of the trigger is to move the game to the state of that id.
When a trigger has a "call" it means that the trigger will find the given named object, and call the given method on it.
In this case, you know that NPCs have an event called Died, and you know that there's a guard placed in the level, given the name "Guard." You also know that pick-uppable objects have an event called Pickup, and there's a pick-uppable object in the level called "Box." Finally, you know that trigger zones have an event called PlayerEntered, and there's a trigger zone in the home area called "HomeZone." In this case, the object "Game" might always be available, and the Game object has a well-known method called Win.

You can wire all this up at runtime using System.Xml.XmlDocument to parse it, and System.Reflection to find Events and Methods. I would actually write some sample code, but I'm running out of patience :-) Suffice to say that you ought to have a Dictionary<string, object> for all your named game/level objects, and a dictionary<string, State> for your states, and a State variable for the current state. When you switch to a new state, each of the Triggers in that state should be activated, and all of the old state triggers should be de-activated.

With anonymous delegates, you don't even need Reflection.Emit to wire this all up at runtime based on XML and reflection, so it will work fine on the Xbox, too! Just don't call Reflection every frame, or you'll be sad because it's not that fast and it does generate a bit of garbage.

The system I use is based on using c# as a scripting language.

I have a directory full of small C# source code files.

On the PC, these are compiled on the fly.

On the XBOX, I included them in the build.

I have a master file which contains a list of all the scripts, and the location where the mission starts.

If the player is at a location that has scripts associated with it, the relevant script files are compiled into objects (or created) and added to a list.

When an event occurs that may or may not trigger a mission, the compiled classes are parsed.

jwatte:

I would second the hard-coding. However, if you don't want to hard-code, then you have to provide entities that your control XML file can talk to, and game events of various kinds.

For example, perhaps you can place "objects" and "trigger zones" and "target NPCs" in your game editor. Give each of these a name. You can then write XML something like:

<Mission title="Kill the guard, Find the box, Return home" init="kill guard">
<State id="kill guard">
<Trigger src="Guard.Died" target="find box"/>
</State>
<State id="find box">
<Trigger src="Box.Pickup" target="return home"/>
</State>
<State id="return home">
<Trigger src="HomeZone.PlayerEntered" call="Game.Win"/>
</State>
</Mission>

For a Trigger XML entity, the "src" would specify a name of an object, and then the name of an event that should be fired for the trigger to be true. When Trigger has a "target," the action of the trigger is to move the game to the state of that id.
When a trigger has a "call" it means that the trigger will find the given named object, and call the given method on it.
In this case, you know that NPCs have an event called Died, and you know that there's a guard placed in the level, given the name "Guard." You also know that pick-uppable objects have an event called Pickup, and there's a pick-uppable object in the level called "Box." Finally, you know that trigger zones have an event called PlayerEntered, and there's a trigger zone in the home area called "HomeZone." In this case, the object "Game" might always be available, and the Game object has a well-known method called Win.

You can wire all this up at runtime using System.Xml.XmlDocument to parse it, and System.Reflection to find Events and Methods. I would actually write some sample code, but I'm running out of patience :-) Suffice to say that you ought to have a Dictionary<string, object> for all your named game/level objects, and a dictionary<string, State> for your states, and a State variable for the current state. When you switch to a new state, each of the Triggers in that state should be activated, and all of the old state triggers should be de-activated.

With anonymous delegates, you don't even need Reflection.Emit to wire this all up at runtime based on XML and reflection, so it will work fine on the Xbox, too! Just don't call Reflection every frame, or you'll be sad because it's not that fast and it does generate a bit of garbage.

jwatte, if you could write some source code up for this I'd much appreciated.

DanBrink:

jwatte, if you could write some source code up for this I'd much appreciated.

You must have missed what he said:

jwatte:

I would actually write some sample code, but I'm running out of patience :-)

I saw it, I was hoping increased interest on the subject might motivate him.

Was worth a try :)

Thanks for all the input i have taken it all on and am designing a system which i think will fit my needs.