Zen and the art of indie game design

Touch Arcade posted an article yesterday about the upcoming iPhone game Zen Bound. Besides looking pretty frickin' slick, Zen Bound is notable because it's aiming at the increasingly popular zen-influenced approach to indie gaming (There is no spoon).



I put this in the same category as other non-traditional games like Jenova Chen's Cloud and flOw, and, to some extent, Crayon Physics (though it's more of a traditional puzzle game). These games are all characterized by a deliberate attempt to avoid the traditional trappings of commercial video games (or even the general concept of gaming). They aren't violent or particularly goal-driven, and they don't present situations where winning something is the player's primary motivation.

Games like this are appealing to me from a design perspective because of their counter-cultural tendencies. What's the best way to create an interactive experience that explores more than the adrenaline rush of today's big-budget games? Make something that moves slowly and doesn't go anywhere. It's a distinctly indie thought process, and it works perfectly for small projects. The focus is on quality on a small scale, doing one thing well and for its own sake.

I don't know if any of these designers will ever strike it rich, but that's probably not the point. The point, I suppose, is that there is no point.

Beyond the numbers: are they just for über-nerds?

Hit points, experience points, reputation points, strength, critical hit percentage, intelligence, agility... There's a long list of "stats" common to games today (RPGs in particular), and most of the time the numbers behind these stats are visible to the player. So do players really want to calculate their crit percentages and crunch the benefits of +12 stamina vs. +10 intelligence? Is it enough for NPCs to express their feelings toward you as +5 love, +7 attraction, and -30 fear?

Asked another way, is it possible to derive any real drama from all the rigid computer logic behind our favorite games? Earnest Adams gives his thoughts in a recent Gamasutra feature about "Numbers, Emotions, and Behavior."

Adams' argument is a familiar one: video games will never rise to their full potential as long as designers continue to focus more attention on the numerical mechanics behind a game than the human element of the game's characters.

In principle, I agree. Games do need characters that behave in more believably human ways. We as gamers would all be better for it, and the industry would get more respect. The constant focus on math isn't a very "humanistic" thing; it feels more mechanical.

The difficulty, though, is that video games aren't just about characters and stories -- they're called games for a reason. We play them. They have rules and structure. We engage in goal-oriented activities and try to win more often than lose. In a fundamental sense, games are mechanical. If you take these elements away from an interactive experience, it no longer qualifies as a game.

Adams notes in his article that "all that emphasis on gear [in RPG games] seems distinctly nerdy." He's talking here about the desire to collect the best items that provide the best stat bonuses and give you the best chance at beating your opponent(s). Is this nerdy? Maybe, but this behavior isn't the exclusive domain of hardcore gamers. Fantasy sports requires the same type of in-depth attention and number crunching, and no one calls it nerdy.

Perhaps the difference is that fantasy sports don't offer the potential for narrative the way video games do. It's pure gaming with no delusions of artistic grandeur.

So what's a game designer to do? Hide the numbers at all costs or give your hardcore players something to sink their teeth into? The answer to this quandary, like most good quandaries, is likely somewhere in the middle, and it definitely depends on the type of game you're trying to make. Could World of Warcraft benefit from more compelling dramatic action or characterization? Absolutely. But would it be so ridiculously popular if it wasn't possible to agonize over item stats and DPS? No way.

Lament of an anti-social gamer

There was a primer posted on Gamasutra a couple of weeks ago about the growing role of social communities in games (and the challenges of building one that works). It's probably obvious by now that there are huge advantages to building an online social community around games -- give your players a place to compare notes and shoot the breeze with other players, and you've got an almost surefire hit, particularly if the game already has a fanbase. Even games that are entirely played online anyway (say, World of Warcraft) have thriving internet communities because they give players another reason engage with each other while they should be working.

But is it possible to provide too many social options for players? It's a lot of work to set up such things, and there may be a point at which actual gameplay can be sacrificed for the sake of "social" features. The case in point is Spore. I was pumped about Spore before it came out. I bought it within a week after release. It's a great game, and it's revolutionary in several ways, but when you really dig into it, there's not much game there.

