The Truth About Most Software Projects

Here is a Digital Survivors article, about what would happen if architects had to work like web designers. The more important truth held in this article, is that it isn't just for web designers. The truth is, this is the software industry in general, as well as most innovation industries.

In particular, this reminds me of a recent project I worked on, for my senior project (can be seen on my work blog).

Enjoy!

http://www.digitalsurvivors.com/archives/000455.php

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.

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.

Neverwinter Nights Mod: The Scrolls of Taz'Azarak

So, I am officially announcing the name of the mod I am working on today. I have decided that I am going to create a mod based off a much more well defined adventure I created and played with two of my friends from high school that they thoroughly enjoyed.

The premise of the story is that the adventurer's must get back the legendary Scrolls of Taz'Azarak. These scrolls each possess an amazing amount of power, as each of them holds some of the lost wizard's abilities. The whole time, they are racing against some unknown foe who is also seeking out the scrolls, trying to gain them for himself. No one is sure what power the scrolls possess, but what history details is that the old arch-magician had gained power over shadow, being able to bend it and use it to his will. However, the power was costly, ultimately taking the wizard's life. In his last days, he wrote a warning to all, telling them that the power of the scrolls should never be used again.

And with that, I bid you farewell.

Engine Updates, DirectX 9, and Mods

So, after doing a lot of research for several days, I have had to redesign several key aspects of the bindings I use for the ILEngine for DirectX 9. Much of this comes from memory and content management, done through DirectX 9, due to the inherit connection between content information (textures, etc) and device context, which is horribly efficient for speed and drawing, but a pain for keeping references tidy when allowing switches between fullscreen, windowed, and resizing. Hence, some work on the engine has come to a crawl until I find a creative way around this. So, until then, I may just stick to creating the application framework for DirectX 9, allow for full modification of the window, and then worry about the rest later.

So, as for the mod, I have been swaying back and forther whether to continue using Neverwinter Nights 2 and its toolset, or to use Neverwinter Nights and its toolset. This is mainly because, for Neverwinter Nights 2, there is not a lot of community content and tools available while for Neverwinter Nights, there is a huge amount of custom content and tools available for creating your own mods. Still trying to weigh this decision more thoroughly on the scripting applications as well.

Game Design Patterns / Rules

Well, as with my last post, this post focuses on patterns and rules for game design. Note, that all of this in many ways is common knowledge to any decent writer or programmer, but I wanted to write something about some internet browsing I did the other day.

So here is the first of the links:

Game Interaction Design Patterns Library

This link will take you to a small and quaint page describing the basics of what the page is for. It will describe what a pattern is, etc. It then has several links. This, in my opinion, is the meat of the this small site. Each of the links (the ones which are not outdated or broken mind you) will take you to a site that discusses patterns, namely "interaction patterns". Now, for the standard software engineer or designer, this may not have any bearing to you. So, here is what an interaction pattern is (referenced from Wikipedia:

"Interaction design patterns are a way to capture optimal solutions to common usability or accessibility problems in a specific context. They document interaction models that make it easier for users to understand an interface and accomplish their tasks."

So, what these patterns often provide are common UI solutions and HCI (Human Computer Interaction) solutions for dealing with and interacting with user input and feedback. There are many more links and better resources out there for you, just read the Wiki article or visit some of the referenced sites from the first site posted. With these, common UI tasks and design you may have been thinking of but didn't know if it would work well (both aesthetically and in usability terms) can be solved for you, leaving you just with the means of implementing that solution.

So, the second site I found and got a kick out of, which is also referenced from the first site, is this one:

Current Rules Master List

This site goes over a list of 400 rules (really only 112 currently) for game design. Now, you may wonder where this comes from, and it is in fact explained very well on the site. The idea was that if 400 unique rules could be created that described everything needed for game design, then game design could be "closed" under those rules. What closed means is it could be fully described, discussed, and elaborated on, as with what closed means in discrete mathematics.

While many of these are common sense based or the basis of basic creative writing and player interactions, they are a good reference for any game designer, as they do actually cover many interesting and varying rules that can be applied to various aspects of game design.