Christmas vacation

Wanted to do three things in my post today:

1. Wish everyone a merry Christmas. Mine has been great so far. Got to spend lots of quality time with my family and my wife's family, all of whom are wonderfully kind, generous people.
2. Let you all know that my wife an I are leaving tomorrow for an extended vacation in Argentina. I'll be returning in mid-January, so I may not be posting for a few weeks. If I have the opportunity, I will post a few accounts of my trip as we go along, so if you're interested, please keep an eye on the blog the next few weeks.
3. Update you on the status of SPUDZOOKA. It's coming along quite well, but I didn't get as far as I would have liked before the holiday/travel madness started. I'll publish a demo level when I return and am able to get a little more polish on it.

Once again, I hope everyone is having a happy holiday season. It's been a good year, and I'll talk to you in a few weeks!

Virtual reality and the Wii

Saw a really cool YouTube video over at Independent Gaming (strangely, the post seems to have been removed from the blog). The video is of a guy describing (and demonstrating) how to set up a VR display using the Nintendo Wii. Really cool stuff. Wouldn't surprise me if this makes its way into a few games in the next year or two.

The perils of self-publishing

There's a nice post from Leo Stableford today about the pros and cons of self-publishing. He's discussing things in context of writing, but I have a feeling many of the same issues apply to self-publishing games.

It would be easy enough to post SPUDZOOKA to a site of my own designing, set up a Google AdSense account and maybe earn a few dollars. If I did a decent job promoting the game, people might come play it.

On the other hand, if I attempt to get my game published on a well-trafficked game site like Shockwave.com, I would definitely get more players and could potentially make more money. The question is whether self-publishing would hurt my chances of being published on a site like Shockwave. Honestly I don't know. The game publishing business is certainly not as well established as print publishing, so my guess is that there are still more avenues available for indie game developers to publish and distribute their games.

I'm just starting to research the possibilities, but maybe I'm getting ahead of my self. I still have a game to finish before I can even publish it myself.

Introducing SPUDZOOKA

It's simple. It's fun. It's vegetarian. It's SPUDZOOKA.

SPUDZOOKA is a potato cannon shooting game (as one reader already guessed). It's designed to be super easy to learn and (I hope) really fun to play.

I'm still in the early stages of development, but things are coming together pretty quickly.

Some features
Like most casual games, SPUDZOOKA is built around a simple game mechanic. In this case it's shooting potatoes at targets. There are a million target shooting games out there, but this one will have a few features that I hope will make it stand out:

• Play in 3D. Most casual target shooters are still Flash-based. SPUDZOOKA's realistic 3D environment should make it more immersive.
• Customize your cannon. As you progress, you'll earn points that can be spent on new parts for your potato shooter. Barrels will affect ammunition and fire speed. Combustion chambers will affect power. Stands will affect accuracy.
• Use various kinds of ammo. Potatoes come in all shapes and sizes, and they're all good for shooting.
• Vent your frustrations on inanimate objects. Part of the fun of SPUDZOOKA is finding targets, which are often hidden behind obstacles such as boxes, crates, shelves, and barrels. You'll have to use your potatoes to knock them out of the way.

I've got some other features in mind, but they will take a bit longer to implement. Casual games are at their best when they're addictive, and that means you can keep coming back without playing through the same content every time. I'll save the details of my plans for another post, but my idea should keep things interesting.

I'll post a test level for everyone to play as soon as it's ready. I'm leaving the country on a long vacation right after Christmas, so I hope to have something ready by then.

The "social gaming" phenomenon

As a follow-on to my last post, I thought I would point everyone to a Gamasutra article published yesterday that predicts the next big thing in gaming (now that music games like Guitar Hero and Rock Band are a "phenomenon").

The analysts polled in the article all seem to agree that the future of video games (the short-term future anyway) is going to revolve around "social gaming," games designed to be played with multiple people present in the room.

A couple of the analysts make a nice (if a bit obvious) comparison between such social video games and the classical board games of a generation (or two) ago. The current crop of games happens to be focused on music, but music isn't the root of the phenomenon, according to these folks. I never much cared for traditional board games, but I do agree with them -- we're just witnessing the next incarnation of group entertainment.

-------------

On an unrelated note, here's a quick hint about the subject of my casual side project...

Rock Band guilt

There's a great post over at Geek Studies today about Rock Band. The gist is that games just can't win:

If a game features violent activity that we could never (and, hopefully, would never) enact in real life, it gets criticized for encouraging real-life violence. If a game features non-violent activity that might even be considered worthwhile in real life, it gets criticized for discouraging real-life action.

