Thursday, June 28, 2012

Enemy AI or: How I Learned to Stop Worrying and Love the Flowchart

Most games you play have some form of AI inside of it in order to control Enemy behaviors.

Some are incredibly simple; take the Goomba, for instance.
His only behavior is to move continuously to the left, regardless of pits. If he hits an obstacle, he reverses direction. Codewise, the Goomba behavior is pretty simple to explain and implement, and barely warrants documentation. Even Bowser, the main boss in each world of Super Mario Bros. consists of a continued pattern of jumping up and down while shooting fireballs.

But what happens when you need more complex behavior? What about enemies who actually change what they're doing depending on what the player is doing? Well, that's a bit harder.

I'm not a programmer at all, and have little skill with code; but as a designer, it is still my responsibility to document my ideas in a fashion that is easy to translate to code. The easiest way I've found to do this is using a Flowchart.

What is a flowchart? Well, if you've spent time on the internet, I'm sure you've seen a few humorous ones. But the actual definition is this:

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem.
 Basically, flowcharts are invaluable charts for documenting, analyzing, designing, or managing a process or program. It allows a person to easily see the flow of the processes, and also design a chart that is more-or-less translatable to code. While it doesn't solve the problem of actually having to code the process, it allows people to create a well-designed algorithm, and most programmers and electrical engineers take advantage of them. For instance, here is a flowchart depicting the entire game of Tetris. Neat, eh?

But what does this have to do with Enemy AI?

Most enemies in older games rely on repeated, recognizable patterns. This is beneficial in a number of ways. For one, it's easier to program. But design-wise, it forces a player to recognize the movements and attacks of an enemy, and counter them to defeat it. Players typically get a nice rush when they recognize and overcome the patterns of an enemy. If you've ever played the Megaman games, you'll know that each Robot Master boss follows a very strict set of patterns explicitly made for you to recognize.

Bastards, each and every single one

As games have evolved, so has AI. Nowadays, developers try to create enemies that are the exact opposite: unpredictable. Normally, the reason for doing this is an attempt to emulate the ultimate antagonist: another human being playing against you. So many FPS, RPG and Stealth games in particular try to create an enemy AI that can anticipate what the player will do and act intelligently; but without being cheap or feeling artificial.
Not a good example of self-preservation

This last point is particularly important, because nobody wants to play against an all-knowing player who can see through walls and has perfect aim. But at the same time, nobody wants to play against a mindless robot that never changes up their patterns, defying any attempt of self-preservation. It's a delicate balancing act, between being bound to a pattern that players can recognize and overcome, and being just unpredictable enough to still be a challenge.

In Dead Gear, I'll be taking the more classic way to AI. Not only because it tickles my love of retro games, but because it's simply the best method with limited time and resources.

Here's an example of the first real boss monster in the game:


The Spore Crab that lives down in the Flooded Cavern, directly below the mushroom-filled Greenlight Mine. He's the first boss, so we need him to be pretty simple and forgiving. Every boss in Dead Gear will have a weak spot; the Spore Crab's weak spot is the green mushroom cap growing on top of its head. The player must bounce off the Green mushrooms on the side of the room and HIT THE WEAK SPOT FOR MASSIVE DAMAGE jump onto his head (which also functions as a bouncing mushroom!), and aim their attacks downward onto the weak spot.


For those interested, you can view a flowchart of the Spore Crab's AI patterns right here. Try to see if you can understand how it flows and moves.

Before this post gets way too long and out of control, I'll stop right here. I hope you liked this little talk on AI and flowcharts.

-Alex

Thursday, June 14, 2012

Experimenting with Dead Gear HUD and Menus

Lately I've been experimenting with menu wireframes and layout, and I figured I'd show it here.

Before going into it, let's do a little refresher course on the various design theories. HUDs (Heads Up Display) are basically the method by which information is visually relayed to the player, as part of a game's user interface. That's the technical term, but we all know it as the 'Number of lives you have left' and the 'score' up in the corner of the screen. You might also know it as the HP gauge, the ammo, the compass, etc; basically anything that the player NEEDS to see while playing a game; should be in the HUD.

Some designers have deemed the HUD an artifact of the arcade-era, and have tried to design games with an absolutely minimal HUD. Some of these games, like Ico and Shadow of the Colossus, used this to great effect and created an almost surreal, cinematic experience. These games proved that you could have a well-designed, easily playable game without pesky menus breaking the player's immersion.

