As a beginning programmer, looking at finished example code can seem daunting. How, with any amount of experience, does someone know what key to type next? What is the thought process in someone's head while they're typing out new functions, classes, and algorithms?

Unless a programmer is retyping something that has been committed to memory, the characters aren't typed in their final order. Finished code for anything other than the most trivial of examples typically involves dozens, sometimes hundreds of iterations, each of which amount to drafting, editing, and polishing.

A Steven King novel is an impressive thing to read. A Spielberg film is an impressive thing to watch. Every piece seems well planned, and every scene throws something new our way. The pure density of ideas presented can seem overwhelming to an aspiring creative. But that quality of content doesn't just come together that way the first time, beginning to end. The final product came together only after countless drafts, aggressive editing, and years of attention paid to polishing ever last detail.

Why would computer programming be different?

The first time that I compile any videogame project, the first version is a black screen. The second version that I compile is a black screen that makes a sound, or displays a rectangle. The third version will perhaps make the sound when spacebar is pressed, or move the rectangle to the last place the mouse clicks. Until those things work right, the videogame project isn't going to work anyway.

But that isn't just how the process starts - that's also how features get implemented. Whether planning went into which features are worth making (a good habit if you have enough experience to estimate how long different features will take, or how valuable they'll be in the big picture), or whether it's just time for hacking features together to explore and entertain creative whims (a good way to learn), the actual process is still incremental. A version is built with an unanimated character drawn on screen, the next version moves that character according to which control keys are pressed, the next version applies gravity to the character, followed by a jump ability, then collision with enemies, followed by hook up to animations, and so on. Between each step, there's compilation and brief playtesting to make certain that the last executed layer does what it's expected to do.

Because of the iterative nature of this process, early on in development consideration should go into how to streamline the testing cycles. While the tendency of many beginners is to first make the logos, splash screen, and menus - again demonstrating the erroneous thinking that something ought to be made in the order it will be experienced in - I suggest working in the opposite order. Leave the interfaces and splash screens for last, when they'll slow down testing the least possible cycles, letting the game compile/run directly into play mode as early as possible and keeping it that way for the bulk of the development time.

Another part of the process in how programmers program is hitting frequent errors and obstacles. Whether we're setting up the development environment, writing core functionality, or extending existing functionality to tend to details, the process of programming is often a two-way dialogue with the machine.

We spend years in schools learning to associate red marks or answers marked wrong (especially to be redone!) as a sign that we have done something wrong. This thinking has no place in programming, particularly when the notification of what's "wrong" just comes from the machine.

The compiler can be thought of as a teacher with infinite patience. The compiler is always happy to proof-read code, and after passing that grammar/spelling inspection, it will show exactly what the work so far does.

It's a bad idea to wait until most of an work is done before making sure that it's being done right. If starting in the wrong direction, it'd be wise to find that out asap before the mistake grows throughout the program. When it comes to asking real human beings to look over what we've done - whether we're talking about parents, peers, teachers, or online forums - we have a carefully conditioned feeling that we should pester them only if we have to, because we have to respect their time and not interfere with their obligations.

The compiler doesn't have any plans for later.

The last part we'll cover here on how programmers program is to take advantage of the concept of scaffolding. Scaffolding in everyday use, for anyone less familiar with the term, refers to the temporary layers of ladders and wood-planks stacked in metal frames around the outside of a building while it's under construction, giving workers easy reach to everything. Once the building is completed, the scaffolding is torn down and removed, leaving behind a structure which could not have been built as efficiently or with as much attention to detail had scaffolding not been used.

What I call scaffolding, in the world of programming, is what most developers call "debug output". The idea is to temporarily include extra lines of code to help make visible the otherwise invisible calculations and flow of the program. Print statements (printf in C/C++), trace statements (ActionScript 3), log statements, and the like outputting information to the console like, "starting function GameDraw", "loading background image Swirl03", or "left mouse click detected" are examples of this.

A good debugger and debugging environment, when available, provide this same functionality through breakpoints, although depending on the language, environment, and platform, a good debugger may not always be available. Breakpoints pause the program at a given instruction, enabling the program to advance one step at a time, observing numbers and changes in memory. This method, when available, is particularly well-suited to making sense of obscure technical bugs.

Breakpoints, like debug print statements or visualization of internal states, are removed or disabled from the game or source code before shared. Debug elements are not needed by the time a game or source code can be shared, because like the scaffolding around the new building, they have already been put to use in ensuring that the project itself came together.

Visualizing this information in-game can also be helpful sometimes when rooting out questions about real-time functionality that takes place across multiple frames which could be difficult to read from lines of text, such as drawing the player as a different color rectangle based on whether the collision code currently thinks that the player is on the ground.

The greatest example of the scaffolding concept is the development of software that simplifies the development of software - level design tools, weapon/unit stat editing tools, animation tools - programs that enable design problems to be solved using design tools instead of through programming. Though they're (usually) not shipped with the final game, this additional programming work makes it possible for the game to be finished sooner and better. In smaller games - including most of my old 2D tile-based projects - sometimes the easiest way to build the level editor is to introduce it as a level editing mode in the game itself, hiding that functionality for the final release. That way the same assets (graphics/sounds), rendering code, and level formats are the same for both playing and editing as the code base develops.

When looking at example source, or playing a finished game, rather than thinking about how the entire program could have come together at once (a daunting task no matter how much experience someone has!), be thinking instead about how scaffolding of debug statements could verify aspects of the program while working on it, or about what the first few crude features would be developed and tested after the empty screen compiles. Test, then repeat.

Think about music composition - the refrain or underlying tune is likely to be worked on before the beginning or end. Or a story might be built around one or more intense climactic scenes, which will need to be packaged between build up and resolution before being ready for others.

When an idea jumps into mind for a videogame, starting to write what the final videogame code might be like from start to finish - complete with rigorous class definitions for everything and all the trappings of a finished game's functionality - just doesn't make sense. Get the bare core working with as little code as possible at first, then layer and iterate.

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim."

-Edsger Dijkstra

There are a lot of films, novels, and comics about artificial intelligence. These present AI as a problem solving, self-preserving intelligence eager to assert its dominion over people.

There are a lot of non-fiction books, internet references, and university classes on artificial intelligence. These present AI as a pattern-matching, data-mining adaptive algorithm used to process mountains of messy, complex information.

AI in real-time videogames is not about trying to program intelligence. It isn't about making the best decisions, thinking through complex problems, or adaptive learning.

AI in real-time videogames is about creating the impression of intelligence. Generally speaking, the appearance of intelligence is all that we're going for - it's functionally pretty similar in such narrow domains, and infinitely more within reach than creating "real" intelligence.

What are the qualities that we can appeal to, in order to create the impression of intelligence during gameplay?

If the "smartest" opening is move A, that move had better not be the opening every time, or the player will just be conditioned to react to that opening move every time. So long as one strategy works repeatedly, what the player is up against doesn't come across as intelligent, just mechanical.

The moment that pattern is broken, or that expectation is violated, the player will project intelligence onto the previously robotic computer entity. "Why did it switch to move B?" The real answer to this question doesn't matter - whether the program looks deeply into the player's eyes and reads his or her mind, or simply has a random 20% chance of doing something random - the important thing is that the player is forced to stay alert instead of always leaning on a memorized strategy. (Guess which of those two strategies is the most cost and time effective solution? Mind reading, or inserting a line that reads if((rand()%10)<2)... )

The 1997 game Trespasser, based in the Jurassic Park universe, attempted to create AI that "thought" based on needs around the ecosystem, but the end result was monsters wiggling around looking confused until they charged sideways at the player. By comparison, listen to a young person or non-technical player spending a few minutes in front of Ms. Pac-Man, and before long they'll blame the mostly random ghosts for all sorts of devious schemes.

Keep it simple. Throwing in a good dose of randomness at a high level for the enemies is often just as effective at creating the illusion of intelligence for the player as a more contrived system of reasoning that would take longer to develop.

Heuristics - "fuzzy logic" is another term for this - is a way to simplify complex decisions involving many considerations into a decision about decisions.

The concept here is a powerful one, but simple once introduced. Instead of building a massive tangle of if-else conditional statements and boolean logic to determine an AI character's next move, the goal is to encapsulate what information derived from those variables means.

It's a form of divide and conquer. To use a business metaphor: how does a top-level executive make informed decisions? By asking each of their advisors and expert employees to offer distilled summaries of the issues they each believe are most important. In the same way, rather than trying to deal with countless variables all in the same part of code, we want to distill groups of variables into meaningful measures that we can base the high level decisions upon.

Moods - or "finite state machines" - can encapsulate a sense of memory, reaction, decisiveness, and thus: intelligence. The way this works is that each character keeps a number tracking its state of mind. Is the enemy wandering, alerted, angry, or retreating? Is the enemy grouping together, spreading out, hunting for a health pack, or battling to the death on a kamikaze charge?

Telegraphing the enemy's current state, and/or the transition into that state change, also goes a long way in creating the illusion of intelligence (though this shouldn't be too repetitive). The enemies turning red with anger in Bubble Bobble declares their current mood clearly, Metal Gear Solid bad guys get exclamation points over their heads, and enemies in No One Lives Forever and Thief (both of which were widely praised in their time for their otherwise normal AI, thanks to this single reason) announced things along the lines of "I can't find her!", "I know you're here!", and asking their comrades things like, "Did you hear something?"

