Tuesday, September 25, 2012

Quick Update!

Whoops!

It's been a while since I've had a chance to update the blog; it's been pretty busy since August.

I got a new gig as a Game/Level designer for a small indie company, and Ameen has been super busy at his new job as well. However, now as things begin to settle down, we're ready to get back into Dead Gear.

I'll be trying to update at least once every week, or at the very least, 3 updates every month. (For real, this time!)



As Ameen works on getting the base code for weapons and enemies prepared, I've begun to start experimenting with more finalized looks at the game and continuing to muck around in the design work. Here's a look at one of the updated Crashsite areas; pretty fancy; a far cry from the original rendering, eh?

On a side note, it's a good month for games, it seems. If anyone's interested in roguelikes, I'd have to recommend the excellent FTL, a scifi roguelike that's had my attention lately. It's a gem of a game, although I do wish it had more content; it takes a lot of willpower to resist modding it and adding 500+ more events, extra races and ships to the game myself. (Maybe one day!)

I'll try to do a nice Dead Gear design post next update.

-Alex

Monday, July 30, 2012

On Title Screens





Title screens. You know what they are. Whenever you start a game on your computer or console, the game cycles through a myriad of slash screens displaying the publisher's logo, the developer's logo, the engine used, etc. But eventually it always comes to the first screen you'll see in the game: the title menu.

I've been pretty busy lately working with Ameen, and getting a lot of design work done, as well as finalizing Dead Gear's native resolution, and working out some bugs and problems with the Unity engine. But until a few days ago, I still hadn't actually worked out an actual title menu screen, aside from some layout frames. Heck, I hadn't even really put any thought towards the game's actual logo!

When Daniel chatted with me a few days ago regarding the main theme of Dead Gear; I thought that it would really help inspire him if he had a closer idea as to what the music would be accompanied by on-screen. So I gave him a few mockup splash screens that would appear right when you boot the game up.

An animated splash screen that eventually fades into:
This! The logo for Daedalus Games.

This splash screen is followed by this:

A static splash screen for the COGS project; a series I hope to continue.

But I had yet to create the actual title menu or Dead Gear logo. So I set myself to brainstorm mode and, through a lot of trial and error, came up with this:

The current Dead Gear Logo.

As anyone who has tried their hand at graphic design will tell you, the art of crafting an excellent logo can be maddeningly difficult. I must have tried ten dozen different ways to create a clever logo that somehow incorporates a gear into the letters themselves. My best effort? A G that looks kind of like this:

if you flip it on its side, it kind of looks like a flamingo's head
But eventually I came to the semi-finalized version above, which gave it the sort of look I desired: a more elegant, simple, Final Fantasy style. I then incorporated it (again, through a lot of trial and error) into a mockup title screen:

