Gamasutra - Proposal Guidelines


				\|\|\|\|

Writers Guidelines

How To Submit Article Proposals

In order to help you write a proposal that will best help the editors make a decision, we have documented the process that works best for us, using an actual article published on Gamasutra, authored by Dr. Paul Tapper.

The initial inquiry should contain a brief introduction about you and the company you are working for, the rough concept of the article, and an outline that gives us an idea of what the article will look like (see Initial E-mail from author box below).
If we like the idea enough, we will ask for expanded detail. Below the sample outline is Paul's expanded detail about the article proposal.
Based on that followup, we asked Paul to write the full article, Personality Parameters: Flexibly and Extensibly Providing a Variety of AI Opponents' Behaviors. By following the development of this article, you will be well-prepared to get our attention.

Initial E-mail from author

Dear Editors,

My name is Dr. Paul Tapper, and I have been a professional games programmer over 5 years. Published games: "Hogs of War" (PS1, PC), "Men in Black: Crashdown" (PS1) a first-person shooter for which I did the AI and the scripting language, "Monopoly Party" (PS2, GC, XB, PC) for which I was lead programmer. I am currently writing the AI for "Worms 3D," a real-time, turn based strategy game for Team17.

In response to your request for game AI article proposals, I would like to propose the following article:

"Personality Parameters: How to Flexibly and Extensibly Provide a Genuine Variety of AI Opponents' Behaviors"

A common problem for game AI programmers is how to distinguish the behavior of different AI opponents. As an example, how to make an orc and a dragon genuinely different as opponents. We can increase the health, amour, and damage of the dragon, but unless we give it a different personality in some way, and make it behave differently, it might as well just be a very strong orc.

Outline:

Introduction

Writing data-driven code

Advantages are more flexible code
Disadvantages are slower execution

Using Parameters

Why this is worth the effort
Disadvantage is more work up front
Making decisions based on parameters

Behavior Parameters

Using behaviors to make characters less predictable
Combining fixed values with randomness
Determining actions based on previous events

Debugging techniques

How to debug these unpredictable, AI-driven events
Modularizing code to separate character desires from game rules
Logging events helps

Conclusion

Please let me know if you would be interested in having me write this article.

Detailed Followup

Personality Parameters: How to Flexibly and Extensibly Provide a Genuine Variety of AI Opponents' Behaviors

A common problem for game AI programmers is how to distinguish the behavior of different AI characters. As an example, how do we make an orc and a dragon genuinely different as opponents? We can increase the health, amour, and damage of the dragon, but unless we give it a different personality in some way, and make it behave differently, it might as well just be a very strong orc.

Data driving: Same code, different data. Data file advantages (reduces code changes, quick tweaking, non-programmer tweaking)

Example 1: Health, amour, weapon damage, weapon range.
(implications of combinations of the values to provide un-expected variety, e.g.- high-amour, low health)

Data format: Backward compatibility (default values). Version control. Edit rights. Inheritance. XML?

But, a dragon and an orc should behave differently. Encountering them should be very different experiences and should require very different kinds of response from the player.

Example 2: Movement parameters. Speed (for each direction), turn speed. Examples (high forward speed, low turn speed -> player will want to use strafe circling attacks) or (high turn speed, low forward speed, limited weapon range, high weapon damage -> player will want to use ranged weapons and keep pulling back).

Extensible personalities: Don't just give a slot for one weapon. Why not give access to list which can be extended to add new weapons. Store the assets names in the data as well (weapon model, animations to draw, fire, etc, particle effects when weapon used, sound effects, etc). This will mean that an orc commander, who is a normal orc, but with better amour and a bow as well as just a sword, can be added without programmer intervention.

This leads naturally onto the idea of Decision Parameters. How does the orc commander know which weapon to use at any particular point in combat? Complex fuzzy switches. References to script functions.

Behavior Sets: Different behaviors: side-step, fall-back, run-away, fire from cover, attack with specified weapon, ring alarm bell, etc. Different behaviors will be applicable to different types of AI characters, so implement them as an arbitrary list (as with weapons). Make them as flexible as possible (giving each one its own set of parameters). Probably the most important question related to different behaviors is how the AI character will decide which behavior to follow at any one time. Each character will want to reassess its current behavior regularly, although certainly not every frame, maybe more like twice a second, and will certainly want to do a behavioral assessment when the current behavior has terminated (if its a behavior which terminates). At each behavior assessment, each possible behavior for the character should be scored, and then the highest scoring behavior should be switched on, with the current behavior being switched off if it is not the chosen one. Top-tip: have a log file to output the reasoning behind every decision the AI makes. It's not enough to know what the AI character did. You'll often want to know why he did it.

Example 3: An example behavior assessment.

Intensive Processing Deferment. Lazy Evaluation. It may be that to properly assess the score for a behavior fully would be rather processor intensive if we had to do so for each behavior (example, a fallback to cover behavior, to be fully scored, would probably want some kind of terrain analysis routine run which could well be expensive). To avoid having to do a lot of processing every assessment, processor intensive scoring functions should be assumed to have their maximum score, and then if the intensive behavior is the one with the highest score when hoping for the best, it can be re-scored using the more processor intensive calculations. If it's still the best, it can be carried out, if it's no longer the best, it should be put back into the list, and the next best should be checked to see if it needs to be down-scored. Of course, once a behavior is chosen as the highest scoring, it may turn out to be an impossible plan to carry out (example, our fall-back to cover plan may have evaluated to be the highest scoring, but the first thing it'll have to do is a path-find to the chosen cover. If the path-find fails we'll want to return to our list of other behaviors and try the next best one)

Squad Behavior: The presented system of behavior assessments naturally lends itself to an "artificial life" style (emergent, bottom-up) approach to multi-character behavior (squad behavior) by allowing the behavior assessment to take into account information about other nearby characters (e.g., orc might have a "ring alarm bell" behavior which scores highly, especially if the bell is nearby, but gets scored down a lot if there is another orc nearer the bell who is currently running a "ring alarm bell" behavior). If a more top-down approach is desired, it would be possible to extend the system by having a nominated "leader" amongst nearby orcs (who need not be any different from his "followers") who sends out commands, either purely in code, or accompanied by appropriate animations and grunts.

Example 4: An example of A-Life style squad behavior. A blow-by-blow account of our band of orcs encountering the player, and how they behave as a unit (without the need for any of them to be the leader).

Example Source Code:
I could provide some simple code to illustrate the ideas in the article, which could be written in the form of a simple text based example which would give a running commentary on the chosen behaviors of a set of characters.