The Spore experience is so focused on encouraging players to share their creations with each other that I felt from the beginning as if I were missing half the game because I didn't care about looking at other people's creations. I love that other creations are pulled into my universe automatically, but I haven't spent a single minute looking at sporepedia online or making friends in the online Spore community.

(Full disclosure time: I'm not a heavy user of social media. I get it, and I think it's changing the nature of the internet before our eyes. But I lead quite an anti-social online life.)

It's becoming accepted generally that, if you don't build social features into your game, you better do it online. In fact, one of the suggestions I've heard for indie developers is to focus lots of attention on your online social presence. Make your game about connecting, not just playing, say the experts. They're probably right--all my favorite and most enduring entertainment experiences have thriving communities. My lack of participation doesn't mean it isn't there.

What I'm trying to find, being an ultra-indie, is the right balance. I can't build or support a big-time social platform to supplement my games. Even if I could, it would almost certainly seem incongruous with the scope of the games themselves. Nor can I hope to compete with the big casual game sites (which naturally have full-featured social elements).

Probably, as with most things, the answer is somewhere in the middle. Create a game with in-game social elements (like multiplayer) and then give players a simple way to connect with each other outside the game using existing platforms like Facebook apps or embeddable web site widgets. Guess I'll add those to the list of things to learn.

Life lessons from SPUDZOOKA

I still find it difficult to call SPUDZOOKA finished. There are still so many things that would make it better. More levels, more cannon parts and paint jobs, more things to shoot at, a new environment to play in (something other than a warehouse) -- all would help. I even planned to build a level editor at one point.

But, as I've said before, SPUDZOOKA was never supposed to be more than a learning experience. What did I learn, you ask? Did any life lessons stick in my head? Here are a few:

Programming is the easy part
Yes, it's essential. Interaction (gameplay) is what makes games tick, and programming makes gameplay possible. There's no denying its importance. But I learned that it's much more difficult to create compelling visuals than compelling gameplay. Gameplay either works or it doesn't. There are levels of quality in there, certainly, but once you've got your central game mechanic humming along, you're done with the bulk of the work. Everything else is details.

The visuals, though, can go on forever. You've got to model dozens of objects, texture them, and possibly animate them. The process is endless, and it's made even more nerve-wracking by the fact that it's always possible to make something look better. I could have spent weeks trying to create the perfect cardboard box, giving it so much character that you would gasp at seeing it for the first time. But I found that the "good enough" threshold for modeling and texturing comes fairly early in the process for me. Partly I was frustrated my lack of knowledge. I don't know the right tricks to make things look perfect, and I found my patience was limited for experimentation. So I generally created something that was close enough and went with it.

Maybe this means I'm not a natural-born modeler/texturer. Or that I should have been a programmer.

Self-promotion is a tricky game
I loved building the web site for SPUDZOOKA. In my day job I work on a large, convoluted corporate web site. It was fun to create something very simple from scratch. But now that it's there, how do I get people to see it? I can blog about it endlessly, be sure the site shows up on Google searches, submit it to game publishers like shockwave.com (we'll see if they respond), post about it on the Unity forum, and post something about it on Facebook. I've done all of the above, and I even added an e-mail-a-friend feature to the page where you play the game. But there's a critical mass to these things, and I haven't hit it yet. It's been an interesting test. I'll keep plugging away, but I've learned that it's a full-time job to promote something like this using the grass-roots tools of the Web.

If a target-shooting game takes four months...
How long will it take to create an RPG with memorable characters, a sweeping story, and a vast world to explore? This is the big one. It will take (more) years, and a lot of dedication to make it happen. I might be better off focusing on a series of smaller projects and putting the big project aside indefinitely. Or I could figure out a way to divide the big project into smaller ones. Maybe there's another kind of story I can tell that won't be so ridiculously large. Instead of aiming right an an epic, perhaps I should start with a short story.

Regardless of what I decide, I have to decide on something. I'll probably spend the next week or two mulling the possibilities and see what develops. SPUDZOOKA is the first step. Now I have to take the next.

A useful user interface, part 2: The GUI

I've been running the play test of SPUDZOOKA for several days now, and I've learned some really useful things. Special thanks to everybody who has given the game a run for its money. It's going to end up a lot better because of it. (If you haven't tried it out yet, you can play here.)