In short, Rock Band has been getting some criticism (granted, it's pretty benign) for effectively discouraging people from learning to play real music.

I agree that this is a pretty ridiculous assertion, but I think the more important observation in this post is that games still seem to occupy some sort of limbo wherein we (as productive members of society) are allowed to play, but only if we feel some requisite twinge of guilt during or after all the fun.

I admit to playing Rock Band at a friend's house until 3 AM on consecutive nights. I marvel at the fact that I, the guy who flatly refuses to sing or dance in public, will excitedly take the microphone and sing songs far outside my vocal range while strutting in place (picture Mick Jagger) and dancing with the microphone stand (picture Steven Tyler--yes, my friend bought a microphone stand).

This is fun in its purest form, yet every time my friends and I (including my wife, and her sister, and my brother's wife) gather to play this game, someone will utter, once every half hour or so, "This is some nerdy shit." It's as if we all hear the little voice of society whispering, "You're wasting your time. Video games are for losers."

So what, I say! No one anywhere does anything productive on Friday night. None of us will ever be a rock star. That's not the point. The point is entertainment; the point is fellowship. And that's a lesson I learned from South Park.

An introduction to lightmapping

I've learned a lot in the last few days about lightmapping, the process of "baking" lighting effects into the texture on a 3D object. I've heard it described as a "poor man's lighting effect." For me, that's a true statement. I can't currently afford the pro version of Unity, which includes dynamic, real-time shadows, so the next best option is to map static shadows into my scenes.

Despite being less flashy, lightmapping is considerably less expensive in terms of processing. Ultimately, I think it's a fantastic value. The effect is great, and the cost is minimal.

Lightmapping is a tough concept to get your head around. Wikipedia has a brief article on it, but it's kind of technical. Here's the gist:

• Generally the best way to control lighting is in your 3D modeling application (the image to the right was rendered in my 3D app). You can build a number of objects, texture them, and light them in whatever way you choose. The trouble is that rendering images with sophisticated lighting is much too slow for a real-time game engine.
• When applying textures to 3D objects for games, you have to "unwrap" the object onto a flat surface that then gets painted with a texture (a tedious process called UV mapping). The texture is then wrapped back around the object.
• Most 3D modeling applications now allow objects to have multiple UV sets. In other words, the main texture can use one set of UV coordinates, and another texture can be attached to the second set.
  
• The lightmapping process takes advantage of this second UV set by converting lighting information from the 3D application into a flat texture that can be applied to an object on top of the primary texture. The result is an object that looks like it's being lit, even when no lights are present.
  
• Since lighting is one of the most processor-intensive tasks in real-time 3D processing, lightmapping is tremendously beneficial from a performance standpoint. The downside is that the "baked" lighting isn't dynamic and won't apply to any moving objects in the scene (well, you could do it, but it would look pretty strange).

These before and after images illustrate the point. The first one is a screenshot of a scene with no lighting and no lightmapping. The second image uses lightmapped textures, but still has no in-game lights. As you can see, the cube that should be lit by the light coming through the window (if this were the real world), is not receiving any light at all, since there are actually no lights in the scene.

Probably the best approach for me is to use some combination of lightmapping and in-game lighting. The result won't be perfect, but it will be close enough until I can spring for the pro version of Unity.

The holidaily grind

Ah, the holidays. Nothing is better for turning optimistic productivity into an overwhelming sense of "I accomplished nothing today." My blogging pace has suffered, as you might have noticed, at the arrival this funny thing we call December. It's a time when the routine balance between personal and professional inevitably tilts one way or the other -- and neither direction favors hobbies.

Nevertheless, I'm making some progress on my side project. Currently I'm working to model and texture the main environment for the game. Though this project is far less demanding on the artistic side, the work still has me looking at quite a long list of required assets. But today I found some good advice on art for indie games.

I programmed some of the basic mechanics for this project back in the summer when I first had the idea and was playing around with Unity, so once the main environment is finished, I'll be able to focus on level design and refining the gameplay. From there it's user interface and sound.

Yeah, there's still a lot to do, but this project is so compact compared to my main one that I might just have a chance of finishing. At this point I remain optimistic. More details to come -- as soon as I finish my shopping.

A casual digression

Gamasutra just published an article about the prevalence (and success) of "cloning" in casual games. (Independent Gaming tipped me off to the article.) Now, I've never been a casual games kind of guy; I have always been more interested in big-budget titles that deliver complex stories and gameplay. Nevertheless, my interest in casual games has grown slowly over the last couple years as the market has grown and as I've come closer to admitting that my best chance of completing a game is to make a "casual" one.

Casual games tend to focus on one central gameplay mechanic, rely on fewer art assets, and have much simpler stories (actually, most have no story at all). The advantages for a small team are obvious. I understand that any hope of creating a complete game that people will play depends on whether I undertake reasonable projects.

So, I have decided to turn my attention for a brief period (a couple of months) toward creating a casual game more modest in scope than my epic RPG. The concept for the game is light-hearted and nonviolent. It will be a target shooting game. I'm not ready yet to reveal the idea, but rest assured that you will all be able to play it.

Those of you who know me will know that this shift is not one I take lightly. I've been working on my RPG for years and, despite excruciatingly slow progress, I am still dedicated to it. But the fact is that it's better to develop a small, complete game than a small fragment of a large one. With a finished product under my belt, I'll be much better equipped to make progress toward the larger goal. A finished game also gives me the opportunity to explore my options for marketing, distributing, and potentially selling a game.

More details about the game will be coming soon. The blog will continue. After all, I'm in this for the journey more than the destination.

Beowulf and video games, part 2

The other day I posted some thoughts inspired by the Beowulf movie's decidedly video game-esque animation and action scenes. Today I turn my attention to Beowulf's story. Now, I know what you're thinking: Beowulf's story is only similar to most video game stories because it sucks. By certain standards, it's definitely not that interesting. Just a few major plot points. Not many twists and turns. Pretty clear roles for the major characters.

A brief interpretation of Beowulf
On the other hand, I think the movie can be "read" not so much as an epic action movie but as an allegory or cautionary tale. I have to credit Roger Ebert at least partially for leading me to this interpretation. His somewhat disjointed review suggests an element of irony and satire in the film. I didn't really find either of those, but he did get me looking for a deeper layer of meaning.

Without giving any big spoilers, I think Beowulf is a story about the price of arrogance, greed, and lust. Ok, this isn't a big stretch -- our hero arrives at Hrothgar's hall boasting of his accomplishments, in search of riches, and not at all hesitant to ogle Hrothgar's wife in that ridiculous way macho protagonists always seem to do (as if to say, "You will be mine, oh yes, you will be mine").

The film's major symbolism, though, can be found in its antagonists. Grendel's mother, in her golden nude-glory, represents the seductive promise of wealth and power. Grendel himself represents the isolation and violent sensitivity born from a society built on greed (he made me think of the Columbine and Virginia Tech shooters). Beowulf's final foe is a physical manifestation of Beowulf's mistakes, a brutal (and large) reminder that leaders' mistakes beget very destructive forces.

Allegory and games
Ok, now the point. For all the discussion about stories in games (particularly the argument about whether they can ever be good), I find myself thinking that allegory could be a particularly rich device to use in game stories (no doubt it has been used before). There are a couple reasons why allegory seems to have a lot of potential for games.

• First, allegory is well suited for the kinds of stories and worlds that are often found in games. Science fiction and fantasy worlds in particular often deal in larger-than-life situations ripe for symbolism.
• Second, and more importantly, allegory can function even in an open-ended narrative situation. Symbolism can be established through visuals (like color or costumes) and sounds (musical themes) without requiring a particular order of events. Additionally, as Beowulf demonstrates, allegorical tales often work best when stories are simple, since there isn't as much plot to distract from the underlying meaning.

Should every video game be an allegory? Of course not. But as the debate over game narrative continues, allegory, as a time-honored form, seems like a good option for developers interested in telling stories of some depth without the pressure of coming up with a brand new narrative mechanic for games.

Is my game going to be an allegory? You'll have to wait and see.

Beowulf and video games, part 1

I saw Beowulf today. Though they took more than a few liberties with the story, it's a pretty good movie (to be fair, the "story" in the original epic poem is quite loose, so it probably needed some tinkering). Being a computer-generated, animated film, there are almost no limits to the scope of the visual effects, and there are certainly no limits to the stunts that the characters can perform.

Several things struck me about the movie as it relates to video games. The next few posts will explore the relationship between epic stories like Beowulf (and their movies) and video games.

Game action inspiring movies
First, while watching the climactic battle scene, I couldn't help but remember some of the boss encounters in the God of War games. With a physically idealized hero (thankfully wearing clothes for this fight) flinging himself around and methodically chipping away at a much larger foe, I could almost see a big button on the screen telling me to press X as fast as possible. I had the same sense when I watched 300, which clearly had some game-inspired action.



There have been film-inspired games for years, and many of them have endured criticism for seeming shallow and rushed to market. Of course, there have been game-inspired films and TV shows for at least a decade well (anyone remember the Super Mario Bros. TV show?). Momentum has been picking up in the last five years or so, with film adaptations of video games popping up regularly (the Resident Evil series, Doom, Silent Hill, Hitman).

The prevalence of movies based on games isn't at all surprising. What's remarkable is the extent to which a video game sensibility seems to be working its way into Hollywood action movies. Indeed, where else would you find inspiration for visualizing an ancient epic poem than our present-day escapist equivalent?

Maybe what I'm noticing is just an attempt by the movie studios to appeal to a younger audience. Maybe the people making movies now happen to be life-long gamers. Or maybe there's a growing expectation that movies provide the same kind of over-the-top, super-intense action sequences as games, where the player is in control. With no control to offer the viewer, do filmmakers feel pressure to choreograph game-like action sequences to avoid losing their audience?

Of course, it's also possible that the complexity of action sequences in films and games only reflects rapid improvements in computer graphics technology. These could be the images we've always wanted to create, but until now we couldn't realize them so well.

What do you think? Are films beginning to draw on some kind of video game aesthetic, or are games and films both just taking advantage of technological change to deliver more intense sensory experiences?

Screenshots and tryptophan dreams

Don't have much to say today. It seems that my mind has checked out in advance of the Thanksgiving binge.

As a special holiday treat, I thought I would post some screenshots of my progress. You'll see lots of unfinished things in here (like untextured buildings), but I continue to be impressed by how easy it is to create a nice atmosphere using Unity's new terrain tools.

The big city

First of all, I apologize for the brief lapse in new posts. Work was hectic last week and involved a trip to New York. It was my first time in New York, and I wasn't quite prepared for the scale of things or the sense of awe that a city so big commands. Upon leaving, I was struck by the urge to play SimCity, probably because the trip ended with a flight over the city on a clear night.

Where does the urge to build a city come from? Not sure, but I think it has something to do with the way cities seem to behave like organisms -- constant while constantly changing. It's not a new metaphor, but it is a brilliant dynamic to try to capture in a game.

Reflections like this leave me wondering about the relationship between story-based and open-ended games. SimCity doesn't have a pre-ordained story. Indeed, Will Wright (the creator of SimCity) and others would tell you that the narrative value of open-ended games like SimCity is in the communication of events after the fact, rather than in gameplay itself. Even more, he would likely say that the best games are ones that possess the most narrative potential without dealing with a specific narrative (in other words, games that encourage storytelling among players).

The Grand Theft Auto series, though, is a nice example of games that accommodate sandbox play along with a directed (though branching) storyline. Some might call the story optional, but really it's not. The size of your sandbox in GTA depends directly on completing at least some of the story.

Since I'm working on a story-based game, I feel compelled to address somehow the possibility of open-ended play in my game world. How I'll do that remains to be seen. A lot of games resort to side quests, the search for hidden items and hidden bosses, etc. These are good options, but they are once-and-done activities. At a certain point, you can accomplish everything. Maybe that's desirable, though. Stories always have a beginning and an end, so to some extent they can't coexist with purely open-ended gameplay. Maybe the best answer is something like GTA or Will Wright's upcoming game Spore, which I've heard him describe as goal-oriented gameplay designed to prepare you for the ultimate sandbox experience.

I can envision adaptive story-based games where the player's decisions truly affect the world and the characters, but they are still some years away (D&D-based games like Knights of the Old Republic don't quite cut it, in my opinion). In the meantime, I'll continue mulling the issue while I build a virtual city to rival Manhattan.

My game design story (so far)

Here's another quality article about game design from Gamasutra (by Gillard Lopes and Rafael Kuhnen). It presents a layered model of game design (starting with concept at the top and gameplay "verbs" at the bottom) and then weighs the pros and cons of bottom-up vs. top-down design. The point, essentially, is that both are required.

Some of you may be recoiling at the thought that I'm gearing up for another overly academic discussion of game structure. Luckily, I'm not that cruel. Instead, I offer something more personal.

My own experience with game design has so far fit quite well into Gillard and Kuhnen's description of a top-down process. I've been mulling the concept of my game for several years (the seeds of it probably sprouted six or seven years ago, but real development started almost five years ago when my brother came up with an idea for a character (yes, development has been, shall we say, sporadic).

With a general context in place for the characters, setting, and story line, we began chipping away at the core questions of gameplay: how would combat work, how would the player interact with NPCs, how would the character leveling process work. The answers to many of these questions have changed several times.

Once the major content-related decisions were made, I started building the mechanics, particularly the battle mechanics. This means, in effect, that I had to figure out how to program all the features we wanted in the game.

The line between design and execution is a blurry one for a small team, but we're now at a point where some minimum amount of playable content is required to test our decisions. If they don't result in a fun experience, we will have iterate at the appropriate design level to improve things. That could mean anything from revamping the battle system to rethinking the entire concept.

So, stay tuned for a chance to provide your feedback. It will be a while yet, but game design for a small fry like me is as much about the journey as the destination.

Game narrative: an overview

A lot of people out there consider Final Fantasy VI (released in the U.S. as Final Fantasy III) to be the best Final Fantasy ever and one of the best console RPGs. While I haven't played the game for at least a decade, I count myself among the adoring masses.

One of the things I enjoyed so much about Final Fantasy VI was the story. There were lots of characters with full story lines (and some without), the story went on forever and had a truly epic scope, which I always love, and it had a villain that everyone loved to hate.

Rather than bore you with a litany of things I like about this game, I will direct you to Blogging Final Fantasy, which is written by worthier nerds than I.

The point, though, is that compelling game narrative is a thing rarely achieved. The reason has been debated for some years now, and there are too many viewpoints to cover in a single post. The crux of the issue lies somewhere around the issue of agency. Agency is the sense of power or control that a player feels within the game world.

Most games attempt to tell stories using cut scenes, which by definition remove agency temporarily to convey some narrative material. This convention leads to the logical idea that gameplay and story are somehow opposed and cannot coexist. A story, after all (according to most definitions), exists in the telling of events, rather than the living of events, which is presumably what agency allows us to do within games--to live a series of events, however mundane. A game without agency is no game at all.

So is game narrative just a film narrative broken up by periods of gameplay? I don't think so. There must be some deeper possibilities, but they may require adjusting our definition of narrative. Take Myst, for example. The "game" consists of puzzles, but these puzzles uncover a narrative, told through the two brothers, Sirrus and Achenar. Still, this narrative is not the story of the player's experience -- the player arrives after most of the brothers' narrative has concluded.

Ah, but there's the thing: in Myst, the player's experience completes the story. The two brothers are locked in limbo until the player arrives to decide their fate (and his/her own). An unbroken sense of agency becomes necessary for the narrative, not opposed to it. What's more, in another brilliant move, the makers of Myst made agency the ultimate goal of the game. The only reward for "correctly" completing the game is the continued ability to explore. An incorrect decision traps the player in a prison book and removes agency--the player can no longer move or interact with the world.

Narrative in games, then, perhaps lies somewhere between traditional storytelling and straight-up, means-ends gameplay. And maybe the quality of game narrative should be measured by how successfully compelling events can unfold without removing the sense of agency.

Defending epic towers

Despite Unity's power as a game engine, not too many finished games have been created with it. Could have something to do with the "you have to have a Mac to develop games in Unity" thing. A new, very casual one was just released on shockwave.com: Epic Tower Defense. (Are we defending epic towers, or using towers to mount an epic defense? Hard to tell.)

The game doesn't really show off Unity's graphical chops, but it does have some nice user interface elements and a variety of different game modes. I found it while looking for something to write about and promptly spent half an hour playing. I think I might have blinked once or twice. Sometimes I wonder if I should shelve my epic story-based game and just create a casual one with "epic" in the title.

Anyway, aside from the easy bake oven ad that I had to watch before playing, it was pretty fun. Seriously, how many 8-year-old girls are going to play a game that involves zapping armies of orcs with lightning bolts?

Glorious free textures

The bulk of my time this week has been spent texturing one of my models. It's not a very complex model (in fact, it's just a bunch of cylinders and cubes), but I'm trying to get everything perfect. The process has left me a bit numb in the brain. Nevertheless, I keep reminding myself that I am relatively new to the texturing process, and this is pretty much what I expected.

The tedium of this particular texture (which is clawing its way from the pits of mediocrity) compels me to comment on the special place in my heart that is now reserved for anyone who posts a library of free textures to the internet. I stumbled on Mayang's Free Textures today, which has quite a variety of images, though there is a 20-per-day limit on downloads (if that's the only restriction, I'll take it). I expect to be downloading several in the coming days as I start creating new textures for the ground in my forest. It doesn't seem quite right that the floor of a dense pine forest would be covered in lush, green grass.

So, today I would like to harness the power of the internet and suggest that both my readers write a letter to someone (doesn't matter who) requesting that Mayang be immortalized with knighthood, sainthood, statues, songs, honorary degrees and other suitable accolades for contributing his photographs to the greater good. Thank you.

Game grammar and the structure of creativity

After a short delay since my last post, I thought I would launch into something super heavy: the structure of creativity. Now, before you flick your cursor toward the back button, let me give a little context.

The context
A couple attempts have emerged recently to define a grammar for games, a structured way of describing or diagramming game design that can help us understand what makes successful games work and (we hope) improve the overall quality of our gaming experiences.

• One is from Daniel Cook, who wrote an article in July on the Chemistry of Game Design. Cook's system focuses on "skill chains" as a way to understand the structure and distinct elements of a game.
• The second grammar model is from Raph Koster, who is helming the Metaplace project. Koster's version of game grammar, touched on in roundabout fashion in this Gamasutra interview, attempts to be more detailed than Cook's as a way to describe the elements of gameplay. I'm guessing Koster's game grammar ideas are a huge part of his design for easy-to-create games in Metaplace.
  

Yeah, games have structure. So what?
These two articles point toward an idea I've been noodling for a while: maybe grammar should be considered in a broader way.

Game design is, to me, a unique art form. (To be safe, let's go with a little "a" in "art" for the moment, as in anything artificial or man-made.) Its uniqueness doesn't come from any single trait; rather, games represent the combination of more creative enterprises than any other form of entertainment. Drawing, painting, animation, music, writing, story telling, interaction design, even programming, all converge in modern games.

Each element of game design, and game design itself, has its own structure. Text is divided into paragraphs and sentences. Music contains movements, verses, chord progressions, and phrases. Visual art deals with texture, colors and composition.

So, regardless of the output, all creative processes will have certain things in common:

• A set of tools for creative expression (paint brushes, instruments, paper, software)
• An appeal to the senses (any art form is ultimately about stimulating some combination of the human senses)
  
• A top-down hierarchy of meaningful units (for a novel it might go like this: book > chapter > paragraph > sentence > word > syllable)
• A bottom-up set of rules for combining smaller units into larger ones
  

Obviously each one of these elements could be explored in great detail, but together they form a sort of grammatical structure for creativity (a superstructure even?) that could be applied to any number of disciplines. For any "multi-disciplinary" creative endeavor, success depends on reconciling the grammars of multiple art forms into one coherent whole.

Grammar, creativity, and games
Is all this blathering too general to be useful? Possibly. Big-budget games and movies are usually created by decentralized teams of hyper-specialized artisans. But Art with a capital "A" these days rarely comes from the corporate machine. For games to grow as Fine Art, small groups of people speaking dramatically different creative languages will have to focus their attention on creating a product that embraces this broad structure of creativity to deliver something meaningful.

Modeling a tree (the easy way)

Like so many things in life, I have discovered after days of work that there is an easier way to do something. That's right, my irritatingly complex description of how to model a tree has been rendered obsolete in 48 short hours. Ok, it was obsolete when I started -- I just didn't do my homework before I set to modeling.

What's the easier method, you ask? It's called Arbaro. It's an open source tree generation program based on a paper by Jason Weber and Joseph Penn outlining an algorithm for computer-generated trees. It's platform-independent. It's free.

Here are some images of trees created with the same algorithm.

I downloaded Arbaro and played around with it for about 30 minutes. Parts of it that are less than intuitive, but some helpful diagrams and more-or-less hidden documentation provide a little guidance. Regardless, this is the kind of program that invites exploration, so I don't mind some healthy trial and error.

Besides generating 3D meshes for trees, it also creates automatic UV maps, which are required for texturing. The UV maps aren't perfect, but they're a good starting point.

Lest you think this is turning into a blog solely about trees, I would like to declare an end to this brief series on vegetation. Next up: rocks and stones. Just kidding. Maybe.

The happiest marriage is one filled with rock

Picked up a copy of Guitar Hero 3 tonight. Haven't played it yet, but it's only a matter of moments until I crack open that bountiful trove of rock.

This latest installment includes a co-op career mode that is quite exciting. You see, after years of eye rolling and summary dismissal of video games as a waste of time, my wife finally agreed to play Guitar Hero 2 with me (she even bought a guitar controller for herself), and she was puzzled to discover how much she liked it.

So, it's with much anticipation that I prepare for a rare period of gaming bliss when the guilt vibes are replaced by those heavenly words, "Let's just play one more song." It will only last a few weeks, so I plan to enjoy it.

Modeling a tree, and (r)ambling through the woods

After some fairly tedious work on my pine tree, I have something that doesn't look half bad.

Unity's restrictions for in-game trees require that each tree include a single mesh (for my non-gamer readers, a mesh is just a 3D object composed of triangles) using two textures: one for the bark and one for the foliage. Unfortunately, I didn't know how to place two textures on a single mesh in Cheetah (my 3D modeling program). It is possible, and pretty easy to set up, but it took some time to figure it out.

Create the foliage
Armed with the requisite knowledge of Cheetah's features, I set out in earnest to fill in my tree. The process I settled on ended up being fractal-ish in a way, which seems a fitting way to create a tree:

• First, I created a small group of six polygons that would act as a small branch and a group of pine needles.
• Then I duplicated this small branch 10 or 12 times along the bottom-most big branch on the tree. I scaled and rotated each copy so the foliage would feel random.
  
• Rather than repeat this process for each of the 20 or so branches, I just did it for the first three. This gave me three distinct sets of small branches (anybody confused yet?).
• Then I used those three branch sets to fill out the rest of the large branches, copying each set several times and moving/scaling it into position.

Remove (some of) the foliage
Another one of Unity's guidelines for trees is to keep each one below 2,000 polygons. Alas, after my foliage frenzy, I was about 1K over the limit. Time to optimize. My first inclination was to remove some of the small branches that didn't add much to the density of the foliage and wouldn't be very visible from a distance. This activity, sad as it was to remove the pretty pine needles, didn't get me far enough. How could I remove more polygons without thinning out my lush tree?

Finally it occurred to me that the branches near the top of my tree would never be seen up close. What's more, the branch sets up there had been shrunk down to the point that the polygons wouldn't be visible even if you were up close.

The solution, while probably obvious to you (if you've made it this far), seems poetic somehow. At the very top of the tree, the sets of branches aren't much bigger than a single branch at the bottom of the tree, so I just removed four of the branch sets at the top and replaced them with single branches. The difference is nearly indistinguishable, and I eliminated several hundred polygons. Final polygon count: 1,970. Yeah, I'm kind of awesome.

First the trees, then the forest

I started working yesterday on my first serious tree. I've tried modeling trees before and found them to be quite tricky. Something about the thousands of tiny branches makes them a pain.

Nevertheless, nice trees are yet another a requirement for convincing game worlds, and the first area of my game is going to feature several lovely copses. Unity has some nice tools for creating the forest (there's literally a "make forest" button), but before you can have a forest, you need some trees.

After some brief research I went with a pine tree. One of those tall ones shaped like a cone. For one thing, it will fit well with the atmosphere of the game world. For another, it's shaped like a cone. How hard could it be?

The modeling process went something like this:

• I started with a cone and manipulated it around until it looked like a decent pine tree trunk.
  
• Then I created some smaller cones to use as branches and distributed them along the length of the trunk, making them smaller as I got higher on the tree.
• Then I was ready to texture the trunk and primary branches. I found a nice, free pine bark texture here and loaded it into the GIMP, the open source graphics editing program. One "make seamless" filter, some rubber stamping, and about 20 minutes later, I had a passable, tiling bark texture. Very exciting.

Unfortunately, this is where it got hard. Foliage, it turns out, is even more detailed a thing than branches. Following Unity's advice for creating trees, I tried to create a simple group of polygons that could serve as small branches and needles. The idea is to duplicate these polygons, tilt them, and scale them until they fill out the entire tree.

As you can see from the picture, I barely got started. First I had to find a suitable texture (the one I found could still use work). Then I had to figure out how to work with alpha channels in GIMP and transfer them to Unity, which is a little tricky (I'm still not sure I could do it again).

Despite the complications, I feel that progress is being made. If I'm happy with the result, maybe I'll post a more detailed tutorial about modeling a cone-shaped pine tree.

Sound effects for the rest of us

I was trolling around a Mac game development forum today and discovered a post linking to a remarkable site called SoundSnap that showcases free sounds. I only clicked around for a few minutes, but the number of quality clips is truly remarkable.

My game has a long way to go before sound effects become a necessity, but sound has been a nagging issue for me, since it is a highly specialized part of game development, and I lack the equipment, money, time, and talent to record sound effects myself. This one site should give me a big nudge in the right direction.

Considering how many sounds are there now, I'm excited to see how many there will be when I'm really ready to dive in. Just think, now I'll be able to create that group of happy sea lions I always wanted.

Stone wall textures, a mountain adventure

I went to the North Carolina mountains this weekend with some friends and hit the obligatory Asheville-area attractions: Chimney Rock and the Biltmore House.

Despite suffering much ridicule from my wife, I managed to take a series of texture photos for the game. It's not often that I stand next to massive walls, so I couldn't pass up the opportunity.

Some work will be required to turn these photos into useful, tileable textures. The GIMP has a "make seamless" filter, but I haven't tried it yet. In the event that it doesn't work very well, I will resort to the time-honored tradition of using online tutorials.

The world isn't flat, it's square, part 2

Well, I'm stumped. After what seems like days of pondering, I can't think of a way to create the illusion of a massive world using one square terrain. Sure, the terrain might look fantastic when you're near the middle of it; the problem arises when you approach the edge. What looks like a vast mountain range head-on just looks silly from the side.

I've considered several options, and none of them really satisfies me:

• Use a truly huge terrain. This option is quite attractive, but I pause because, while there seems to be no upper limit to the size of terrains Unity will let you try to create, there is certainly a limit to how large a terrain most computers will handle without choking (I've hung Unity more than once by trying to create too large a terrain). It is therefore a requirement to divide things up into sections.
• Hide the edges of the terrain. One obvious way to do this is with water. Indeed, islands are probably the ideal use of square terrains. But I'm not creating a group of islands Myst style, I'm creating continents. Another option is the inverse of islands: valleys. If each area of the world is surrounded by impassable cliffs, the player will never see the edges. That might work, but what if you discover some lofty perch that lets you see for miles? You would see the edge of the world, and beyond that, nothing. It would be very disconcerting.
• Build a backdrop. Hiding the edges might work, but a world full of squarish islands and valleys isn't very appealing to me. Besides, how can you let the player travel between areas without letting them approach some sort of boundary? Another option, then, is to acknowledge the edge of the map and just use a flat image that looks like it carries on into a new area. The illusion might be convincing enough for the player to go with it. Final Fantasy XII uses a technique like this to divide many of its zones. Unfortunately, I'm not confident in my ability to paint a backdrop that gives the necessary sense of depth.
  
• Something in between. Or I could use some mixture of the first two options. I could hide the edges by building a terrain that is considerably larger than what I need for an area but not so big that it would slow things down. Then I could focus the action of that area near the middle of the terrain, and the functional boundary between zones could exist some distance away from the terrain's actual edge. This could certainly work, but it seems like an inefficient use of the computer's memory and, frankly, like a waste of space.

That's a lot of words to say that I don't know what to do. If anyone has ideas, please let me know.

Part of the trouble, of course, is that I'm trying to force a tool to do something it wasn't really built to do. Probably I should take a step back and come up with a creative solution that will work within the boundaries I've got, instead of trying to explore the edges all the time.

Terrains are fun; UV mapping is not

Just a quick update this morning. Last night I spent my time on two things: UV mapping and terrain painting.

For those of you who don't know, UV mapping is the process of "unwrapping" all the polygons in a 3D object onto a flat image so it can be painted with a texture. This process has gotten much easier in the last few years, thanks to some more sophisticated algorithms having been built into most of the 3D programs. Nevertheless, it is still very time consuming (and tedious).

After getting tired of trying to map UVs for one of my buildings, I decided to spend a little time creating a terrain. I have a fairly good idea how the terrain should be laid out for the opening area of the game world, so I started creating the rough, square shape of it. After about 10 seconds, I realized that making a terrain is considerably more entertaining than UV mapping. I then proceeded to spend so much time on it that I wasn't able to write a blog post.

The world isn't flat, it's square

I spent most of the afternoon today testing the limits of Unity's new terrain system. Partly I'm learning how to use it, but mostly I'm trying to decide how to set up my game world.

Most terrain systems (Unity's included) work best with square terrains created from a heightmap (essentially a grayscale image whose pixels determine how high each point on the terrain mesh should be). The trouble with square terrains is, as you might guess, that the world is not square. You cannot fall off the edge. Unity terrains seem fairly flexible in that they don't have to be exactly square, and they can be adjusted to be quite large. Any really large terrain, however, would come with serious performance hits, since all its heightmap information would have to be stored in memory at the same time.

Because of this problem, most world-based games have chosen to divide things into sections and make the player look at realism-killing load screens when moving from one zone to the next. The notable exception is World of Warcraft, for which the good folks at Blizzard developed some way of streaming terrain information to minimize the number of load screens (this is one of WoW's most important innovations, in my opinion, because it allows a more enduring sense of immersion, and air travel).

So what are my options for piecing together a coherent world? Load screens are a necessity, I'm afraid, since Unity can currently handle only one active terrain at a time. Nevertheless, I would like to divide my world into squares that actually fit together. I may end up scrapping the idea, but I'm hoping that by planning ahead, I will be able to devise a way of making the game world feel coherent with some tricky, on-the-fly switching of higher- and lower-detail terrains. We'll see.

In the meantime, I have to work in squares. I take heart, though, that this is a time-honored gaming tradition. Think of the original Final Fantasy, where sailing your ship westward past the Earth Cave will spit you out on the eastern edge of the map near Crescent Lake. Sailing north will transport you to the world's southern reaches, where you will continue sailing north. It feels perfectly natural at first, until you realize that in a real, round world like ours, one cannot sail north forever.

Unity 2.0 has arrived -- check it out!

Unity 2.0 was released today. I downloaded the trial version and should be getting my licensed copy soon. This means I will have the ability to create terrains and brilliantly elegant GUIs. The terrain engine is really powerful -- not only can you sculpt and paint the terrain, you can paint objects onto the terrain. Trees, grass, rocks...anything really. Trees and vegetation even sway in the wind.

Here's a screenshot of a scene I created in just a few minutes. You can see the GUI I was testing in the upper left corner.

Everyone should go download the new version of the Unity Web player and then check out the demos here. They really are amazing.

A tricky concept

I'm sure all of you who regularly read my posts (thanks) are probably wondering when you'll actually get to see something other than a little blue man and a crate. In fact, how can you be sure that I'm really developing a game at all? I haven't mentioned its name, given any insight into characters or plot, or even shown any concept art. My blog's appearance is pretty bare; it's just a stock Blogger template. I haven't mentioned a web site. The list goes on.

So when can you expect me to deliver something real? I'm working as hard as I can (damn that day job) to create something reasonably professional for you. I don't want to embarrass myself, after all. The truth is I'm learning as I go, and that means a good deal of trial and error.

Beyond the tortoise-like pace of development, my real hesitation is a desire to promote this video game in a meaningful way. The blog is obviously a part of that strategy -- an experimental way to build an audience (tell your friends) and a game at the same time.

Now, one approach to the blog would be simply to post every asset I create one at a time. This would lead to a wonderfully long list of posts showing off disconnected, even random pictures of boxes, trees, buildings, people, animals. It would also leave no surprises for the game itself. If you've already seen all the locations and read about all the characters' inner-most secrets, why would you play? (If you are interested in random pictures, you will transfixed by this endless slide show.)

So I have to control myself. I will want to post pictures of everything, but, no, the trick is to write interesting (and I hope enjoyable) posts while establishing a controlled leak of information that will help build a grass-roots interest in this game I claim to be creating. I mean, how could it not work?

Real-time battles, part 3: party AI

My last post about real-time battle systems looked at requirements for enemy AI. This third (and final) installment will deal with party AI.

To me one of the most significant differences between a turn- or time-based battle system and a real-time system is how the other members of your party behave. Old-fashioned time-based systems like Final Fantasy VII usually have random battles that take place in a temporary battle area. The advantage here is that the player can easily give orders to every member of the party during the battle, since only one party member or enemy can execute a move at any given time.

In a real-time system, things happen too fast to give explicit orders to each party member throughout an entire encounter. One obvious solution to this problem is not to have a party. But if you don't take the easy way out, you have to prevent the rest of the party from being a liability.

The common approach to party AI is, first, to give the player a way to switch control between active party members at any time during a battle and, second, to provide a short list of general behaviors for AI-controlled party members. These often give you three choices along the lines of aggressive, defensive, and support (healing and ranged attacks).

Unfortunately, these limited options usually result in party members that seem to get themselves killed (but only after using up all your items), and there is no way to customize their behavior any further.

Final Fantasy XII's gambit system finally offered a better and more fun option for party AI. By giving the player access to the if-then structure (e.g., if an ally's health drops below 50%, cast cure on that ally) of the party AI system (and by making it a part of the character leveling scheme), party AI became not only useful, but fun. Creating just the right combination of gambits became almost a game in itself.

One criticism of FFXII's gambit system, of course, is that the more gambit combinations are available, the less you have to pay attention during battles. You can literally run up to a group of enemies and go get a snack while your party defeats them. In some ways this is quite nice, but could be quite annoying for players who like finer control. Turning gambits off is always an option, though.

I haven't yet designed the party AI system for my game, and I don't know how I'll approach it. Some amount of control over party members' decisions is essential, but a more robust system would need to be carefully integrated into the gameplay and could distract from the primary character leveling system (which is going to be very cool, but I don't want to give it away just yet).

But until it's time to program party AI, I will turn my attention back to modeling buildings and other inanimate objects.

The joy of texturing

As I mentioned in my last post, creating art assets is likely to be the most time consuming aspect of this project. Visuals are, however, quite important, as a fellow blogger points out. While I'm just starting the process of modeling objects, I would like to take a moment to discuss texturing. The reason is simple. Yesterday I turned the crate I had so expertly modeled into a living, textured game object, and I am pleased.

This is premature, of course, since we have yet to come up with a texturing method (more on that in a moment) or even a color scheme for the first area of our game world. Nevertheless, in an effort to see what might be involved in creating a vibrant wooden object, I set out to texture my crate.

Now, there are really two main approaches to texturing:

• Painting -- this is what the real artists do. Start with a base color in your favorite graphics program and gradually paint in details like highlights, shadows, texture (like wood grain or knots). If you're curious, check out this tutorial on painting, yes, a crate. Painting can yield fantastic results because the possibilities for stylized textures are endless. Case in point, World of Warcraft.
• Photo-based texturing -- It would be unfair to say this method is any less artistic than painting, but the desired effect is different. Photo texturing aims, as you might guess, at realism. Using this method, you would start with a photograph of your desired texture (a piece of wood or, better yet, the side of a crate) and manipulate it until it fits your desired style. My favorite example here is the Myst series.

Which method did I use? Well, neither. My 3D modeling program has a very nice procedural wood shader (which means it creates a texture from a program instead of an image file). So, instead of finding a crate to photograph or trying my off-hand at painting from scratch, I created a flat plane in Cheetah, added a wood shader, customized it by fiddling with some numbers, rendered it, and then used that rendered image as the starting point for my texture.

The result is certainly not going to change the world, but I was amazed how a couple hours of work could turn a drab gray cube into a crate just realistic enough not to be noticed -- and for a crate in a video game, there is no greater accomplishment.

The trouble with modeling

Having made faster-than-I-ever-dreamed progress on gameplay programming, the time has come to turn the bulk of my attention to modeling (that's 3D modeling--my career with Calvin Klein never really took off).

For the sake of completeness, here's a quick list of all the basic gameplay that's currently working:

• Basic movement
• Camera controls (complete with collision detection!)
• Battle mechanics (attacking, casting spells, applying status effects)
• Character, enemy, and weapon stats (attacks actually cause damage)
  
• Enemy death
• Basic enemy movement and AI (lots more work to be done here)
  

My brother, who has more experience with 3D modeling than me, will be handling the bulk of the character modeling and animation, while I will probably focus on inanimate objects (for example, this crate I modeled yesterday). The reason for this switch is simple: while there is plenty more programming to do, a story-based RPG like ours isn't worth much without a world in which the story can take place. It will also help me hold your interest, dear reader, if I can balance my dry ramblings with a few pretty pictures.

Speaking of dry ramblings, I feel compelled to point out that the creation of art assets will likely prove to be the hardest part of this project. Not only must every object in the world be designed and modeled, it must be textured, animated (if necessary), and placed. We're going to attempt a master spreadsheet containing the status of every object in our little world, and I'm genuinely frightened to see how big it will get.

This is the part of game development that separates the big studios from the little guys. Success in modeling depends as much on the number of people as the depth of talent. Our approach will be to take it one building, rock, or tree at a time until we have a world for you to play in.

Two unrelated notes

• My favorite band has cast a surprise announcement on the recording industry: they are selling their latest album on their own web site, with no record deal, and, this is big, for as much as or as little you care to pay. Seriously.
• Secondly, I have one song left to clear on hard in Guitar Hero II--yes, Free Bird. I must beat it before GHIII comes out. I have no choice.
  

The stuff of innovation

Independent Gaming posted a link yesterday to a panel discussion about innovation in games. The panel took place during the Independent Games Summit at this year's Game Developer's Conference (GDC), which happened back in March.

There was a distinct counter-cultural feel to the discussion, even to the point that all the panelists expressed a distaste for the pursuit of innovation (which of course happened to be the subject of the panel). Ok, that last sentence wasn't entirely fair -- I think the panelists' complaint was against innovation as an end in itself. Innovation for innovation's sake leads to gimmickry, so the feeling went, and gimmicks never lead to compelling or enduring art.

Yes, the "A" word. It didn't surprise me that artistic expression was a major subject of discussion. Two of the panelists in particular felt that games should be viewed through the same hyper-individualistic lens as writing, (indy) film making, painting or any other form of individual/small group expression. To these people, games are about the game designer, not the player.

This position ignores the vital question of entertainment. Any public expression (artistic or otherwise) is meaningless without an audience. Readers, viewers, and players contribute to the meaning of an expression by the act of participating and interpreting. Without participation, expression is moot. Participation in games by definition requires the potential for entertainment. For me the appeal of video games as art lies in the fact that the audience can now play an active role. Artists no longer need to dish out meaning and/or entertainment; they can facilitate it.

Unfortunately, high art in games is still just an academic dream. Even recent attempts at forcing players to make difficult moral decisions (see Bioshock) seem superficial at best. Maybe the issue is some incompatibility between gameplay and story. Maybe it's just the youth of video games as a medium. Either way, when you really get down to it, the exploration of these ideas is the reason I'm creating a game. It's not so much a way to express myself as a way to communicate with someone else about something both fun and meaningful.

The pursuit of brevity

It occurs to me that some of my posts have been way too long.

Real-time battles, part 2: enemy AI

My first post about real-time battles dealt with timing -- how to pace a battle so it's fast-paced but leaves just enough time to make decisions. Part 2 deals with a considerably more complicated topic: enemy artificial intelligence (AI).

Before I begin, a disclaimer. I don't know anything about AI -- at least not about programming it (yet). These thoughts are just that: reflections on what's required to simulate an intelligent adversary. The way I see it, the problem of enemy AI can be divided into two parts (at least in terms of RPG games like the one I'm making):

Basic movement
In a real-time battle system, enemies exist in a world filled with obstacles -- rocks, trees, buildings, other creepy monsters -- so enemies need the ability to move around the world without doing silly things like trying to walk through a wall or wandering into the ocean.

Basic movement, then, requires that enemies have the ability to move around in a normal fashion (when nothing is in the way), and to avoid obstacles when they arise. Normal movement, of course, can take several forms. One enemy might patrol between a series of fixed points while another might wander aimlessly in a particular area.

Neither of these possibilities is very convincing, however. It would make much more sense for enemies to move about the world with a purpose. Not only would they lead happier and more fulfilling lives, they would seem more realistic. An evil imperial soldier might indeed patrol between fixed points, but a giant cave bat wouldn't spend all its time wandering within five meters of the place it was born.

Higher brain function (deciding what to do)
Wandering is fine, but what if a player (or group of players) invades the cave bat's cave? It would protect its turf by attacking the intruders. The first order of business is to decide who to attack. This decision is easy enough when there is one player-controlled character, but in a party-based or multiplayer game it obviously becomes more difficult.

Many games solve this issue with the concept of aggro. An enemy might attack the first player it sees, but if another player comes in and deals twice as much damage, he will draw the enemy's attention. Aggro, then, can be thought of as a function of damage or healing. Whichever player in range has offended the enemy the most becomes the object of its raging cave bat wrath.

Once the enemy has decided who to attack, it must then choose the manner of attacking. The conventional way to approach this problem is to build a decision tree. Given its set of possible moves, the enemy will survey its situation and choose a move, often with a healthy dose of randomness built in. For example, a monster with access to a healing spell and a basic attack might go through this sort of thought process:

• If my health is less than 60%, heal myself.
• Otherwise, attack the player with the most aggro.

The options in the decision tree get priority based on their order. As you might imagine, these trees can get pretty complicated. It's not the most sophisticated way for enemies to make decisions (they can't learn), but it is the most straightforward.

A similar approach is also useful for party AI, which I'll discuss in part 3. I know you can't wait.

My camera, vanquished

After three days of wrangling with my code and muttering to myself, I have managed to get my camera system to a place where it mostly behaves. Having accomplished this, I feel a new sense of admiration for games with cameras that gracefully avoid passing through floors and walls. It's still possible to make it pop through a wall occasionally or to find just the right spot where it will completely freak out, but it'll do for now.

Here's the gist of how it works:

• Just before every frame is drawn on screen, the camera casts a series of rays to detect objects around it. The primary ray starts at the camera's target (the player) and casts back toward the camera, ending a short distance behind the camera. A group of secondary rays are also cast pointing outward from the camera itself, like spines sticking out in several directions.
  
• In normal circumstances (when no offending objects are near the camera), the camera can be moved around by clicking and dragging the left mouse button.
• If an object interrupts the primary ray (i.e., passes between the camera and its target), the camera jumps to a point in front of the object. Once the object is clear, the camera slides back to its preferred distance from the player.
  
• If the camera detects an object below it (like the ground), it will begin sliding toward its target. In this mode, the camera's distance to the target is proportional to its own distance from the ground.
• If an object gets too close on the left or right side of the camera, the camera will slide along this object toward the target until it slides clear and can move along unobstructed.

So why was I having so much trouble? My camera didn't have enough feelers sticking out of it. My initial setup only cast rays backward, left, right, and down. With so few, it was easy to make the camera think it should be moving forward and backward at the same time. Once I added a few more feelers--essentially increasing the resolution of my collision detection--the camera started behaving more like I planned.

Then the muttering diminished, and I cracked open a beer.

The virtual web, and how to avoid hitting the ground

The other day I stumbled on an intriguing new project called Metaplace that's aiming to provide an easy-to-use, web-standards-based way to create virtual worlds. The possibilities for creating games are obvious, but this seems an interesting step for the Internet in general.

If Metaplace works like they say it will, it would be possible to turn your web site into a virtual world--meaning that your site wouldn't just deliver content, it would provide a place where people could gather and discuss that content. Imagine being able to chat in real time with anyone else who's currently visiting a site. It could be an incredibly powerful way to make connections. This is a big step beyond our current social networking setup, where people just leave messages amounting to little more than, "I wuz here."

--------------------

On a game-related note, I spent most of my time today working on camera collisions. There's nothing worse than a game with bad camera controls. I'm trying to build a camera that's smart enough to keep the player always in sight. This means recognizing when it can't see the player and moving to a place where it can.

I've gotten to the point where my camera can handle direct obstacles well enough. Things get tricky when it needs to avoid objects like the ground. It doesn't make much sense to look at the player-character through the ground, so the camera needs to recognize when its getting too close to the ground (or something like a wall) and move to a safe spot along the vector between the camera and the player. This involves a lot of math for an English major, so I'll just have to take it slow.

Real-time battles, part 1: timing

Ok, so my last post wasn't exactly about real-time battle systems like I said it would be. This one is.

As I mentioned previously, there are advantages to a real-time battle system (like World of Warcraft or most other MMOs). For one, you don't need to whisk the player off to a "battle mode" that exists in some parallel universe. Another big advantage is that battles can be more realistic. Enemies and party members can attack and be attacked at any time, and there doesn't need to be any god-of-the-battle AI that dictates when each character or enemy is allowed to execute a move.

As you might expect, these advantages come with their share of tricky design decisions. This is the first in a series of posts that will discuss some of the common ones. Where to start?

Timing

Attack speed -- At first glance, timing seems easy. Each character or enemy has an attack speed, probably determined by some stat or the awesomeness of your weapon.

Cooldown -- Ok, that might be enough if all you do is flail about, but what if you want to give your player a special "extended flail" skill? You wouldn't want him to be able to string these together endlessly (it just wouldn't be fair), so you need a cooldown time for each ability or skill.

Charge time -- So now you can't eliminate your target with an endless string of "extened flail," but couldn't you just string together every skill in your arsenal and gank your unsuspecting target that way? (Indeed, this is the method used by every god-forsaken rogue in World of Warcraft.) This wouldn't be too challenging, either (yes, I played a mage), so you also need to implement some system where abilities require time to execute. Then you need to decide whether the charging process can be slowed or interrupted.

Down time -- This is similar to cooldown, but instead of affecting a single ability, down time affects your ability to do anything at all. After executing your supremely powerful "nuclear meltdown" ability, there might be a period of time when you can't execute any new moves, which leaves you vulnerable to the giant cockroach monster that survived the meltdown. Final Fantasy XII used down time instead of cooldown; WoW imposes a uniform down time of about a second after each move, in addition to skill-specific cooldown.

Easy enough, right? Part 2 will cover the intricacies of enemy AI.