Big games - whether a First Person Shooter, Third Person Adventure, or Real-Time Strategy - invite some other AI needs like pathfinding. FPS and TPA games often include hand-placed nodes in the world giving AI clues for where doors are, where the center of hallways/rooms are, and where the best cover points are to kneel behind. RTS games can involve a bit of clustering (basics of facial recognition algorithms) to assess areas of defensive weakness. Basic vector geometry and dot products can be used to ascertain line of sight between characters (including trivially checking a character's facing), and trig (especially atan2) are useful in finding angles to shoot in, look at, run toward, or flee from.

Puzzle games are obviously a whole different can of worms, depending entirely upon the game's structure.

All that said, much of the real-time AI in most games still tracks back to (a.) creating the illusion of impatience and intelligence by being unpredictable (b.) reducing groups of variables into easily prioritized decision points (c.) committing decisively to display a range of possible behaviors and (d.) unsubtle announcements of the current behavior or moments of mood switching.

On the technical side, the AI "mood" (finite state machines) can be tracked simply by keeping two more integers per enemy. The numbers are used by setting one of the integers to an enumerated value corresponding to behavior #1 vs behavior #4 (etc.), and the other tracks how long the current behavior should continue before being reassessed. For example:

enum {

MOOD_WANDER, // same as "#define MOOD_WANDER 0"

MOOD_CHASE, // same as "#define MOOD_CHASE 1"

MOOD_MIMIC,

MOOD_FLEE,

MOOD_NUM // useful for randomizing mood

};

/* the larger the first number (200), the more decisive the enemy seems; the larger the second number (150), the less predictable the enemy seems */

#define NEW_MOOD_TIME (200+(rand()%150))

class Badguy_typ {

// skipping class variables definition here for brevity

int aiMood;

int cyclesTilMoodReconsidered;

Badguy_typ() {

aiMood = MOOD_WANDER; // begin unalerted

cyclesTilMoodReconsidered = NEW_MOOD_TIME;

// other character initialization goes here

}

void Move() {

if(--cyclesTilMoodReconsidered <= 0) {

aiMood = (rand() % MOOD_NUM); // random new mood

cyclesTilMoodReconsidered = NEW_MOOD_TIME;

}

/* cyclesTilMoodReconsidered is only intended as timeout, so that left on their own, unprovoked, enemies will seem unstable, curious, and impatient, like they have minds of their own. */

/* Within the switch statement below, it's fine to switch aiMood and reset cyclesTilMoodReconsidered even if it isn't time for a mood change yet. For example, if the enemy is within a certain range from the player, especially if line of sight is established, switch "aiMood = MOOD_CHASE;" */

switch(aiMood) {

case MOOD_WANDER:

// code for enemy that's wandering aimlessly

break;

case MOOD_CHASE:

// code for enemy aggressively going after the player

break;

case MOOD_MIMIC:

/* code for enemy that's copying the player's movements. This is simple but distracting. It gives a false sense of security suggesting the player is in control, but can turn aggressive unpredictably or upon getting in close. */

break;

case MOOD_FLEE:

// code for enemy getting away from the player

break;

}

}

// skipping other class methods for brevity

}

Ultimately, it's ok if the AI isn't the smartest thing on earth. If the player outsmarts it, they'll feel like a champ. You don't need to prove to players that a computer can process and respond to information faster than they can.

As Ian Davis, the founder of Mad Doc Games told me, "The goal of videogame AI should be to put up a fair, convincing fight, and eventually lose."

At the end of the day, creative people do considerably better work when they're allowed to care.

If the attitude is that we're out to make dog toys for dogs to chew on - but replace the dog in that case with a human being who is treated as similarly incapable of learning - then the team is on track to be a junk factory.

If the attitude is that the audience is capable of learning and finds thrill by being clever, that the players can be trusted to be patient and persistent when challenged, that here's a once-in-a-lifetime opportunity to spend hours pushing an ever-developing mind's undivided attention to think effectively, the team is on track to treat their work with responsibility and attention.

This is where Calvin and Hobbes came from, this is where The Neverending Story came from, it's at the root of work by Roald Dahl (Mathilda, Charlie and the Chocolate Factory) and A. A. Milne (Winnie the Pooh) and classic Disney (when they still cared; that is, when Disney's creative geniuses outnumbered their suits and lawyers).