To fans of my comic and not-comic, it might look familiar!
While still not perfect (it'll certainly need more tweaking before release), I felt that it fit the mood I was going for. And while I was crafting this, I did a lot of thinking about title screens in other games. There's a pretty rich history of title menus.

Galaga, or wall of text, the game?

Back in the 80s, menus screens were almost carbon copies of their arcade counterparts. In arcades, menu screens were pretty barebones, and served a few pretty simple purposes: to display the current high score, to display the game's logo as prominently as possible, how many credits had been inserted and as a small menu to choose whether to or not you'd be playing with other people. As a general rule for the early title screens, it always seems like there's more text than anything else taking up the real estate of the screen, and then programmer art.

Damn your rustled, windswept hair, megaman.
Eventually, as programmers let the artists do more of the layout work, and most of the text disappeared in the early 90s. Art filled most of the screen, giving a more aesthetically pleasing title screen. Now, the text that did remain were purely for the sake of the menu. In the early 90s, some games began giving players the option of difficulty levels as well, something that wasn't very common with arcade games of the age.





Eventually, as the 90s progressed and tastes were refined, only a single unwritten rule remained: The game's logo should naturally take up a large portion of the screen space, with a small copyright text. This wasn't so much a rule as it was common artistic sense: this allowed the title screen to be both pleasing to the eye, and it gave the developer a chance to hook players into the game. If the players weren't sure if they wanted to play the game, they sure did now.

The Zelda and Chrono Cross title screens were interesting, as they were simply the game's logo imposed over a moving 3D background, displaying gameplay or the game world itself instead of static art or imagery. Zelda's title screen played the iconic Zelda theme while listening to the stomping of Epona's hoofs, which was for many who played the game, an extremely memorable experience. Chrono Cross' title screen played soothing music while moving a camera through a beautiful underwater landscape. Many other games eventually took that path as well, although many still opted for classy static backgrounds and art.






Now, in the modern age of gaming, developers have tried to keep things as simple as possible. Many indie games and many AAA-quality games still go for the simple, static approach. Other developers try to mix it up a little, like how Valve cleverly changed the backgrounds of Half-life 2 depending on what section of the game you were currently on; serving as a sort of reminder to the player as to where they last left off. (Minecraft used a similar idea as well, using a generated world as the background for the title screen.)

So by looking at all of these, what do we need in a successful title screen?

I would say that it really only requires three things:

-A good, strong title/logo.
-A non-clashing background. If the background clashes with your logo and the menu, it will look amateur. If you want an example, take a look at the majority of flash games.
-Music and/or sound! Tying a memorable song to the main menu/title screen is important, as the players will be going through it each time they play the game.


With Dead Gear, I decided to go with a more static, simple imagery; simply because I felt it worked best. The maps, ink and paper slowly shift in the background so it isn't just a flat, unmoving image. Anyway, that's my little talk on title screens. Sorry for the lack of updates this month! In August I'll try to go for one update per week.

Take it easy,

-Alex

Friday, July 13, 2012

Main Characters and the Blank Slate theory

On this blog, I've never really delved into the plot of Dead Gear, but today I figured I should at least tell you who it's about!



The player controls a girl named Illyia. Her direct description from the game design document is as follows:

A curious-minded 15-year old Aetherian girl named Illyia. She has an unusually strong gift in Crystalmancy, the ability to evoke magic from crystals and stones; a trait common in her Aetherian heritage. Raised by wealthy foster parents in Central City, she braved an adventure to find her real parents in the midst of the Centralian-Aetherian war, forging friendships with unlikely people. After crash-landing on Dead Gear, she will stop at nothing to find her friends in the Daedalus crew. She prefers dressing simply, wearing only a purple tunic and a necklace. Her refusal to wear shoes is a source of humor and fascination among those she meets.

 As the description says, Illyia's main skill is in Crystalmancy, her ability to use magic from the stones and gems she collects during the game. She's an intelligent, sharp-tongued girl, and her dialogue in the game reflects that.



This reminds me of a technique used in a lot of games, and you're probably familiar with it. You can call it the blank slate theory, the tabula rasa theory; but basically, it's a silent protagonist. A main character that never speaks, but may convey emotion through facial expressions, actions, etc.

If you're any kind of gamer, you'll recognize this type. Mario, Link, Gordon Freeman, Samus Aran, Master Chief, Chell; all of these characters belong to this trope. Some people in the game industry have gone on record saying that they hate the silent protagonist, that it's lazy storytelling. They prefer a fully developed character, or at least one that you can mold to your own liking, like Commander Shepard in Mass Effect.



And yet, games such as Wind Waker and the Paper Mario series excel at telling a fairly complex story with nothing more than pure expressiveness, and even some tongue-in-cheek lampshading of the trope itself. Even Jack from Bioshock is completely mute, and it only seems to intensify the narrative. Why is it so effective?
When a person plays Zelda or Half Life, the silent protagonist technique allows me to play a blank slate and put my own personality into the character. They depend on other characters and situations to do the talking for them, and I can personally respond to these characters and situations in my head, without having thinking about what Link would ACTUALLY say. It endears the characters to the people playing, because effectively, they are playing as themselves.

 Of course, the silent protagonist technique doesn't work for all games. Would Metal Gear Solid have worked if Snake hadn't spoken? Probably not very well, even if all he did were annoyed grunts. It all really depends on the game and the plot. If the plot is character-driven, then the silent protagonist usually doesn't have enough strength to stand on its own; unless the side characters are so compelling that the story really becomes about them (such as Bioshock). 








 All in all, people who dislike the silent protagonist are often missing the big picture. They feel like they need a pre-established character in order to create a compelling narrative, and that simply isn't true. Some people simply cannot seem to immerse themselves into a blank slate character, and that's kind of a shame, since many of the silent protagonist games are the most well-written! 




With my respect for the silent protagonist, you might think that I would adopt that plot mechanic for Dead Gear, especially since it's a common device in Metroidvania-style games. But I ultimately decided to give Illyia a voice of her own, rather than the player giving her one. She's a developed character with a past of her own and a story to tell, so I thought that it would be the best course of action.

-Alex




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

Tuesday, May 29, 2012

Mockup Update

Quick update: Here's a mockup of one of the bosses in the 'Bunker' area of the game. As you fight it, the corrosive acid rises and lowers. Was definitely listening to old Contra music while making it.


Monday, May 14, 2012

What Game Designers are Not

I just read a little interview with the director of Diablo 3, Jay Wilson, and I thought he made a pretty excellent point during the talk:

"And so a lot of the times I think you see people get into design because they have a lot of ideas and they think, 'If I'm the designer, then everybody just has to do my ideas.' And I would say if that's your reason to get into design, please don't go into design. That's a terrible direction to come from."
"If anything, your goal as a designer should be, 'I can't wait to get somebody else's ideas into this game,' because you're not going to be the one making it. Your art team and your programming team are going to do a ton of the hands-on work. You're not even going to be able to work until they do their job."

This is great, and I think very truthful of a lot of gamers who want to break into the industry. They think to themselves: 'I can't do art, I can't program, I can't compose music; but hey! I have a lot of ideas. That's what game designers do, right?'

Unfortunately, everyone has ideas! An idea man is not useful, because ideas are the only thing he can provide.
Most game designers have a background in art or coding, because the more disciplines or fields of knowledge they have, the better they will be able to filter their own ideas or ideas from the rest of the team, into a big pot of good ideas (hopefully) that we would call the game.


Wilson continues:

We get anywhere from 400 to 700 skill ideas. And there's a whole bunch of them that are awesome, but either aren't right for the class, or they aren't right for the game. That's the designer's job: to know the difference. It's not an artist or producer's job to know that. It's the designer's job to know that."

 The Game Designer is just that; they control and design the infrastructure of the play mechanics of the game. They do not just toss out ideas and expect others to make a game.

Of course, in small teams such as Dead Gear, where I essentially perform the Level Design, Game Design and Artist roles all at once, I believe the Designer has a bit more say in what the actual game should consist of.

But overall, and I've heard this echoed by tons of successful Game Designers, the main role of the Designer is to LISTEN. You listen to your team, you listen to your playtesters, you listen to everyone. It is arrogant to believe that good ideas can not come from people who aren't designers. That being said, the Designer needs to fight for the good ideas, and stick to a particular vision; otherwise you run the risk of draining time, resources and team morale by redesigning things over and over based on people's comments.

-Alex

Friday, May 11, 2012

The Importance of Illustration in a GDD


As I create pages within the game document and direct tasks for coding, it's become more and more apparent that in a good design document, the game designer should illustrate almost everything to better convey what they see in their mind.

I'm personally guilty of writing everything down in finely organized text and charts, with my own imagination filling in the blanks. The obvious danger of this is that the rest of the team will simply not be able to comprehend what your ideas are unless you make it as clear as possible. I'm an artist by trade, so the easiest way to go about that is just drawing or making a mockup.

After all, while this section in the GDD may convey most of the necessary information:


Something as simple as adding a little sketch can really help.




Or rather than giving a detailed text explanation about how swimming mechanics should work, I found that simply making an easy little image document (in addition to the detailed explanation) made things more clear:



So, lesson learned. When in doubt about explaining unclear mechanics, always take the time to create a visual example for the rest of the team, and save everyone a lot of time.

-Alex

Saturday, April 28, 2012

Game over, man, game over


 I was recently replaying SOTN, one of my favorite games of all time. As I died the umpteenth time to a particularly mean boss in the inverted castle, I realized something.

Game over screens suck!

Game over screens were a staple of games even as early as the 1950s, with pinball machines lighting up the phrase with lightbulbs.

 Naturally, they became a staple of the arcade scene as well, often followed by a CONTINUE? screen with a countdown, challenging arcade-goers to empty their pockets of sweaty quarters.

 So in reflection, I guess game over screens have always sucked for people experiencing them. But when did they begin to become obsolete?


In an arcade, getting a game over literally meant your game was over. There were no save points and you had a finite amount of lives.

 When the home consoles came out, many of the games available were formatted the same way. They were essentially arcade games for home.

You just didn't have to pony up the cash to continue. Heck, in most early console games, you didn't even get continues.At best, you might get a terrible password combination to get back to roughly the same place you were when you died.

But even when savepoints and checkpoints were being introduced late in the famicom's life cycle, the game over screens persisted, even though the game was never over! 

I suppose the main point of this rambling early-morning post is that Game Over screens are largely obsolete, and usually irritate a player if he has to sit through the same game over screen, press start, wait a few seconds for the main menu to appear, and THEN reload his save.

If you're designing a menu screen flowchart for a game, allow the player to instantly reload their latest save directly the game over screen. This way, instead of a game over screen, it becomes a permanent Continue screen, without the question mark, and you don't grind a player's nerves.

I've noticed that personally, if I am able to instantly reload my save when I die, I'm not nearly as irritated than having to wait 10~ seconds and go through a few screens before reloading my game.

Just something to think about.

-Alex

Friday, April 20, 2012

BHOLDR Mockup

Quick little update, I was fond of this mockup I just did, so I decided I should post it. Click on it for full, animated size.


The room houses a neurotic Artificial Intelligence named BHOLDR, and his little pet.

This room serves as the shop in the game, the AI sells you the junk his pet scavenges from the Dead City. In typical Metroidvania fashion though, it is possible to beat the game without ever finding him.


Once I get the assets in-game, I'll have to take advantage of some particle effects, maybe add some dripping water and steam; should look pretty nice.

Update-wise, we inch closer and closer to a workable prototype. We've completed a great deal of the movement-based code, which is, for obvious reason, the bread and butter of a platform game. I've even gotten my little idle animations in there too, which is nice.

-Alex

Monday, April 9, 2012

A small look at my level design process in Dead Gear

While a significantly large portion of the design work is done primarily in word documents; I still have to design the actual world prototype. Here's a very small , shrunken cropping of an enormous 1:1 scale game world map that I build in photoshop. (The actual 1:1 image is somewhere around 60000x18000 pixels; it's pretty huge.)

