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.

Man on fire

My brother has been working for a while on a better model for us to use while testing animations. Upon importing this model into Unity, my brother insisted that I make it catch fire. Five minutes later, this is what we had. Any demonic overtones are purely coincidental.

Building a world

I've given plenty of props to Unity so far, but even a great engine is only as good as the content you feed it. To create content for a game, you obviously need tools for 3D modeling, animation, texturing, and music/sound editing. Thankfully, there are quite a few options out there even for people operating with a limited budget.

For 3D, I had been leaning toward Blender, since it's free and includes an impressive list of features. It also has a big time learning curve and an unconventional interface.

I recently picked up a copy of Cheetah3D, however, which is very reasonably priced and offers nearly every feature I need: first-class modeling tools, skeletal animation, UV mapping, 3D texture painting, and, in the most recent beta, light mapping. The user interface is a snap to learn as well, and objects created in Cheetah can be imported seamlessly into Unity.

I'm getting to the point now where I will need to begin churning out content and building the game world. Efficiency is paramount for a small shop, so tools like Unity and Cheetah can make a daunting task much more manageable.

My next post will talk about some design decisions required to set up a real-time battle system.

In Blizzard's shadow

Hello, my name is Ben. It has been one year, five months since I last played World of Warcraft. I am proud of my resistance to the temptations that keep tugging at me, like The Burning Crusade, the fact that all my friends and family still play, and the peer pressure brought on by the Scroll of Resurrection.

Despite my resilience heretofore, I find it hard to escape the shadow of WoW that looms over my game. This is particularly obvious in my control scheme. Left click to look around your character. Right click to turn him. Scroll wheel to zoom in and out. Some of these are standard features of PC RPG controls, but I find that as I refine the controls, almost all my decisions are made by furrowing my brow and trying to conjure memories of how they did it in WoW.

As you might imagine, this is cause for concern. The easy thing would be to grab The Burning Crusade free trial from my bookshelf and fire up my old account. (I stood over the trash can for a minute after receiving said free trial but could not bring myself to toss it. Now it just watches me work.)

No, the right thing to do is mimic the intuitive parts of the WoW control scheme then try to improve on the frustrating bits. I don't want my game to look or feel like WoW, but genre is a useful thing and must be acknowledged, even as it relates to keyboard input.

Now if I could just remember those frustrating bits...

A sneak peek

One of the coolest things about Unity is its Web player plugin. It's the same idea as the Flash Player, but it renders amazing 3D graphics instead. Pretty cool.

As a way to test out how well I will be able to embed builds of my game into this blog, I'm posting here some of the progress on my battle system. It's not much at first glance, but there really is quite a lot of depth to it. Here are some nuances to look out for:

