Finally an Update on the Quest System

So, after taking a break from the engine work (due to classes, personal life, etc), I've finally made some substantial progress on the Quest System. The basics of the quest system is as follows:

• Objective - Represents some objective object for a quest. An objective, in short, is more like a single action quest. However, using extensions, a Quest can hold objectives that are really more quests, which allows for powerful and strong chaining. Each objective has its actual objective control, the reward for completing the objective, whether it is completed or not, and whether it is "required or not" (used for larger quests).

• Quest - This is a sub-class of an objective. This represents the actual container used for a quest. This stores a series of Objectives, keeping track of their state. Whether the quest is completed or not is determined by whether or not all of the internal objectives are completed, as well as any overhead the Quest itself requires.

• Reward - This represents the reward object for the quest. This can be customized into storing anything, which is useful for any type of game.

• ObjectiveControl - This represents what is used to actually check if an objective is complete or not. This is a control which is dependent on the actual state of the system in the game. Each Objective has an ObjectiveControl, which itself monitors the state of the game system, characters, etc to distinguish if the Objective has been completed or not.

Right now, I'm working on building a simple system that generates quests using these, based on the parameters of a simulation. The simulation will be a simple 2D world, in which stick figures will move over the land, altering it in some way. Based on the state of the simulation (allocation of resources, number of people / mobs, etc), quests will be generated. A list will contain the quests available and from it, a user can take a quest at a time and "complete" the quest, allowing them to see how the simulation progresses. Once the core system has been built and verified, I will move on to seeing what it can be used for in more classical games.

Finally Have DirectX 9 Working

So, after struggling with Visual Studio 2008 on a bug that is generated when doing a batch build of the engine and its subsidiary libraries, I have finally gotten a basic library built for encapsulating DirectX 9.0 in the engine. I am looking into fixing the build error (I may need to disable incremental builds and instead make it an all or nothing thing... That could be the source of the error, as it seems to malfunction with the libraries whenever it is recompiled after a previous failure).

I am now working on a proof of concept application, a simple game, that uses the current state of the library. It will do basic content loading and management. The entities in game will utilize state and action objects during play. The basic game will be a 2D vertical rail shooter. The following actors will be made:

"PlayerShip" - Using the generic actor, this will have the following states and actions.

• PlayerControllerState - This state acts as the controller for the player. This will be in charge of determining the actions the player's ship performs, based on input information, provided as an action from the system.
• HealthState - This state is the amount of health the player's ship has.
• WeaponState - This state is the currently equipped weapon of the player.
• FireAction - This is the action which the PlayerShip performs on its parent. This action calls the ship to fire, telling the game world to generate the current weapon effect on screen.
• CollisionAction - This is the action the PlayerShip performs on anything it collides with. It damages the target by a certain amount.

This is the basic idea. Enemy ships will have similar controllers, controlled through simple AI and the like. Likewise, they will have their own actions and effects.

I will update once the prototype game is out.