It's an evolution of the original layout I had created using Visio, which is pretty invaluable for layouts and flowcharts.



As you can see, the majority of it is simple gray and black; with only a few colors to discern special platforms, enemy placement, or objects affected by gravity. It's very difficult to not get caught in the trap of making everything beautiful from the get-go, like IceForest1 up there in the corner. But it is essential to get your level flowing and working well as a prototype before adding all of the flair, because, after all, what if the level you designed turned out to be crappy and unfun?

With prototypes like these, I can write in a document about what the room is going to be like, design the room design visually, insert them into the game, use them for playtesting, and then once we're satisfied, I can begin the task of making it pretty. (Although I do like to create a small, pretty mockup of each area before I begin. It helps me feel out the atmosphere of the area, as well as block out the colors I'll need later.)

The purple boxes are rooms that are documented, but yet to be designed visually. I typically try to judge their sizes with the purple box, but on occasion the final design is often larger or smaller than anticipated.

Each 'room' has its own PSD file and Text file; I add relevant gameplay notes everywhere I can. Then I flatten the room and paste it to this large map. The giant map is somewhat unwieldy, but it's important to examine the game world as a whole, and to make sure areas are connected appropriately and logically, game-wise.


-Alex

Wednesday, March 28, 2012

Unseen Mechanics in Platformer Games