• The way blue box man's left leg twitches when he runs.
• The fireworks that go off when he lands a Super Attack (press "2" to execute one--you'll love it).
• The way he runs forward while moving backward.
• The glorious piece of weaponry that blue box man and red box man are both carrying.
• The way the camera gets stuck above blue box man's head when you zoom in too far (using the scroll wheel).

Here are the controls. (You need to download the Unity Web player to play the game.)

• Right mouse to enter full screen mode (highly recommended--some of the controls don't work too well otherwise).
• Click on an object to target it.
• Left mouse: look around
• Right mouse (in full screen mode): turn
• Scroll wheel: zoom in and out
• w, s: forward and backward
• a, d: turn left and right
• q, e: strafe left and right
• 1: attack
• 2: super attack
• 3: cure
• 4: spell

Oh, for a space helmet

I played Metroid Prime 3: Corruption for the first time tonight. Aside from the usual "wow, this is really cool" effect of playing Wii games, two main things about the user interface struck me as very well done.

• First, the controls (of course). The running, aiming and shooting action all take some getting used to, but there are some very nice touches, like moving the wiimote toward and away from the screen to activate a door lock.
• The heads up display (HUD) is also really nice. Samus Aran of course wears a nifty space helmet, and the HUD actually looks like a visual overlay from inside her helmet. So instead of information sitting on the screen in some sort of omniscient way, it really looks like you're seeing only what she would see. It's also possible to make out the faintest reflection of Samus' eyes in the HUD, which is a brilliant detail.
  

Ok, so the controls and HUD basically make up the whole user interface, but the sense of immersion is almost immediate and breaks rarely (most notably when she rolls into that little ball).

This of course leaves me wondering how to improve immersion in an RPG-type game. Standard RPG controls and HUDs hardly make sense at all, actually. How do you know how many health and magic points your target has? What do menus and hotkey bars have to do with making decisions in a real battle?

One answer is that the objective is different in FPS games than RPGs. FPS's rely on first-person perspective and a direct connection between player and avatar. Often the in-game character's face is never visible. RPG UI tends to be much more akin to omnicient third-person perspective in a novel, where the player assumes a god-like control of characters' actions. Maybe these two kinds of perspective are just there for different reasons, to facilitate a different kind of immersion.

This to me seems like an easy out for RPG developers. I think most of the time the quality of immersion (and story telling) takes a back seat to the goal-oriented "game" aspect of things (why else would you need to see a number flash on screen every time you deal damage?). Some would say that's the way it should be, but I'm not so sure.

So how do you combine the best of both worlds? I'm not sure yet, but my best idea so far is to have all my characters wear space helmets.

The right way round?

One of the challenges for small game development teams must be division of labor. Your standard team might include a programmer, an artist, an animator, and a game designer. If you're lucky, you'll even have a writer (though most big-budget titles don't even seem to have those). But, as with any small team, there is likely to be some crossover in roles, particularly as deadlines approach.

Seems easy enough, but what if your team only includes one or two people? The first thing you would probably say is, "Don't waste your time on an epic RPG." We already know people like me would ignore that, so the question becomes, "Where do you start?"

You could start anywhere, really. Obviously you need a concept and a premise. Then you could work on character designs, level designs, concept art. The right thing to do would be to write up a formal design document to force yourself to think through all your major design decisions.

My answer: gameplay programming. This is odd to me, since I am not a programmer by training, or even by interest, really. So why would I treat it as the starting point for my game? Structure.

The way I see it, concentrating first on programming lets me create a functional skeleton for the game. Once that is in place, I can begin replacing placeholder elements, like my blue box man, with more--interesting--objects. I think of it like the outline of a paper. Once the structure is in place, the real creative work can begin.

Is this the right way round? Who knows, but it makes sense to me, and in a team of two with no deadlines, that's all that matters.

Fun with blended animation

In this post I'm going to dig into a particular topic a little bit: animation. First, a little setup.

When I switched to Unity from Torque, I also decided to change the nature of my battle system. I had been working toward a time-based battle system in Torque, which meant that each character or enemy in the battle had a timer that would reset after each move and then refill over a period of time. When the timer filled, that character/enemy would enter its desired move into a queue that would execute one move at a time.

One big advantage of this system is that it's easier to input moves for multiple characters (since only one character/enemy is doing anything at any given time). Unfortunately, it's also a bit dated (think Final Fantasy VII) and works best with a separate battle screen.

So, in Unity I'm working on a more "real-time" system like World of Warcraft or Final Fantasy XII where enemies are visible all the time, have an aggro range, etc. This type of system is much more realistic and helps maintain the illusion of the game world, which is something I want to do as much as possible.

So what about animations?
Time-based systems make animations a little easier to handle, since each animation occurs in sequence and involves the entire skeleton. A basic move might go something like this.

1. "Idle" animation playing before the move.
2. Play a "run" animation and move toward the target.
3. Once the character reaches the target, transition to an action animation (like swinging a sword).
4. Play a "run back" animation and move back to the starting location.
5. Transition back to the "idle" animation.
   

A real-time battle system isn't quite so neat. At any time, your characters can be running in any direction while attacking, being attacked, casting a spell, etc. So your animation setup needs to be pretty flexible. This kind of thing is usually handled through the concept of animation blending. Here's Unity's discussion of the subject. To use blended animations, it's often a good idea to create separate upper and lower body animations that are combined at runtime. So your animation setup might look something like this:

• Full body
• Standing
• Walking
• Running
• Strafing
• Walking/running backwards
  
• Upper body only
  
• Swinging weapon
• Spell casting
• Blocking an attack
  
• Taking damage

With a blended animation system, you can give the upper body animations control over the affected joints in the skeleton when necessary, without interrupting whatever is happening in the lower body. This way you swing a weapon while standing, running, or whatever. Also, with a layering system like Unity's you can blend multiple upper body animations at once. This means you can run, swing a weapon, and take damage all at the same time.

Learning to animate
Animation is a very complex subject and an art in itself. I don't claim to be very good at it, but there are a lot of good basic tutorials out there. I'm particularly fond of this one, which explains the process of animating a run cycle.