Quests and goodies!

Well after a large brain storm I finally implemented the Quest System. It was a bigger under taking than I had initial thought. A lot of factors played into the design. For instance, how do you determine what an NPC should say, how should you organize your outstanding quests and such. Well these things were all answered after a long meeting with Ken. We bounced back ideas on how this beast should be implemented.

Another problem arose through not having a solid GUI system up. So we had to make due with what we had. The structure is as follows:

The player has a MissionHolder and a MissionDispatcher. The MissionHolder is essential a hashtable of Missions and strings as the key, that listens for MissionEvents such as add/completed, etc. A Mission is simply a struct with a name and a status, eg. COMPLETED, FAILED, INPROGRESS, etc.

The real meat and potatoes is in the MissionDispatcher. It listens for a dispatched Mission (which most likely comes from a Dialog from an NPC). The dispatched message (an Event) has the name of the Mission in question. The MissionDispatcher has a reference of already Dispatched Missions, if this mission has not been dispatched, it creates it based off of the Event information. The Event information contains a .MSN filename which is a Mission File that contains all relavent mission data. Now that we have this created Mission, we fire an Event to the MissionHolder, and presto we have an assigned mission.

Well actually there is still a lot more work to be done. This simply assigns a mission, but what the hell is a mission without an objective, and rules to completing that objective? This is were scripting comes in very handy. Thanks to LUA this is done quite easily. In total we have a possible 8 files for a single mission. This sounds like a lot, but with all the possibilities we need responses for all of them. Here is the breakdown of each file and its use:

1. mission_check.lua - this file contains a function which takes in an array of mission names, and assigns the correct dialog response. The array of mission names are the queue of missions this particular NPC can give. Based on the status of the current assigned mission, this function will present the correct dialog or action. Ex. If mission A is in progress, the next time the player talks with this NPC he will ask how the mission is going.
2. [mission_name]_setup.lua - this file has the array of possible missions to assign. And feeds it to the mission_check.lua.
3. [mission_name].dialog - this file is the initial dialog for a mission. If you choose to accept it, it, an event will fire to the MissionDispatcher.
4. [mission_name].msn - this file states the mission summary and where to find the mission rules. The mission rules are what needs to happen inorder for this particular mission to be complete.
5. [mission_name]_inprogress.dialog - This dialog is for when the mission is in progress. What should the NPC when you have not completed the mission, but talk to him again, maybe give you a clue or something to get you on your way.
6. [mission_name]_reward.lua - When the mission is complete, and you come to collect your reward, this script handles it.
7. [mission_name]_reward.dialog - The NPC needs to tell you what he is giving you. So we have a dialog for it.
8. Can be the rule set, this maybe multiple files.

There you go, a flexible and functional Quest system. This was my first attempt at creating a Quest system, so there may be holes and pitfalls along the way, but I am happy with the way it turned out. In a matter of minutes I created 2 quests - an assasination, and a breaking a pot.

Updates and more updates...

It has been awhile since I have updated this blogger. Many changes have happend.

Team:

There is no I in team, the University of Wisconsin-Parkside finally has a game developers club, and yours truely is a member. With our first project at hand, we are getting our feet wet with the Myriad Engine I built this past semester. I am very thankfull to be working with these individuals, very talented indeed.

Engine Updates:

I have been tinkering around with "controllers" with entities. I took the approach of having an
EventManager take in events from various objects, to shoot them out to listeners who want to hear from those objects.

Benefits:

A very decoupled design, I can swap out different controllers for entities, making for AI design much simpler. I am very pleased with the robustnest (this a word?) of this system.

Pitfalls:

The only pitfall I see so far is these passing of events can get very costly. For instance say we have 500 active entities, each of these entities is going to shoot an event off stating its current action, the EventManager has to pass the events to the correct entity, which in turn can be costly on the CPU.


Items on the agenda:

- Create Virtual File System ( almost complete thanks in part of PhysFS )- 80% complete
- Quest System (retrieve this sword, bring to character type deals ) -0% complete
- AI system (my good friend Ken Smith will be attacking this ) -0% complete
- Independent View Direction -0% complete
- Weapons - 60% complete

Things are moving along, the level editor is nearing completion and the engine is almost complete.

'Til next time.