Very often when you play a game, you usually take several design mechanics for granted.

One, in particular, was something that was discovered and perfected in the NES platformer era, called Mercy Invincibility. The best, and easiest example would probably come from the NES Megaman series.



In Megaman 1, when the player took damage multiple times, consecutively, it meant that he could die at a very rapid pace, without having a chance to correct his behavior. Enemies with rapid attacks were deadly; getting hit and then falling into spikes was a death sentence. Naturally, this was frustrating for the player, as this left very little room for error. (Something already pretty notorious in the Megaman series.)

But in Megaman 2, the designers attempted to fix the problem. When Megaman was hit, his sprite would flash rapidly, and he would have a solid second or two of complete invulnerability. This is called Mercy Invincibility, and it allowed to players to get hit, and then, quickly correct themselves to avoid further attacks. Experienced Megaman players even used Mercy Invincibility to their advantage, allowing themselves to get hit, and then using their temporary invulnerability to walk on the normally-fatal spikes. This greatly increased the ease of play, and lowered the frustration of insta-dying.

But before Megaman 2, even the original Super Mario Bros. had come up with a form of Mercy Invincibility, even though Mario had no health bar and would instantly die if he took any damage as small Mario. After Mario had consumed a mushroom and transformed into Big Mario and then gotten damaged; he would flash several times as he shrunk into small Mario, and more importantly, for a few brief moments, he would become invulnerable to all forms of damage. (Except the all-mighty pits of death.)  If you play or look at a lot of amateur platform games, you can usually see when the creator neglects to add this little caveat of a mechanic, and usually it's an indicator of bad design. There are always exceptions to the rule, though, and sometimes even well-designed games do not have Mercy Invincibility, although they typically become notorious for difficulty, ie: Metal Slug, Contra series.

 (If you want to see a incorrect way to utilize Mercy Invinciblity, check out the hilariously bad PC version of Megaman made in 1990, here.)

