Thursday, May 25, 2006

Miniclip's Wild Waters

Miniclip has presented an old idea and wrapped it in impressive 3D graphics and amazingly addictive gameplay. While new players may have a hard time getting used to the controls, they will soon feel entrapped by the replayability and will keep playing for hours.

I'm talking about Waterslide Slalom, the popular gaming portal's popular waterslide simulator that was in the "Top 10" list for some time (the reason I'm late in reviewing it is simple: I can't stop playing!) The 3D graphics make this a visually impressive product (and the sound ain't too shabby either), but the real reason for the success of this game is what I call the Almost Factor.

The Almost Factor is what made Waterslide Slalom a huge Miniclip success.

The Almost Factor is when the game makes the user feel like he or she almost beat the game, but not quite, and if they try again, they can do it! They almost crossed that chasm. They almost beat the alien boss. They almost beat the other car. They almost made it to the end of the slide without falling off. And so they try again and again, each time getting a little closer to the goal and finally making it, only to be met by a whole new set of challenges.

Waterslide Slalom uses a brilliant system of "whoops! almost made it" that keeps players coming back for more.

Waterslide Slalom utilizes the Almost Factor beautifully, and that's what makes this game a winner. I've often picked up this game fully intending to only play for a few minutes, and the next time I look at the time it's been 45 minutes. I'm sure you'll have a similar experience, and that's why I'm giving this game a 9/10.

Have you played Waterslide Slalom? Click the "comments so far" link below and tell us what you thought; your opinion counts!

Monday, May 22, 2006

"Good Enough" Really Is

Occasionally game designers and programmers use complicated AI when it isn't really needed. Many times this complex behavior can be simulated with a lot less code and processor use. So when should developers use complicated AI?

The answer is simple: only use complex AI when the player will notice and appreciate the result. Some examples would be first person shooters; sometimes the developers spend countless hours and energy developing amazingly intelligent AI when all it does in the end is run, jump, and shoot. Simpler systems do the same thing, but the programmers wanted to show off their skills instead. Examples? I don't have any. You can't tell the difference, so unless you developed the AI, you don't know anyway.

However, I do have some examples of games that were (and for some, still are) extremely popular and addictive, but utilized some of the simplest AI ever created. Think about Space Invaders, the first real video game ever invented. The AI was also the simplest AI ever invented; the aliens simply marched across, then down, across, then down, until they eventually overpower the player and the player loses. A simple design (the simplest, really), but it created the most popular game of its time (actually, it was the only game of its time!)

Space Invaders implemented extremely simple AI.

Another example would be Pacman. The AI was quite simple really; one ghost chased the player, one stayed close by, one tried to cut him off, and the last one moved randomly. The AI could have been much more complex, implementing reinforced learning, neural networks, or any other AI systems, but simple path finding did the trick. Even if those systems had been implemented, how much difference would it have made?

Simple path finding was used to make Pacman an ageless arcade favorite.

Can you think of other examples of simple AI? Or how about an example of complex AI that isn't really realized by players? Let us know about it; your opinion counts! Click the "comments so far" link below and tell the world what you think!

Wednesday, May 17, 2006

For Fun's Sake!

One of the worst mistakes a game studio can make is designing for the studio instead of designing for the player. Nobody wants to play a game that's just a tech-demo or a flashy graphics-laden piece of artwork. One of the ways this problem occurs is when the studio is "ruled" by one of the major departments: designers, artists, or programmers.

When the designers are in charge, they might make demands that are impossible for the programmers and artists to meet, resulting in a game that fails to meet expectations.

When the artists are in charge, the resulting games will be laden with flashy quality graphics, but they will be boring and dumb, suffering from major design problems.

When the programmers are in charge, the results will be games that require micromanaging and are way too hard to play. They will be technology driven and very impressive to be sure, but they won't be any fun.

The solution is to allow all the departments to work together on the same level, as well as requiring programming, art, and design experience from everyone, so they can understand the different points of view.

Another reason studios might not design for the player is because they don't playtest enough, or their playtester groups never change. The studio will get more and more used to their own game during its progress, and they might overlook major flaws in the design. Similarly, when the same group of playtesters is used throughout a game's development, they may get used to different problems and come to accept them.

Whatever the reason, game development studios need to design their games for the players. They need to consider what the player will see and do, not just how the game operates under the hood or whether or not it has impressive graphics.

Can you think of other reasons studios might fail to bring the player into consideration? Click the "comments so far" link below and let us know!

Wednesday, May 10, 2006

Right to a Fair Trial

When designers are going over the feedback provided by playtesters, they should be wary that not all ideas have merit. Some ideas should be considered, others should be immediately thrown out. For ideas there is no "right to trial by jury," as some people delusionally think. Feedback falls into three basic categories:

1. Additions

These are new features that playtesters recommend, often a favorite feature of a similar game that they think should be in this game too. should be chucked out a second story window upon conception. If a designer begins to seriously consider adding a feature after the project has reached the playtesting stage, it isn't a good thing, its a sign that he hasn't thought the design through enough. In that case, he should go back to the drawing board and start over.

2. Improvements

These are embellishments on features already in the game. They should get a few minutes of thought, but if the designer isn't convinced after that, he should throw them out as well. Better yet, he should file them away so that later, if the game has flaws, he can go through these and see if they solve the problems.

3. Corrections

These are fixes that correct bugs or harmonize different elements of the game that have been at odds with each other. These should be embraced and immediately implemented. They require no thought whatsoever. It's that simple.

Can you think of other types of feedback that wouldn't fit into these three general categories? Click the "comments so far" link below and let the world know!

Monday, May 01, 2006

An Unhealthy Attachment

Few elements of gaming have become more cliche and standardized than the health bar. You get shot, you lose health. Get shot again, and you lose health again. When the health is all gone, you lose a life and the health resets. It's a simple system, and it works. Unfortunately, it isn't very realistic.

In real life, the type of bullet isn't the only thing that determines whether you live or die. Other factors include where you got hit, how far the bullet went, whether or not you're bleeding (and how much and from where), how fast your body can heal, and physical and mental strength. The health bar fails to take any of these factors into account, and for many of them, it simply can't implement these features. A radical change needs to be adhered to, and the health bar should be abandoned forever.

What are some alternatives? One is a multi-bar system. In this system, each major body part has a seperate health bar. This version of the health bar is used by the MechWarrior series, as well as some smaller free games, such as IVAN, an RPG. However, this implementation isn't completely lacking in faults either. Let's continue looking at other examples.

The MechWarrior series implemented a limb-based damage system.

A simpler implementation that fulfills some of the "bleeding" aspects that are required by a realistic health system is the bleed bar. This is a seperate bar that measures bleeding; it goes up as the player takes damage, and the level of the bleed bar decides how quickly the health bar gets lower and lower. Medipacs can both increase the health bar and decrease the bleed bar to help heal the player, but multiple medipacs are necessary to completely heal him. This works well in many cases, but it still fails to take many other elements into account.

Why the big deal, you might say? Why isn't the health bar good enough? After all, there are many things about games that aren't realistic: lasers, for example. The answer is simple: at a time when "realism" is all game developers ever talk about, gameplay realism should come before graphic realism (I've talked about this before in my article about RPG level systems; look there for more information regarding this argument).

IVAN, an RPG, uses a limb-based damage system.

Can you think of other aspects the health bar fails to account for? How about different alternatives to the health bar? Or maybe you think the health bar should stay? No matter what you think, we want to hear from you; your opinion counts! Click the "comments so far" link below and let us know what you think!