Showing posts with label Procedural Content. Show all posts
Showing posts with label Procedural Content. Show all posts

Monday, December 21, 2009

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.

Sunday, October 4, 2009

Dynamic Quest Generation

So, while I'm thinking about it, I'd like to talk about something called "Dynamic Quest Generation". Many people have heard of it. Many others have asked for it. I'm here to discuss why it is feesible, and why it is not.

So, as far as making a system to do this, I can say with 100% certainty that it not only is possible, but it could be programmed by an undergrad student at university. In fact, a group of students in the CS Department here did do just that. I did that at one point as well. The core of the system was these classes:

  1. Quest class - Represents a quest, its goals, its preconditions, postconditions, rewards, etc. Can also encompass multiple quests (quest chain, etc).
  2. Goal - Represents an abstract goal type for a character to achieve. Can encompass complex goals, such as doing multiple parts of a quest, etc.
  3. Precondition - Any precondition required for beginning the quest (level, certain item, etc).
  4. Postcondition - Any artifacts that occur in the world as a result of the quest (level, area change, changes in people, etc).
  5. Rewards - I made this separate of postconditions, in that rewards are what only interact with the completing characters. This includes things like experience gain, item gain, alignment shifts, etc.

Now, using these, it is possible to create a completely random and logical quest system. But does anyone see the main problem with this? If you look hard, we have everything to dynamically create quests, except for one thing: Dialogue, Narrative, etc.

So, you may think that is the easy part. But in truth, for a system like this, that is the hardest part to accomplish. For example, it is very easy to create something like this:

"Go kill ten flying monkeys. Then fetch my ruby slippers. Then come back to me. I'll give you ten gold and a shovel. Then help me bury Toto. I'll join you."

However, it is much, much more complicated to create something like this:

"Oh, I really need your help! The flying monkeys of the horrid wicked witch have gone too far. They killed my dog, Toto! Even worse, they ran off with my ruby slippers, and I am stranded here without them. Could you please go and kill all ten of those horrid monsters and bring back my slippers? I'll reward you with all the gold I have and the Tin Man's shovel. Please, I'm begging you!"

"Oh, thank you for returning them to me. I am ever so grateful. If you could be so kind, could you do me one last favor? I was going to, but I just don't have the heart to bury Toto."

See the difference?

So, in all of those, I bolded the actions required to complete certain stages of the quest. You need to kill the ten flying monkeys, fetch or bring back the ruby slippers, get the reward, and then bury Toto. The specific objectives I underlined, as with the number and name of the creature to kill, what you needed to fetch, and what you received as a reward. All of that content could be replaced very easily in both instances. However, the problem goes with randomly creating the second piece.

If every NPC had that exact same dialogue for this type of quest, it could get really old, really fast. So, I could expand it to being 2 dialogues, then 3, then maybe X per race, Y per gender, etc. The point is, no matter what numbers I choose, eventually the system will become stale. Hence, we really need to randomly create quest narrative to solve this problem, but also do it in a believable manner.

Hence, the idea of random quest generation is really solving 2 problems:

  1. The first is to solve the problem of building the quest.
  2. The second is to solve the problem of building the narrative.

The harder of the two is most definitely the latter. To solve that, you would need a narrative engine for creating your quests. Even more so, you would need it to be flexible and update-able with new quest types, new dialogue and item entries, etc. Lastly, everything in it would need to make sense, contextually, for the game. And even after all that is done, you would need to update the narrative options, as any system is bound to get stale after a while. Add on top of this multi-language support, etc, and you can see the issues with this.

S, that is my rant of random quest generation. I think the idea has great promise, but at the same time, as players and designers, we need to really note what is the meat of the problem. It is not in assembling a quest, but in making the quest believable.

Monday, July 6, 2009

Looking Into Procedural Content

Well, right now I'm working on a project which will create a randomly generated graph, based on some parameters fed into the system. The graph will then be displayed and be editable by users. Next, after the graph is displayed, the system will export the graph into a format for being read.

Here comes the fun part: take the graph and edges, with weights to specify distances and values to specify sizes, and create terrain or a dungeon from it. From there, make the dungeon exportable to either Maya or 3D Studio Max.

Right now, I'm in the planning stages of developing this software. Currently, the system utilizes a rough system of vertices and edges to create the graph. However, the goal is to surpass that and allow for cycle detection and the like, which can be used for vertex reduction and complexity reduction for the graph.

About Me

Software engineer, game developer, writer, and student. My work revolves around games, algorithms, real-time development, and creative works.