As a side note, the idea of Mercy Invinciblity may have been an indirect influence on the Health Regen seen so often in FPS games nowadays. But as the Insomniac dev in the article above explains: most of the time it goes too far; often preventing the game from becoming suspenseful or exciting, which is never a good thing, especially in a combat-oriented FPS. Perhaps a more direct descendant of Mercy Invincibility would be Spawn Protection, protecting players in multiplayer games for a few seconds after they spawn.

Another mechanic that's very common in more well-designed Platform games is something I call Jump Forgiveness. Traditionally, in platform games, you can't jump unless you're standing on something. Obviously, this also has a basis in reality. So, naturally, when you play something, you believe that you're doing what you see below: running and jumping BEFORE you hit the yellow line; the edge of the ledge.




However, if you try coding this in your game, you'll notice that it becomes difficult to jump right at the edge, even if you have good reflexes. Half the time, you'll just end of falling off the ledge and being unable to jump.
I assume that Miyamoto, the designer behind SMB, noticed this problem, and addressed it by doing this:


He allowed the player to jump in midair, if only for a half second of leeway, after walking off a platform. This made it considerably easier to jump from platform to platform, an invaluable thing to have in something as platform-centric as Mario. The amount of leeway you give your player can vary, but generally a half-second to 1 second is the sweet spot.

The most important thing about these mechanics, and others like them, is that they allow the game to flow so smoothly that the Player does not even know that these designs are in place.

-Alex

Sunday, March 18, 2012

Dead Gear Possible Title Screen Art

Was messing around in Photoshop today, wanted to do a quick little piece promoting Dead Gear.




Edit: And just like that we have a new coder and technical director, a Mr. David Gutierrez. It's good to have him on the team.