The feedback has been positive overall, but being my own harshest critic, I feel like the game still leaves quite a lot to be desired. I think the concept is a decent one -- a little light-hearted destruction goes a long way -- but there are some tweaks to the user interface that will make the player experience better. Thus begins the second part of my brief series on user interfaces.

The graphical user interface
There are two main elements to SPUDZOOKA's GUI, and probably most games with a play-level-then-upgrade structure (that's a technical term -- you like it?): the HUD (heads up display) and the upgrade interface.

I wanted SPUDZOOKA's HUD (the graphical interface elements that appear on the screen while you're playing a level) to be as simple as possible. In the top left corner of the screen, there's a score display and a timer. These elements simply let you know how you're doing. The timer is most important while playing, so I think it needs to be much more prominent, maybe even moved to the top-center and given a more graphical treatment.

In the lower left there are two elements, a squarish graphic with a number in it, and, next to that, a smaller squarish graphic with some potatoes in it. These are both really important, but I don't think they work very well.

• The button-looking graphic with the number is there to denote which cannon you are currently using. You only start the game with one cannon, and there's no indication what this number means until you edit your cannon for the first time. Even then, you need to build and save a second cannon before the number means anything. Right now there aren't enough levels for that to be necessary. I'm thinking about cutting out the ability to build multiple cannons -- we'll see.
• The small graphic showing the potatoes is there to denote your current ammunition. Again, you won't know what it means until you edit your cannon for the first time (I think that's ok), but a lot of people who played couldn't figure out how to change ammo. The trick is that you can't always change ammo -- it depends on which kind of barrel is attached to your cannon. I think the meaning of the ammo icons didn't translate well from the editor, and people didn't remember whether they had access to multiple ammo types or not. Probably I need to add an icon for each type of available ammo in the HUD and give some indication of the currently selected ammo.

That's it for the HUD. I wanted to include enough elements to keep players informed during, levels but I think I need to go a little further to explain things.

Now onto the cannon upgrade interface. The idea here is that players can mix and match cannon components to create up to three cannons that not only look cool, but have different strengths and weaknesses.

To make this mix-and-match feature work, I needed several elements:

• A way to select components of various types,
  
• A way to buy components that can later be mixed or matched,
• A place to display the current cannon configuration and its stats,
• Some indication of which cannon (of the three available slots) was currently being edited,
• A way to save a new configuration or return to the previously saved cannon in that slot.

The three component selection areas work pretty well and are fairly intuitive. The result of cycling between components is immediately apparent. The data display for the current configuration seems to make sense as well (except maybe the list of available ammo).

Things start to get tricky, though, when players try to figure out the function of the buy and save buttons. The problem is that upgrading your cannon is a two-step process. First you have to buy the new component, at which point it goes into storage, and then you have to save that component to your cannon, at which point it moves from "in storage" to "in use." The previously saved component on that cannon moves back into storage and becomes available for use at a later time.

It's the inventory concept that makes things too complicated. There are (small) text elements displaying the number of each component in storage and in use, and it's clear that buying a component adds one to storage. Nevertheless, the intuitive behavior, I think, is for the "buy" button to save that new component immediately to the cannon. This seems to be what most people expected.

My attempts to hint at the desired behavior probably weren't enough. The background on the component selectors turns red when you don't have enough in storage to use that component in a cannon (meaning you have to buy one). The background of the full cannon display on the right turns red when you haven't saved that configuration, and you can't save it until you have enough of each component in storage (which would cause the background color of the components to be blue). In other words, once everything is blue, you're good to continue on to the next level. If anything is red, you've got a problem.

If I'm going to keep this two-step system, I think I need to create some additional cues in the interface to let people know what to do. I could make the "buy" button flash when an additional component is required and/or make the "save" button flash when the cannon is ready to be saved. Those two things would probably help a lot.

You can probably tell I've put a lot of time into the cannon editor and the GUI for SPUDZOOKA. I think my first go was passable -- players could figure it out after a few tries -- but I need it to be obvious on the first try. And that will take some more work.

A useful user interface, part 1: Play controls