Ico went through great lengths to create a seamless, cinematic experience to minimize breaking player immersion.

 Other games followed their lead, such as Limbo, and several other more indie/artistically-inclined games. Even First Person shooters began to remove some thought-to-be-essential HUD elements, like the Health meter. (As mentioned a few months ago in the game mechanics post.) However, on the opposite side of the scale, some genres demand constant micromanagement, such as RPGs and MMOs.

oh my god no

Keeping in mind that Dead Gear is not meant to be an artistic experiment, nor a horrible abomination, I decided to try and keep Gameplay HUD to a minimum, by keeping only the most essential elements grouped together in the top left corner: Health, Anima, the currently equipped magic, and the number of prisms (serves as a form of currency in-game) collected. I also included a small notification in the bottom right that displays the name of the enemy last damaged by the player.



Dead Gear Gameplay HUD

I've also been modifying and fiddling around with the gameplay menu, where the player can check their status, the time played, the % of the game completed, etc. They can then switch to their inventory or fusion menu screens. My original idea for the menu was that the menus were juxtaposed on top of large, slowly moving gears that cover the screen. I haven't decided on whether this crosses the line from 'interesting' into 'distracting,' though.


Current layout for Status Menu

Each time the player opens the menu, the Gears will move in from the sides of the screen. Let me illustrate the idea with terrible little doodles.

1
 Here's the basic screen, with Illyia doing her thing. When the player hits the Menu button, however:




2
 Within a second, large gears approach from the left and upper right, as well as the little switch panel in the bottom right. They'll have to move in fast, because the player will become frustrated and irritated at the game if opening the game menu takes longer than a second.



3
As the Gears move into position, the text and stats appear, as the gears continue a very slow rotation in the background.

Anyway, that's my little spiel on HUDs and the current state of the Dead Gear status menu.


-Alex

Friday, June 8, 2012

Gem System in Dead Gear Part 2

I once hinted about Dead Gear's weapon system, but since then, I've sat down, analyzed it, and completely reworked it. The previous system I had laid out had many good points, but ultimately, I felt I needed to push it in a different direction, and most importantly, design it completely before coding on combat began. Let me give you a few snippets from the game design document:

Illyia has the ability to draw magic out of crystalline stone, and it is her primary method of attacking. Throughout the game, Illyia will find and pick up precious stones and add them to her repertoire of spells, combining them for new effects. She can equip one 'Base' Gem spell, and two spell combinations (fusions) at a time, switching freely. But she can only equip new gem fusions at a save points.

 Gems can be used by themselves, which is called their ‘Base’ fusion. They cost no Anima (mana/MP) to use, and serve as a basic attack for Illyia. Base attacks can also dictate what the general theme of the gem is. Let’s take a look at the very first two gems that the player collects in the game: Diamond and Moonstone.
Moonstone, if fused with itself; equips its Base spell, the ‘Moonstone Bolt.’ Moonstone Bolt is the game’s most basic projectile attack, and it can be held and charged for a more powerful projectile. As mentioned above, the Base hints at what the gem’s defining traits are. In this case, all gem combinations that use Moonstone result in a Fusion that can be charged up for a more powerful attack or effect. Diamond, if fused with itself; equips its Base Fusion, the ‘Blade.

Fusion matrix example, some names are outdated. Magic Bolt = Moonstone Bolt, Magic Sword = Blade

The Diamond’s defining trait is that it is a melee weapon. All gem combinations that include Diamond will be short-range melee weapons, or involve them in some way.
When two separate gems are fused, they always result in the same Fusion. (ie: both Moonstone+Diamond AND Diamond+Moonstone would both result in the Holy Sword Fusion.) The Holy Sword Fusion takes elements of both the Diamond (melee weapon) and the Moonstone (charge shot), and combines them; the Holy Sword is a melee attack that you can hold and charge for a very powerful attack.

A snippet from the Fusion chart. There are ten gems in all, which means a total of 55 different spell fusions.

To continue the example, Garnet’s Base Fusion is Flamethrower; fairly powerful, but an attack that takes some skill to wield. Garnet’s defining trait is that all its fusions are powerful, but come with a requirement that all of its fusions require skill-based usage. Whereas the Holy Sword is slow, fairly strong and easy to wield; the Flame Sword is fast and powerful, but requires precise timing on the combo, stunning the player if the cue is missed.
Likewise, the Fireball fusion is powerful, but requires the player to input a specific command each time they want to use the spell, instead of just mashing the attack button. Since it is a Moonstone combination, Fireball can be charged for an immensely powerful attack.

Or, as a tl;dr: The player will be able to mix together and equip different gems for a large variety of different attacks.

 Hopefully, players will have fun experimenting and choosing different spell fusions to find a combination of weapons that fit their own playstyle.

-Alex