What if you aren't working on a game for children? Most people in the entertainment industry go their entire career without making a product specifically for children, right?

Unforunately, people outside of development often don't dig very deeply when asked what is liked about a videogame. This effect is not because the players lack intelligence, it is simply because they are not used to thinking in terms of how or why it might have been done differently; their relationship to videogames doesn't require the same sort of precision or rigor. This is partly because, for better or for worse, they're trusting us to understand the whys and hows.

When asked why I prefer one food over another, my answer can be a lot less exact than what a chef needs to consider; when asked what I prefer about one car over another, my answer can be a lot less exact than what an automotive designer or engineer needs to consider.

Ask someone why they like GTA San Andreas, and many players will say "because I get to commit crimes." I propose that an important part of what they enjoy is the Hollywood vehicle handling, the freedom to drive any car, enjoyment in exploring, and the clever satire. On what grounds can I claim that my answer has any better shot at being right than theirs? Those same players very rarely seem interested in the ton of other crime games on the market which are (a.) focused more on the crime (and b.) lacking the driving, exploring, and satire of San Andreas.

Ask someone what they like about they like about Gears of War, and they're likely to say, "Chainsawing aliens!" Yes, it's memorable, with blood splattering all over the camera. But there are plenty of videogames with chainsaws which failed, and bad videogames that chainsawing aliens couldn't fix. I think that the Halo / Bubble Bobble style co-op and the watching-each-other's backs is more likely what helped this game earn its place in the hearts of so many players.