As a professional "web guy," I have more than a passing interest in user interfaces. The most brilliant concept or the most beautiful design means nothing if people can't accomplish their desired tasks on the web. The same is true, of course, for any kind of application, serious or silly.

For SPUDZOOKA to appeal a wide audience, its play controls and graphical interface must be simple, intuitive, and easy to master. Frustration is the opposite of fun. I don't know yet if I've succeeded in delivering the fun, but here's a look (in two parts) at the basic process I used to design the game's various interface elements.

Play controls
SPUDZOOKA is primarily a target-shooting game, but it borrows a lot of its play controls from first-person shooters. The challenge is to keep the controls as streamlined as possible. Here's what the player needs to be able to do, and the reasoning behind the control scheme I chose for each task:

• Aim and fire the cannon -- The goal of each level is to destroy as many targets as possible within a set time limit, so aiming and firing is kind of important. Thankfully, as anyone who ever played a first-person shooter will know, the mouse provides a perfect interface for this: move the mouse to aim; click to shoot. Easy enough.
• Switch weapons -- Lots of target-shooting games stop there, but SPUDZOOKA lets you carry more than one potato cannon at a time, so there has to be a way to switch between them. Another first-person shooter convention fits well here: using the number keys to switch weapons.
• Switch ammo -- Yes, more switching. Clearly everyone knows that different spud cannons shoot different kinds of ammunition, so I had to work that into the game. The number keys are out for this one (even the higher numbers), since they are being used to switch weapons. I could map several letter keys to various ammo types, but that still seemed redundant and possibly confusing. Instead I decided to use a single button (tab) to cycle through all the available ammo types for the active cannon. The disadvantage here is that it could take a bit longer to select the desired ammo. However, because each cannon will only be able to shoot a few types of ammo, a cycling control seemed to work well enough (let me know if you disagree).

That's it. Seasoned FPS gamers (who made it this far) may have noticed that one important control is missing: the ability to walk around. Seems like a big omission, I know, but I have decided for the time being that the player will be stationary. I'm sure it seems limiting, but there are a couple of reasons for it.

1. The levels are small and potato cannons shoot a long way. If you can run around and shoot things, it might be too easy. Enabling really slow movement would probably irritate people. Better not to risk it.
2. I don't want to complicate things. A lot of the skill in FPS games comes from the player's ability to move and aim at the same time. I know this because I am quite inept at jumping while shooting in Halo, which seems to be necessary for survival in multiplayer mode. While plenty of people certainly possess these skills (they have all killed me in Halo), I don't want those skills to be a requirement for my game. I want to focus the player's attention on choosing the right cannon and ammunition for clearing obstacles and hitting targets, not on maneuvering quickly and dexterously through space.

Once you play through a few levels, you can tell me whether you're completely bored standing in place. In part 2, a look at the graphical user interface.

Good progress...and a long way to go

SPUDZOOKA is coming along pretty nicely now. I've got the backbone of the game working, which means that it's possible to play through several levels and edit your potato cannon in between. You can also change cannons and ammunition on the fly. Everything fits together, and I don't get any code errors when I play through it. All things considered, that's pretty good.

The bulk of the work now is in two places:

• The graphical interface. I need to make it prettier and, I hope, completely intuitive. The goal is for people to be able to play with minimal instructions. I figure a casual game like this can't survive more than a few seconds of, "What am I supposed to do?"
• Level design. I've got a couple test levels built, just to get the flow of the game set up, but they will need to be completely redone. Thankfully I set things up so building new levels shouldn't be too hard.
  
• Ok, three places. I also need to polish up the sound effects and come up with some music. Naturally I plan to compose and record it myself (I've gotten this far, why bring in anyone else now?) That could take a while, but it'll be fun.
• Well...maybe four (nobody expects the Spanish Inquisition). The whole point of building this thing is for people to play. So I have to put the game out there. At the moment the plan is to publish it on a web site, which I have to build. I don't envision anything too complicated, but it'll take a little time.

My goal is to have the game itself finished by the end of March. I doubt I can get the web site done by then as well, but who knows. I'm hoping to have something for you all to play test in another week.

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 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.

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.

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.

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.