By digging a bit deeper for what wishes are really being fulfilled, rather beginning at the superficial layer of how it's presented, we can start to see seemingly disparate games in the same category, and understanding innovation seems a little less like a shot in the dark. If what the player finds thrilling about violence in many games is the level of empowerment, influence, and control that it affords - a sense of power - elements of that same empowerment may be found by having mayoral control over a city (SimCity), being able to summon nearly anything one can think of into existence (Scribblenauts), or having control over time (Prince of Persia: Sands of Time or Braid).

Guitar Hero, Ace Attorney, and Trauma Center all appeal to the same deeply rooted, "I want to feel great at something difficult" wish fulfillment which has been around in pro sports videogames from the beginning. NBA Jam, NFL Blitz, Wipeout, and Tony Hawk identified that core desire, and exaggerated the fulfillment to a comically extreme degree.

This is about treating adults like adults. It begins with speaking up on the development team when it seems like the design is targeting the lowest common denominator, pretending like people are simply interested in watching easy explosions, vs seeing events they cause as part of a feedback loop that instills a sense of accomplishment for having figured out something new. When it feels like you may be on track to denigrating the human mind by giving the player meaningless chew toys, instead of working hard to produce something fit for consumption by an intelligent, capable human being, "throw it out, there's a better way to entertain him."

These Free Lessons are developed to help the community, and I like writing them, although they are very time consuming. If you find these lessons valuable, and can afford to make a small donation to show your support, it would be greatly appreciated. This helps me continue setting aside the time needed to keep quality a priority in the free lessons. PayPal makes the transaction safe and simple - you don't even need to have a PayPal account if you have access to a credit card!

I have received 1 donation*. I write 10-20 pages each month on a variety of topics to help people, have hundreds of subscribers and thousands of readers. These writings generally receive positive responses from people that are dedicated to reading and acting on them. If you'll take a few minutes to share even a few dollars with me to show appreciation, I'll certainly notice.

If you're not able to make a donation, no worries! A simple referral letting your peers know about these resources via forum, blog, or social network can also go a long way in helping me help more people.

[*Update! I have now reached a total of 5 donations!]

Chris DeLeon