Jeff Stewart's Design Blog

Late Review: Batman: Arkham City

2012-03-01T13:03:00.001-08:00

Story (9)
First of all let me preface that I am only a cursory Batman fan. I've read the comics only sporadically and although I've seen all the movies, that hardly qualifies one as an expert. That said, the storyline for this game was more than enough to keep you enthralled and moving to the next objective. The characters were introduced well, and every side quest was a wonderful joyride.

The one issue I have with this game is the number of intertwining main stories. This game suffered from the Batman Returns syndrome in my opinion. There were just too many mingled sub plots to provide a clear, concise narrative from beginning to end. Having big bosses like Clayface and Solomon Grundy under the control of your Nemesis was great, but having at least three large-scale evil plots operating at the same time felt messy. (-1)

The Catwoman scenarios were also a tad distracting. They were masterfully done, sexy, and fun to play. They were also a nice break from the game itself. But, I was actually somewhat disappointed to have to keep playing Catwoman after I had finished the Batman storyline. It sounds weird, I know. I think I just didn't want anything to spoil what had been an excellent experience. I was "satisfied" with the game.

Systems (10)
There is no system in this game that is not quintessentially Batman, and everything is expertly done. The Batman can move through the city exactly as you would expect him to. Travel while swinging, gliding, and running is so smooth it puts other games to shame.

While fighting hordes of enemies Batman stays in character whether you are a novice or expert at the game. In a skirmish, combat is basically all about pointing the camera at who you want to attack, and maintaining an awareness of the whole group. The combat can be just challenging enough, and you can really feel the impact of rethinking your strategy, improving your skills, and spending your upgrade points.

The gadget mini-games are also a great example of the superior design of this game. None of them are difficult to win at all, nor are they meant to be a barrier. They are simply there to provide a respite from the normal gameplay and reinforce the gadget-phile and detective aspects of the Dark Knight.

Levels (10)
This franchise has a lot of things going for it when creating a game. That said, the designers show their skill in the implementation. One can be the savior Batman, swooping in to save innocents on the streets. You can be the detective, following evidence trails and solving Riddler's logic puzzles. You can also be the hero, charging in to the heart of darkness to face those pesky arch-nemeses.

The upper city level is a playground, a jungle gym where one can drop in and out of skirmishes at will. This area changes throughout the game, adding enemy types and upgrades to keep you on your toes. There are just enough options for dropping in or sneaking up on your foes that you really get to experiment, rather than being forced into a "do this or die" style level design.

The interiors and subterranean areas are fun to navigate and explore, letting you play as a stealthy predator or a hardened martial artist. There are only a handful of confusing areas in this game, and since using the map is so "in character" for Batman, I can't even subtract points.

Audio (10)
The music is superb. It matches the tempo of the gameplay which has a very natural explore-stealth-fight progression itself. The two really work together to compliment each other. I noticed some new tracks I hadn't heard in any Batman movie or series before, as well as some of my favorites.

The ambient audio is great, and tends to draw your attention to points of interest rather than be distracting. It helps that there is little fauna or ambiance going on in the city besides the elements you should care about like the inmates and helicopters. From time to time you'll scare away birds as your zip-line sinks into the brick near them, or notice your footsteps or dripping sewer water.

The voice acting really takes the prize. Rather than having voice actors phoning in their work, as happens with so many video games, the actors make this game shine. The personality comes through so well in all the characters, from the lowly inmate to the madman himself, the Joker.

Art (10)
Everything in the game embodies the Batman franchise. Of course the architecture, palette, and lighting is spot-on.

The character designs are more than excellent. To work within a franchise is often intimidating, but with a wealth of material and variations the art team managed an original feel without abandoning anything canon. The archenemies are expertly caricatured, the inmates distinguishable yet faceless, and the Batman himself a perfect blend of all the series' takes on the hero from Adam West to Animated Series.

What makes the game more than excellent is the use of camera angles. Like the previous game, the angles are finely tuned to comic panel perfection. Whether Batman is simply walking through a doorway, hanging from a ledge, or using his signature gadgets, the framing of the game screen makes the experience feel like an interactive comic book page.

Wishlist
Any of the Bat-Vehicles would have been fun to play with. I know the story here forbids it, but hey it's a wishlist. I'd also love to explore Wayne Manor and the Bat-Cave. I'd like to scale some taller buildings and infiltrate some nemesis secret lairs. Okay, sounds like a new game! You guys up to the task?

Overall Score (9.8/10)

Freedom to Choose, or "I. Kant Play This!"

2012-02-27T13:57:00.001-08:00

Some games celebrate the choices they give players. Some games are really just toys, a vast sandbox of player choices. Still some offer no real choices other than to participate or stop playing the game.

"If you have free will, turn to page 101. If not, turn to page 101." - Unknown

BioShock
In BioShock, the player encounters a collection of young girls who have been rendered immortal, joined genetically with a regenerative slug from the sea floor.

Upon cornering one of these creepy cuties, the player learns that these slugs contain the genetic material "Adam," the progress points of the game. The choice is given to the player, kill the children or save them? Killing them results in immediate points, saving them results in a few more points at a later time.

The choice that is being presented has almost nothing to do with the one actually put before the player. It is an illusion. The player knows that the collection of animated vertexes before them has no connection to the real world. The girls aren't real, and so there is no natural moral law against harming them.

There are actually two choices here. Both exist and have outcomes in the game world only.

Choice of story arc. Does the player wish to experience the story from the standpoint of murderer or hero?
Choice of reward schedule. Does the player want fewer points now, or more points later? This makes the game a bit preachy, since saving the girls results in more total points in the game.

But what if you consider the choice as a moral one? The illusion of choice surrounding the girls is also integrated into the game as a whole. "A man chooses, a slave obeys." repeats the city's founder, as you beat him to a pulp (probably after choosing to save the girls).

Philosopher Immanuel Kant concluded that the only objective basis for moral value is the "rationality of the good will, expressed in recognition of moral duty." In other words, a person can only act in "free will" if they are acting out of duty (a law they have given themselves) and not in response to their situation.

According to Kant (and from a meta-game standpoint), the player who reacts directly to stimulus, by taking upgrade points, may be considered a slave. The player who applies his own "real-world" morality to the game world (which has no intrinsic morality) could be exercising free will.

The choice in this game received a lot of flack for being once of those classic gaming black and white choices. The irony here is that, according to Kant, only players who chose the "obvious" route of not killing children (even in a morality-free environment) seem to be displaying free will. All the rest of us are child killing slaves.

"We must believe in free will, we have no choice." - Isaac B. Singer

Even when we discover (thank you spoilers) that more points total may be gleaned by not killing the children, we can load a saved game and reverse our decision, thereby proving again that our decisions were never based on a moral duty, and we're in it purely for the points.

Mass Effect
The Mass Effect series has a certain dichotomy to it. In the first Mass Effect, there exist similar choices to the choice in BioShock. Many situations require you to make (virtual) life or death choices for the in-game characters. One of the most notable being responsible for either the salvation or genocide of an entire race.

But Mass Effect 2 is somewhat different. All, or at least most, of your choices revolve around you as a leader. By acting as leader, you are responsible for the situations you place others in. The bulk of your choices stem from diligence and duty. Not many games let you experience this element of leadership.

Part of your duty is to upgrade your ship and gain the loyalty of the crew, in an effort to ensure the maximum safety of everyone. Failing to to do so dooms one or more of your crew mates to death. Upon a second play-through, you have begun to achieve some level of prescience. You know that laziness or failure is not an option.

While the ignorance of a first play-through of the game absolves you of the "meta-moral" ramifications of some of these choices, playing the game repeatedly raises the "meta-morality" bar.

The philosopher Kant would have us consider categorical vs hypothetical imperatives. Namely, that you cannot judge the morality of an action based on its hypothetical effect. For an action to be moral, it must be made by duty without regard to its effects.

In other words, when you replay the game (with a theory of what might happen based on the previous play-through) in an effort to better perform your duties as leader, your imperative is hypothetical. Your moral duty is usurped by your desire to achieve a better outcome. You are not exercising free will, you are being a slave to optimization.

“I wear the chain I forged in life....I made it link by link, and yard by yard; I girded it on of my own free will, and of my own free will I wore it.” - Charles Dickens

Using a walk-through or having knowledge of what will happen also robs your actions of weight. So although they could be perfectly reasonable, and therefore perfectly moral, they are valueless. The only way you can really win, morally, is to have played and won the first time through.

Late Review: The Elder Scrolls V: Skyrim

2012-02-24T10:58:00.000-08:00

Story (8)
The main story was unremarkable but decent. A self-fulfilling prophecy causes dragons to be brought back to life, and only a prophetic hero can end the scourge by killing the master dragon. Some of the ideas like time travel and trips to Valhalla didn't seem necessary. I would have rather defeated the dragon through non-supernatural means. It felt like a lot of overly fanciful ideas tacked on to a fairly straightforward tale. (-1)

I particularly enjoyed the diplomacy table sequence, although I wish my decisions had a bit more impact. This was an excellent opportunity to let the player craft their experience for the rest of the game by choosing magical solutions to defeat the dragons, straightforward military attacks, or stealthy secret missions. (-1)

The guild stories and missions were great. Each had an awesome plot that transitioned you from FNG to guild leader in a believable way. The characters and scenes were memorable, and these stories were often better than the main quest line, if only because they were shorter and more digestible.

Systems (4)
Skyrim, like Oblivion, seems most easily played as a stealth archer with a backup short sword. I tried to be a war hammer wielding beefcake, but the enemy variety made that choice difficult. Shouts are a fun idea, and collecting them was fun as well. The problem with these is that only a couple of them are really useful, which is the same problem I have with the spell system.

The level up screen is much more intuitive and better presented. The interface is beautiful. (+1)

I really like the idea of cooking, alchemy, smithing, etc. but the the implementation is too simplistic. If the developers spent a bit more time on these systems instead of making them simply item transmutations, they would have been much more interesting. Also, why must I have to be a master smithy to do anything interesting? (-1)

I just loathe the sheer amount of components, foods, etc. There's no elegance to it at all. I could spend all day collecting and tasting new ingredients and never really discover anything worth crafting. Sometimes a flower should just be a flower. (-1)

Killing miniboss dragons is fun, although the implementation could use some work The dragons are too squishy, and even though they are slightly different, they all felt the same. I also had dragons just disappear mid-battle. (-1)

About 1 out of every 5 quests I tried to complete had some sort of bug with it. Some of these I could find workarounds for, but there were some that I had to enter developer cheat codes to complete. (-1) The huntress Aela kept sending me to kill creatures that were already dead. (-1) Oh, and the Markarth bug. (-1)

For all the hype, Werewolves were dumb. Finally I get to be a bloodthirsty bad-ass and the game throws me into a quest line with guys wielding silver weapons. I've never felt so awesome only to be slapped back down to earth. (-1)

Levels (8)
All in all, the level design is an improvement as well. The terrain is fairly easy to navigate, the one exception being mountains. With mountain areas, sometimes you can scale the mountain to save time, but it's never apparent. I would like to have more of a hard collision boundary here. It gets worse the higher the mountains get. (-1)

Dungeons tend to form a loop and return you to the start. Each one has it's own progression, with bosses hanging around the end. There isn't a great deal of repetition in the designs or look and feel. Each one has it's own unique story, and the designers made more use of physics traps. Well done.

Then there are the cities. The larger ones tend to be tougher to navigate easily. Windhelm is a maze of the same texture, Markarth is also bit of an over-under maze, and Solitude forces you into a dead-end. These are minor issues, though they often make tracking quest beacons difficult. (-1)

Audio (9)
The music was excellent. Transitions were smooth and effects were well sampled. The effects and stings peaked at all the right times.

The ambient sounds in the cities and forests were nice. Nothing felt out of place. The game still suffers from way-too-stealthy monsters. Just once I'd like to hear a monster coming at me instead of being attacked without warning. (-1)

The voice overs were on par with the last game, if not a little better. There were still several areas where either multiple actors voiced the same character or the actor had an off-day. And it was hard not to notice everyone getting shot in the knee.

Art (8)
Here you have a remarkable improvement from the previous game. The models are better proportioned, and have more realistic animations. The textures are more gritty and battle-worn. The concepts for some of the creatures were particularly original, with my personal favorites being the Hagraven and the Giant.

The environments are also a remarkable improvement. The map is littered with interesting places like geysers and mineral flats, swamps and whitewater rapids, or frozen wastes. The fauna and inhabitants fit the areas well and create a believable world.

The underground areas and dungeons were also much more interesting. One exception being the Dwemer ruins. While very cool in their own Wizard of Oz way, they felt tacked-on. Having the orcs, or Falmer, inhabiting them was also extremely uninspired. (-1)

The areas that spoil this winning streak are the cities. Each city layout is unique, and most are well executed. There are a couple issues that spoil this for me. Some cities seems to have been very heavily influenced by Lord of the Rings. Markarth is very Gondor and Whiterun is practically a copy of Rohan from the movies. Windhelm was just plain ugly, confusing, and uninteresting. (-1)

Wishlist
I never slept once except to trigger a quest line. I never ate, with the exception of clearing my inventory. I carried around potions that I never used and collected ingredients that I abandoned upon discovering how useless they were. There are just a lot of systems that are carry-overs from other games, and exist here as incomplete ideas.

I guess I wish that sleeping and cooking could serve as a end and beginning to each day, a way of invoking the mundane times of a quest in order to heighten the more epic elements. I wish potions were interesting, and not just as plentiful as calipers. I wish I had to work a little harder, or be a little sneakier to get those potion ingredients, and that the potion was actually worth the effort.

I steal an apple by mistake and the omniscient thief police alert every guard and shopkeeper. Why does this series handle theft in such a way? It's silly, and anti-fun.

Overall Score (7.4/10)

Extreme Loss Scenarios

2012-02-23T14:59:00.000-08:00

What Are You Talking About?

Extreme Loss Scenario is a term I coined to describe those hateful situations you find yourself in as a gamer where mountains of work are lost in an instant. A scenario in which you experience "extreme loss" could be as simple as a bottomless pit, as premeditated as distantly spaced save points, or as integrated as a spreading fire mechanic.

In multiplayer games they can leave seasoned players giddy while making newbies cry. In single player, they can cause total frustration and cause players to walk away. They are scenarios that punish players with significant loss of time or resources, often for the smallest of mistakes. They are also some of the most memorable game experiences.

Surprise! You're Dead.

It usually doesn't happen in real life. But in games, it can happen to anyone at any time. Instant death in games can be a great tool for evoking tension, but often it is a hastily implemented wall to scare players into submission to the "normal" mode of play.

"In Super Mario Brothers, you begin with a problem. You must move to the right or time will run out. If you move to the right, you get another problem. You must jump over (or on) the Goomba or you will die. If you die, you begin again (minus a token for an additional chance at the game)."

I don't consider this an example of an extreme loss scenario, because you are warned repeatedly (although via trial and error) of the risks and rewards. You will lose lives until you learn the fundamental rules of the game, but you are presented with this information early and consistently. Even bottomless pits are acceptable here. Because you don't invest large amounts of time into customizing Mario's appearance, stats, or weapons, it's okay to kill him repeatedly. The main "meter" you watch is "lives," As the lives count down, you know you're in trouble.

In Dungeons and Dragons based CRPGs, you often find yourself encountering traps and trapped chests. If you have invested your experience winnings in trap skills, you will no doubt be detecting these traps as well as disarming them. If you haven't, you will be in for a surprise. Consider:

"You've just finished killing the boss monster and you're low on health. Surely one of the many chests lying about the room has something to help you. It does, but (unbeknownst to you) it was protected with a flame trap and now you have no option but to watch yourself burn to death."

Sure, you could have hired that thief mercenary and stocked up on flame resistant armor or potions of firebrand but now it's too late. You're dead because you clicked on something you shouldn't have.

So what's the problem, you might ask? That's what games are, right? After all, life throws unexpected problems at you all day long. Games are a simplified reflection of life. Right? Deal with it, noob. Less QQ more Pew Pew.

Games are also increasingly a form of escapism. They are a tool for learning new ideas and experiences. The emerging number of options one has for experiencing games places the burden on developers to make their games pleasurable, frustration-free experiences. Extreme Loss Scenarios tend to exhibit one or more of the following:

Confusion: Completely unexpected requirements for progression
Surprise: Limited or no recovery time
Anger: Inevitable loss of progress and investment
Loss of Control: A forced situation, uninitiated by the player

Is it fair to expect behavior that hasn't been conditioned, or introduced in a tutorial? For a developer, the act of punishing behavior that isn't conditioned is a kind of psychological "attack" on the player, a form of meta-game challenge, a way of saying "hey player, expect the unexpected." This causes panic, and although it can be an easy way to create tension in a survival horror game, it often promotes abandonment of the game altogether.

Learn by Dying

Some game situations seem to be created around the idea that a player should consistently lose progress until they comply. In single player games, these scenarios provide extreme frustration.

Temporary blocks over a pit of death in Megaman games, or non-collidable blocks in Castlevania II:: If you have prior knowledge of the order and placement of these blocks, these sequences are approachable, otherwise you're screwed.
The Creeper in Minecraft: Hissssss. You have mere seconds to run away before all of your items become lost in the wilderness and you find yourself respawned.
No Auto-Save in Old Adventure Games: You're immersed in the story, and you're making some real progress. Then you accidentally walk off a cliff. You are dead. The last twenty minutes were wasted. Did you learn anything? You should have learned not to be immersed in a game, to be constantly aware of having to save your progress.

Some game actions give players a great deal of power over other players. In these situations, all players have the potential to wield the power, and so although frustrating at times, the balance remains fundamentally fair. Both players accept the fact that the challenge will be emerging from another conscious entity, bent on your complete physical and psychological destruction by any means necessary, often including cheating.

Thieves in MMORPGs like Ultima Online. Certain evolutions within the game rules, like nested numbered bags, emerged to counter this.
Snipers in FPS games like Counter-Strike. Who enjoys sniping? Only the sniper. The other player has no warning, and has no gameplay options besides burning the midnight oil to memorize the map.
Superweapons in RTS games like Command and Conquer: Generals. Although most multiplayer games don't reach the superweapon stage, these attacks escalate trading blows to the point of erasing a game's worth of work in an instant.

The interesting twist in a multiplayer setting is that all of the anguish and rage of one player is magically converted to elation and given to the other player. These actions are so one-sided, they tend to stop the game for newer players rather than encouraging one to keep playing.

What's A Dev To Do?

From a game design standpoint, these Extreme Loss Scenarios can manufacture dissent and dissatisfaction with the game. On the other hand, these actions could potentially serve as a way to whittle the player base down to a hardcore few, increasing loyalty. Be aware of your intent and the power you wield.

Know what your game is really about, and focus on that. Why train players on the subtle decisions and then present them with a "do this or die" mechanic, simply because a programmer could implement it easily?
Design games that provide more gameplay on death, instead of less. In Planescape: Torment, the player is immortal, and after dying wakes up in a morgue, often unlocking new parts of the game.
Auto-Save! Increase the number of save points! By respecting the time that players invest in your game, you as a developer are telling them that you respect them, the player, as an individual.

The contrary opinions, that harsh punishments for mistakes are a signature of games, tend to come from personalities that remind me of old men on front porches.

"In my day, we would grind mining skills in 16 hour shifts, only to have our entire inventory pick-pocketed while we waited for the market zone player limit to clear, so we could sell what was left. And that's the way we liked it!"

In games, we have the power to give people experiences that real life doesn't. We can build systems that encourage ingenuity rather than enforce compliance. We can induce fear, or we can explore without fear.

"...I'm going to show these people what you don't want them to see. I'm going to show them a world … without you. A world without rules and controls, without borders or boundaries; a world where anything is possible. Where we go from there is a choice I leave to you." - Neo

Late Review: Deus Ex: Human Revolution

2011-10-30T15:09:00.000-07:00

Story (9)
You, Adam Jensen, an investigative, security specialist, ex-cop has every motive to pry into the happenings around the company you work for. Just in case that wasn't enough, they "got your girfriend." Just when you thought the cliche's had moved out of town. (-1)

Overall, the story was better than most game stories. It was a full of flip flops and twists and was interesting enough. The dialogue could have been better, but the characters were at best interesting and at least distinguishable.

The game treats you like a spoiled child, answering every "aha" moment at the end of an act with a "wake up and smell the roses" lecture from a major character. It doesn't get old though, and helps to keep widening the possibilities for conspiracy, which is the central theme of the game.

Systems (7)
Most of the gameplay was preserved and translated well from the prequels. You had patrolling guards, trip mines, lasers, hacking, guns, and crawling through ventilation shafts. And of course, boss battles?

Seriously, those boss battles were bad. They wrecked the RPG portion of the game, making it extremely difficult for stealth characters to play without cheesing. On top of that they were just not fun. Basically all of them involve waiting for the stealthed boss to reveal himself. (-3)

Gun battles were fairly fun. And of course this game has sticky cover, that "me too" two-dimensional mechanic crammed into every modern 3D FPS game. I'm actually a fan of sticky cover games, they tend to make FPS games more equitable. It's just that DE:HR didn't need this mechanic.

The conversation system was nice. The focus on reading into context clues made the choices meaningful. It was a subtle but noticeable difference from a lot of RPG dialogue trees. Some of the dialogue felt forced but the heart to heart scenes brought personality to your character. (+1)

Here's a pro-tip: Pick your two or three favorite guns for the game and drop the rest of them. As you upgrade certain weapons you'll want to keep them, and it gets harder to do that. Obsessive collectors like me find this lack of inventory space annoying. The game would have done better to simply limit the number of guns I could carry. (-1)

Levels (7)
Spaces are confusing at first, especially cities. You'll find yourself checking the map a lot until you get to China, where you'll be elated to find signs. Signs! Thank you, level designer, for at least correcting your confusing layouts with colored arrows. (-2)

Mission objectives were tried and true, nothing new there. At least side quests were confined to their specific areas. The overall progression was fairly nice as well, with the areas becoming more and more dangerous as you progress. You get to have some freedom in an area without the ill effects of leaving unfinished business everywhere.

Levels eventually became more and more combat focused, though. It became harder to find tranqualizer darts. There was also too much box stacking, which admittedly is a carry-over, but not necessarily in the spirit of the game. (-1)

Audio (9)
The music was good. It had a Matrix feel during the story moments. The transition system worked well, with flawless transitions between tracks.

Sound effects were not particularly innovative, so no Star Wars level effects here. However, they were well sampled and presented. (-1)

Art (8)
Why depart from the original look so much? My guess is that they wanted to introduce a "human" element. Create a sense of reality with the antique furniture, futuristic victorian fashions, and street trash that would contrast the steel and mechanics of the cybernetics.

A good notion, and well executed, but not original at all. Blade Runner called. They wanted their entire aesthetic back. Maybe if the game hadn't taken you to China... (-2)

Animations were good, although there were some glitches. Facial animations were mediocre, as they are in every game and most likely will be for some time to come. To my knowledge, only Valve Software has proven that facial animation can be done well with current technology.

Use of yellow outlining to denote interactables was welcome. Since the game is so dark, you are likely to miss stuff. I would have enjoyed some kind of effect (ala Terminator visual readouts) that drew my attention to these elements as they came on screen.

Wishlist
I wanted to hack enemies. If your mechanical cronies are sleeping on the job I should be able to convert them to mercenaries, or at least disable them.

I wanted to replace my limbs rather than my weapons. I want to put Skeletor arms on my He-Man. I saw enemies with goat legs. I want mechanical goat legs. No fair.

Overall Score (8/10)

Go Play This: Indie Games!

2011-10-24T06:43:00.000-07:00

I love indie games because they tend to come from a passionate few instead of an industrially empowered large. Because of that they can get away with innovative ideas that would make project planners cringe and marketing departments scratch their heads.

Here are 5 of my favorite Indie games, chosen because of their replayability value. There are definitely some interesting newer indie games out there, but these have that "special sauce." These are games you'll break out again and again.

Minecraft
It had to be first on the list. Everyone either is rabidly in love with this game or is wondering what all the fuss is about. If you're the type that got Legos for Christmas and stopped playing after you completed the steps in the manual, then this game may not be for you.

Minecraft is a game about mining and crafting. That's it, really. Just know that 15 million people are playing the beta, and the game has had no apparent marketing campaign other than a grassroots fanfare of YouTube videos.

A lot of people overlook the wonderful multiplayer potential of this game. In addition to simply hosting a server for friends, there are many communities with mods for economies and real estate. Being part of a group building project is a real blast, and the Rube Goldberg machine-type interactions lead to emergent innovation. Not many games can make that claim.

Spelunky
This game is a side scrolling platformer with random terrain generation. In it you play a cute little explorer with a whip, ropes, and bombs. The game is pretty tough to play without a controller. It recently got ported to XBox Live Arcade.

The charm of this game is in the randomization. Each level has a girl that you have to save, and often there are elaborate traps like boulders and lava pits. If you play far enough and die enough, you can begin to pay money to save your progress.

Iji
Iji is a side scrolling platform game with an RPG style skill system. Investing points in certain skills denies you access to certain areas, weapons, and abilities, etc. The entire game was apparently developed by one guy. Finally some love for a Game-Maker game!

What I love about this game is that it "feels" like an indie game. There is a likeable crudeness to the game in the graphics and story, yet at the same time, there is diligent attention to detail. You can sense that this game was loved.

Strange Adventures In Infinite Space and Weird Worlds: Return to Infinite Space
Coffee break-length 4X game impossible you say? The mighty Klakar would squawk at that notion. Because of the short length of these games, they are much better appreciated when played multiple times. Both are turn based, but there are some action parts during combat.

Strange Adventures and it's sequel Weird Worlds are odd puzzle games about exploring the universe while bartering, collecting, and delivering cargo while staying alive. The games have masterful audio and art. The levels are randomly shuffled, and there's a chance you'll get a rare doomsday invasion scenario.

The Enchanted Cave
Rarely does an RPG stat grinder come along that someone like me gets hooked. As a designer, I know which mechanics to expect. The Enchanted Cave isn't particularly innovative, just surprisingly deep and well presented. You won't finish it the first time, or the second. It's the puzzle aspect layer of the game, finding the treasure items and stat modifiers, that creates the addiction.

Movement is from the keyboard, while inventory interactions use the mouse. To use a spell during battle, drag it from the sidebar onto your character during each round. It's weird but somehow I got used to it. Took me a week of lunch breaks to beat it.

Adventure Design: Space Quest 0

2011-10-20T07:01:00.000-07:00

Design Objective:
Create a fangame for one of my most beloved series, Space Quest.

Obstacles:

Must be up to par with the originals
Develop using Adventure Game Interpreter with parser interface
Can't succumb to dead end situations pervasive in early adventure games

Design Thoughts:
I wanted to use AGI simply out of nostalgia. These were the games I grew up on, and I loved the freedom of the trial and error parser interface.

I also love the art. It's blocky and it's hard to discern detail. But it helps create focus on what matters, like where to go next, what to pick up, etc. If you're pixel hunting, you've only got 160x200 pixels to sift through. It also forces you to be cartoony with your elements if you want them to be readable. There are optical illusions that are created with large blocks of color that are at your disposal as well.

Process:

I began designing this game with a list of all my favorite adventure game moments, and some new ones I wanted to try. There was also a list of concepts I loved from the original Space Quest games:

Character movement puzzles, like the root monster from SQ2
Optional exploration points and multiple paths points
Deaths. I accept that it's evil game design. I still want lots of deaths.

When designing the puzzles, I wanted to be nostalgic with a twist. That seemed like the best choice for a "pre-sequel" homage game. That's why there's an escape pod sequence, a crash landing with a surprise, and a distract the guard puzzle.

The background art for the game began as simple sketches, just to get the blocking right. Next, using a tool called PICEDIT, I created the in-game resource. This was done using an antiquated line-drawing, pixel placing, geometry filling method that was honestly just too fun. AGI backgrounds basically have a "depth" or "Z" value for each pixel, so that when you place a pixel on the screen, a second layer determines the draw order. That's what creates the "magical illusion of 3D."

Creating sound for the game was a bit of a pain. I didn't want to blatantly steal any sounds or artwork, and because of that I had to create sounds using a clumsy command line tool that converted them from MIDI to the in-game resource. Some sounds and music were simple, but most of my efforts at making MIDI files and converting them failed.

Scripting the game was fairly straightforward. The editor I used, AGI Studio, had a C-like proprietary language. The one gotcha was memory, this antiquated engine only allowed 255 variables and 255 booleans, or flags. It actually wasn't that hard to work within that space.

Reception:
Just Adventure (4 Golden Mops) - "If Jeff Stewart had released his game to the general public, say, between Space Quests II and III, I don't think anyone would have realized it wasn't an official Sierra product."
Reloaded (4.5/5.0) - "Good puzzles, true to the original, and interesting plot."
Space Quest Omnipedia (80%, truly a great game.) - "The puzzles in this game get an A."
Home of the Underdogs (Two Thumbs Up, Way Up!) - "What makes Space Quest 0 much better than your average amateur games is the variety of puzzles, none of which particularly difficult, but all are logical and fun to solve."

Download Space Quest 0: Replicated

Walkthrough

Hindsight:
There were several concepts that I didn't put in the game simple because I was "done" with it (getting busy at work again). I had a platformer game planned called "Super Pinkun Brothers" and an asteroids-style shooting game for the space travel portions of the game. Including those sequences would have rounded out the game nicely.

The plot for the game could have been much, much better. I'm a better writer than that, and I honestly just did a once-over writing job to tie the puzzle elements together. Although people didn't seem to mind too much, I know that better writing would have made this game stand out.

Postmortem: Cruise Time

2011-10-18T16:44:00.000-07:00

Cruise Time was/is a social network game I helped develop for Facebook. It was published and funded by A Little Entertainment in Houston, TX. During the development of the project I acted as Designer, Project Planner, and Producer. This article is an attempt to demonstrate some of the mistakes I made as a rookie Producer, as well as demonstrate some of the frustrations of the fast-paced social gaming space startup.

A Little Entertainment was busy "finishing up" their RPG dungeon building game called Doors 2 Adventure. Although the game was late, we were developing our own database and server framework. We had funding and were on the lookout to acquire additional teams.

The president decided to position us as a publisher. We had:

Some experience with micro transactions through PayPal.
Developed some rudimentary tools for Customer Service.
An experienced marketing person with a budding relationship with Facebook.

Phase I

Four of us started the creative core of the Cruise Time project. The plan was to develop a working game within 3-4 months, and in doing so, gain a better sense of the additional resources we would need to launch the complete game within 6-7 months.

Design
Cruise Time was an attempt to put a new, more widely appealing face on a proven type of game. The plan, largely, was to build a game similar to Hotel City, but with a strong focus on avatar customization. The first design was focused on the player's avatar and the status symbols they would collect when traveling the world.

The theme was lighthearted, playful, and exotic. The backgrounds would change, the characters would be more animated than most Facebook games, and players would explore the world. The corporate tie-ins were limitless and the pitch was an absolute success.

Engineering
I had estimated that we needed two full time engineers for the client, as well as the help of our database engineer, who would help connect the client to the live database at regular milestones for testing. We conducted some initial framerate and technical tests, then drafted the plan.

The previous engine had been Java-based, and development was being handled by one engineer. It was absolutely inflexible and far too time consuming. We needed to be able to iterate quickly, not only during the project, but after launch as well. We chose the obvious, which was Flash, for our development environment.

The results:

The first milestones came slightly slower than expected
Flash has a myriad of bugs and inefficiencies and no animation tools
Using source control software to with Flash files was a nightmare

The slow progress didn't bother me much because we were only barely missing milestones with half of our expected engineering team. We were running ads for a second engineer. The database engineer was a shared asset, although he was usually busy. His plans for client integration with the server looked good, and we decided to wait until we had a bit more of the client developed to begin integration.

Art
I had seen many problems with creating art in-house, namely that it was expensive and time consuming. I did a cost per monetized unit evaluation of the previous game, and decided that without a doubt we needed to outsource, both to lower costs and to avoid altogether the various hiring problems we had been experiencing.

The plan was to:

Develop the artistic style of the game in-house, outsource the rest
Create a working demo which needed one of each asset type
Investigate the feasibility of additional outsourcing of animations

The animations portion of the project was falling behind as well. However, our animator was helping build the engineering portion of the animation system. Without the ability to hire, forging ahead seemed like the best solution to the problem at the time. Animations seemed like something we could outsource.

Phase II

ALE Games first title, Doors 2 Adventure, was now several months past schedule. Its main engineer (our database engineer) was working from home exclusively, completely cut off from our project. The content production schedule for Doors was in disarray. A few junior artists were hired to help out. Hiring for Cruise Time was frozen.

Contrastingly, our project seemed to be progressing at a predictable pace. Our small team had created a working demo. The art style had gained traction, and several of our technical hurdles had been overcome. Members of the team were excited to be on the project.

The vision for the project was solidified. We felt like winners. Lonely Island's "I'm on a Boat" would sporadically erupt near the end of the day.

Facebook announced grievous new restrictions on viral posts, which forced some redesign.

Design
The game as originally envisioned, didn't seem to be what people expected. As I would start to explain the game, people would interrupt with their own ideas, and the ideas were surprisingly similar. People didn't want to be millionaires and own their own yacht. They wanted to be Captains and own their own cruise ships.

So, I redesigned the game from this perspective. I dropped the emphasis on the avatar, as well as several wishlist components of the game as it became obvious that we couldn't reach our goals without additional engineering. The game became a simulation about ferrying passengers between world ports and keeping them happy. I also developed several new viral mechanics to help counteract the Facebook restrictions.

Engineering
The game was becoming more and more interactive, but due to the non-involvement of the database engineer it was merely a shell. That meant the client was also now behind schedule. It had a facade of functionality, which allowed us to begin polishing the interface and playing the game.

We petitioned for the hire of additional engineering help. Damn the excuses.

We could certainly not continue at this pace.
We couldn't stop. Everyone genuinely believed we had a successful product.
The only way to continue was to hire without the consent of the Director of Technology.

We placed ads.

Art
Over the course of a few iterations, the characters and style were becoming clear, and this was all that was needed to begin outsourcing the bulk of the content. The studio we chose for outsourcing used a web-based system that allowed tracking of each comment and change.

Animations were behind schedule. Hiring was frozen. Outsourcing of animations wasn't looking feasible. I began looking for a range of solutions involving training transplants from within the studio to cutting large portions of the animation content.

Outsourcing had a few minor bumps but was the least stressful portion of the project by far. We worked with a team in Austin who contributed well to the creative side of the project and came through just in time.

Phase III

The engineer for Doors 2 Adventure (our database engineer) unexpectedly left the company. When he left, he took the source code for Doors and the server with him. Although this initially created a shock, many on the team rallied to fill the void.

We lost marketing altogether due to internal squabbling, and with it our ability to remain in constant contact with Facebook. If a change was happening, we found out about it on the internet like everyone else.

We lost more people, some of which really needed to go sooner. With this "transition" we lost testing and customer service. The company now had no advertising expertise. I began my job search, but I had faith the game I was working on would be successful if we could finish it.

Design
The game data had been entered, and I had begun balance passes. Since a large portion of the game was still undeveloped and disconnected from the database, we were losing precious design iteration time.

For the first time in my life, I was a Designer pressuring engineering to finish the game so I could balance it. As a Project Planner I knew that engineering was doing all they could. As a Producer I was angry that all of this turmoil had conspired against our creation in such a short period of time.

Engineering
Our contract IT person was hired full time, and repaired the damage enough that we could at least upload content for Doors 2 Adventure. This IT savior became our new server engineer, working with our client engineer to connect us to the cloud. This dynamic duo was promising, but it meant that we now had even less client development going on.

Our "shared" PayPal system was also in Java, which meant without a Java developer we didn't have one anymore. We had to find a Java Developer, write a new one, or use a third party service. We found a third party service that had been field tested and endorsed by several competitors.

The game was now officially late.

Finally, we were able to hire some additional engineers. They were dedicated and wonderful guys, and began bringing the game up to speed. We finally got our tutorial system working.

Art
Our animator left, but the junior artist hires turned out to be rock stars. They were able to complete the animation assets in the space of a couple of months, and were pivotal in testing and feedback.

Our lead artist and web designer were putting a great face on the game.

Phase Out

We had investors drop out after the debacle surrounding the first game. The notion of "soft launching" the game to pacify an increasingly interested board of directors came up. I kicked and screamed like a baby. It happened anyway.

The initial numbers were not bad. The game spread virally without marketing and people were buying in-game items. We prioritized the remaining mechanics and began working on them. We bought ourselves some time. Everyone was hopefully watching the metrics scroll by on a game that wasn't complete. Inside, I was boiling.

Our third party monetization service was a sham, so we tried another one, which was also a sham. They frequently charged more than was stated in the contract. Facebook credits was simple and easy to hook up, and ultimately charged less money (30%) than the third party services (34-50%).

In order to get more investment money to finish the game, the board wanted more games. We began work on a spin-off game using the same engine. It wasn't enough. The company went out of business.

What I Learned

The process of transitioning from a Designer to a Producer was very beneficial to me. As a Designer, I learned:

That small startups are even more volatile than I had expected. In my experience, it was usually the closely knit, rock star team that had done all the real work anyway. Why not just dispense with the bottom 90%? Insurance, that's why.
To be more mindful of the cost ramifications of mechanics. Systems that produce large amounts of emergence are likely to produce similar amounts of work.
Waterfall is elitism when it comes to game development. I'd been revising my own ideas on development for years. Unwittingly, I found myself validated by Agile concepts.
"Fail faster and follow the fun!" was a phrase picked up at a social conference. I found it disturbingly true at every stage of development, from the initial pitch to the final launch.

As a rookie Producer, I learned that:

Ownership is an effective tool. Empowering people to set their own goals and work estimates for the project causes them to spend time assessing their responsibilities. Remind and encourage instead of micromanaging.
Taking time to create advocates fosters momentum. When someone disagrees with you, it needs to be acknowledged and reasoned with. Unchallengeable power is tyranny, despite it's intentions. People often make the same choices you do given the same information.
Take responsibility. Give credit. Admit when you're wrong and distribute praise to the people that deserve it. We had great people who did all they could despite adversity.

Go Play This: Board Games!

2011-10-17T15:18:00.000-07:00

Here's 5 of my favorite board games. Of course, if you're a board game geek, you probably own all of these anyway. If you don't, come see what all the uncool kids have been doing!

Carcassone
Players build a medieval landscape by matching tiles and scoring completed patterns. By far my favorite board game of all time, it is both extremely easy to learn and highly replayable. The River expansion is a must if you consistently play with the max number of players.

Of the expansions I have played, some add a great deal to the game:

Inns and Cathedrals - An extra player's worth of tokens, the "big man" and double scoring tiles. Adds tons of fun to the game.
The Tower - Adds tower foundations and comes with a handy tile organizer. In my opinion, the tower mechanic as designed is too painful to be fun.
Cult, Siege, and Creativity - Don't bother with this one. The cults are rarely used offensively, and the sieges, although a nice balance to the Inns and Cathedrals pack, create more groans than giggles.

There are a few house rules that friends and I have developed and thoroughly tested for this game:

Ignore farms. They drag the end game out and cause huge swings in scoring.
Hands of three. At the beginning of the game, draw three tiles. Upon playing one, draw another. This allows you some turn by turn strategy that makes the game exponentially better.

Settlers of Catan
Players compete for dominance with expansion of settlements, roads, resources and trade routes. This one is probably one of the worthy first in a long needed revival of board gaming since games like Monopoly monopolized the space. (See what I did there?)

There is a bit of debate on the fairness in this game due to a high random rewards factor. Players effectively choose their starting income probability by turn order, leading to a possible dominance of leading players. You can counter this somewhat designing your starting board layout instead of shuffling it. Space out the good numbers (6s and 8s) so that they are harder to connect with roads.

There is still a great amount of strategy to the game, especially with a group of hagglers. The only downsides are the excessive card shuffling, which can feel tedious after a few successive games.

Settlers of America
Players work to found settlements, claim resources, and enough build supply routes to conquer the industrial revolution. As the game progresses, the active board moves to the left, in a manifest destiny bid for control. This spin-off of the original adds a very interesting twist, and solves some of the random rewards issues associated with the original.

There are some new mechanics that make this game more strategically fair than Settlers of Catan:

First, you can only create supply routes to your adversaries settlements, so gaining ground can have unintended consequences.
Second, the earned gold adds another dimension to haggling and resource rewards, softening the blow of leading players.
Third, the advancing game board lets you dislodge the leading positions, and also adds a nice narrative to the game.

I love the multiple step bid for control in Settlers of America, although it is very much intended for those who have already been introduced to the original Settlers of Catan.

Stone Age
Player's tribes compete for resources and growth potential using procreation, farming, hunting, and natural resource collection. There are multiple strategies to the game, but ultimately he who has the most tools wins.

Overuse of the "Zug- Zug Hut" (as we call it) can come back to "bite" you if you don't watch your food consumption. Also complete buyouts of a resource also leave one open to be locked out by their rivals. The chits are fun to play with, too.

The scoring indicators are a bit misleading, showing people as an indicator of the points you will receive. Since you use people as chits, it's a bit confusing at first.

For a game about cavemen, the real game is surprisingly about outwitting your competition, getting inside their plans for cave domination and making them go horribly awry.

Power Grid
Each player's company tries to create the largest power grid, bidding on power plants and energy resources. Although may sound like a uninteresting theme for a board game, this game is anything but boring.

There are a few things that I found odd about the game, but that certainly don't count against it.

The game has less focus on resource bidding than I would have expected. Only a few games have really ended with a buyout of the resources market as a viable strategy for preventing a win.
The best free energy power plant in the game is almost impossible to acquire. When it finally does emerge, it is rarely purchased. This could be subversive social commentary for all I know.
Oil chits are black, and coal chits are brown. I know they had to distinguish these same colored resources, but you'll find yourself arguing about it anyway.

Despite these nit-picky grievances, I'm sure you'll find this game worked into a regular rotation.

Software Development Processes

2011-10-10T09:41:00.000-07:00

Which Software Development Process Should I Use?

What Are My Options?
In this post I'm going to discuss the highlights of the Waterfall, Agile, and Cabal software development processes.

"Do it right the first time." The Waterfall Method is a model for game development which was adapted from other, more rigid industries where iteration was so expensive as to be impossible. Waterfall relies on the knowledge of the designers and producers to build a fool proof plan on which to execute. In the Waterfall Method, development is seen as flowing steadily downward, like a waterfall, from design to implementation to testing.

"Plan to do well, then fix your mistakes." Agile development is a model based on iterative and staged development, where tasks and solutions evolve through collaboration. Agile promotes adaptation, acknowledging that previously planned solutions may prove insufficient. In the Agile Method, time is allotted for multiple, iterative "re-evaluations" in order to prioritize the primary objectives..

"Leave the planning to people who build it." The Cabal Process has been popularized by companies like Valve. The Cabal is a small, multi-disciplined team assigned to a portion of the project. It starts with a top-level Cabal, or "creative core" of more experienced team members and then segments into multiple mini-Cabals which work simultaneously. Often multiple people may edit the same portion of the game, and therefore consistency, modularization, and knowledge sharing tend to increase.

What Are the Pros and Cons?

In a Waterfall system, the game idea is usually originated by a design-heavy committee, then implemented by art and code. This has some advantages:

Designers tend to be advocates for gameplay and the user experience.
Having a single point of accountability for design improves communication.
Having a big picture plan makes it easier for project planners to schedule.

However, the Waterfall Method is arrogant, in that it assumes that the designer and producer know absolutely everything. Not only that, it's extremely risky. Teams often mitigate this problem with a "design by committee" approach, but this tends to dilute the game idea. In my experience, most teams seem to be moving away from the Waterfall Method.

In Agile, the game idea is still usually originated by a design-heavy committee. The game idea is prioritized so that the core concepts are completed first, and this has definite advantages.

Teams know sooner if the idea needs significant refining.
The core systems of the game receive more testing and polish.
Content creators usually have longer to experiment with the core systems.

Agile is a bit more humble than Waterfall, but it relies on the "agility" of the team. Designers must be willing to throw out designs that prove unworkable, engineers will likely have to re-engineer systems, and artists may have to refocus if content changes. Usually, these adjustments are incremental and small, and as such, definitely more efficient than if a Waterfall project goes wrong.

With Cabals, the advantages are many fold if it is successful:

Team synergy increases with collaboration of shared projects
Ownership and accountability increases as ideas are shared in small groups
Individuals other than designers become heavy game idea contributors

Many stumbling blocks can prevent Cabals from being successful. Egos can dominate small groups, or shy contributors may tend to prefer more formal submission processes. In such a collaborative environment, a Cabal designated to design the core gameplay could become the envy of others on the team. Valve suggests rotating positions inside the creative core group.

Any Suggestions?

The only way to make expectations is to break them. - Unknown

From my experience, development teams are dynamic and often operate independent of an enforced process. Often, strong enforcement of a process can destroy will and creativity even if it increases performance.

I would suggest taking lessons from all the aforementioned development philosophies. Every iteration should begin with the determination and meticulousness of a Waterfall Method. When planning a project, one should always be Agile, expecting to iterate as soon and often as possible. Ultimately though, disseminating ownership and accountability like in the Cabal method ensures that the game is getting the widest range of creativity and attention it deserves.

I would also suggest that the decision to focus on a specific process be weighted by the type of game design itself. As I said before, Waterfall is generally seen as antiquated but might work for smaller projects.

A focus on Agile might work better for games where the core idea and content demands are equally divided. Games like Role Playing, Real Time Strategy, or Driving games might benefit from Agile. These games usually have a large amount of time spent on the content as well as the core mechanics.

Cabal Processes could work better on games where the core game concept is simple but content takes the bulk of development time. Games like First Person Shooters, Adventure Games, or Sandbox Building Games like Minecraft would benefit from the Cabal Method. Although the core gameplay may be solid, the variety of content generated will keep the player interested.

RTS Maps: Transport Down

2011-10-07T10:50:00.000-07:00

Command & Conquer 4 - GDI 2-3

Design Objective:
Create a mission that will be the proof of concept for the CnC4 campaign and the game.

Obstacles:

Must support multiple respawns and cooperative play
Follow a well received game like CnC3

Design Thoughts:
To make a mission for a sequel in the wake of a game as well received as CnC 3 is a daunting proposition. The gameplay was a radical shift from the previous game, and in many ways a lot of the pillars of what made the series great had been dropped. However, tone and setting were some of the tools that I had at my disposal, and those could definitely be executed on.
The story of the mission, being "downed in mutant territory," also let me draw from some nostalgia and create an interesting escalation. I wanted the player to slowly realize that he was not as alone as he initially thinks, and then realize that he'd kicked a hornet's nest as he fought to escape.

Process:
The core game allowed multiple respawns and cooperative play. I didn't want to use artificial coop tropes like "you stand here and you stand there and then the door will open." I wanted to give the players a bit more natural situation. Put two players in a scenario with more enemies than they could handle alone, and then just let them work together to handle it.

In keeping with the threat escalation idea, I decided on the objectives. After spawning near the downed ship the player would feel largely alone but surrounded by fog of war and positioned in the center of the map. To get things started, players have to venture out to rescue some downed escape pods. This would introduce the player to the local mutants, and provide an opportunity for the player to explore the map a bit before things get hectic.

Next, the player would have to capture and hold three points, Tiberium spikes, around the map, with some interference by NOD and any leftover mutants, forcing the player to build up his forces a bit, and begin to deal with NOD.

Finally, with the points captured, the downed ship would countdown to repair, and NOD would come in with full force. It was important that players get a chance to both scout the map and encounter NOD beforehand, as being surprised by large forces is never fun.

As the ship repair status neared 100%, NOD would be attacking from every angle, with the players alone in the middle of the map, respawning right in the heat of battle, one player having to defend the other.

Reception:
During focus tests, players were generally positive about the map and the mission. However, the largest part of the feedback (positive and negative) came from thoughts on how the core game worked. Luckily, the quiet start and ramp-up nature of the mission kept this initial confusion from being a total disaster, as players had time to experiment at the start of the mission.

Hindsight:
Command and Conquer 4 was never truly "designed" as such. CnC4 was tacked on to the remains of an attempt at a persistence-based Command and Conquer game, designed to introduce lots of new units and powers over time. Although the full motion video team produced some high quality footage that made the game feel epic, in reality the game was put together hastily to hit the market before StarCraft II.

Obviously these aren't prime conditions for any game, especially one that carries the weight of the Command & Conquer title. I still contend that CnC4 is a good game, but not necessarily a good CnC game.

Campaign missions in CnC4 were all fairly simplistic. It was hard to depart from the "die, respawn, rebuild" nature of the game, which didn't feel like any previous RTS. Supporting respawn in missions changed the battle escalation a great deal as well.

Randomness in Games

2011-10-04T18:27:00.000-07:00

Chances Are 50/50 That It's Good Or Bad...

Randomness is often at the forefront of discussion on why a game feels fair or not. Obviously there are successful games that depend very heavily on randomization as a major mechanic like Yahtzee, Poker, or Carcassonne.

In my experience, a player's feelings toward randomization comes primarily from how long they have time to react to it. It also changes drastically when you consider whether it is applied as a boon or a punishment. If randomization seems to occur at the same point a punishment is determined, it seems much more suspect than if it occurs long beforehand. However, if a boon is randomized, one is rarely put off as long as it is clear what happened and why.

The degree to which something is considered random could also be in dispute:

Tetris blocks are never completely random, although they are shuffled several turns in advance.
Diablo's loot tables are somewhat random but have a pretty strict filtering system in place.
Attacks in Risk use randomization, but the size of forces is still usually the determining factor.

Randomness Is Bad.

Random numbers should not be generated with a method chosen at random. - Donald Knuth

In games with random level generators like Settlers of Catan, Spelunky, or Minecraft, an unfavorable randomization is mitigated by the fact that you can prepare and plan to accommodate it. When the level is seemingly generated "on the fly" like in Asteroids, Helicopter, or Tetris, you always have a situation which you can "blame" the computer for making you lose, regardless of the number of times the randomization occurred in your favor beforehand.

In many RPGs, the attack damage is often calculated at the time of the attack. This is a means of keeping battle after battle from being rote but if the range of damage is too large, each encounter can feel like a simple roll of the dice. Have you ever "whiffed" away in frustration at a boss who "crits" every time? This is especially apparent when checking for traps in most RPGs. You spot check, wait to see if you took damage, and if so, reload to roll the dice again.

So if you're using randomization to provide a challenge or to punish a player in some way, make sure:

The player has time to react to the new information generated by random chance.
The chance decision provides new gameplay, rather than simply providing an outcome. For example, spawn some monster instead of simply damaging a player if they fail a spot check on a trap.
That you are providing some means of letting the player improve their chances of favorable outcomes.

Randomness Is Good.

Chaos in the midst of chaos isn't funny, but chaos in the midst of order is. - Steve Martin

In games, the suspense of having a chance of getting something randomly from a chest, loot drop, or other action is huge fun. In fact one could argue that it's largely the reason such repetitive play is tolerable in games like WoW, FrontierVille, or your favorite table in Vegas. Much discussion can be made about the subtleties of random reward schedules. Suffice it to say that within each game, there exists a ratio of risk vs reward which should be applied to each boon.

Obviously repetitiveness can kill an experience and make it feel like work. "Randomizing" helps extend the life of the game by providing variety in challenges and obfuscating the occurrence of rare opportunities. However, true randomness can often have the effect of being "too random." In true randomness, there is a chance you could get the same Tetris piece 20 times in a row.

Games must usually have a hierarchy of events and scenarios, ranging from common to rare. Within a game, a player may experience a range of random common experiences, to then get a chance at experiencing a random rarer one. This nested hierarchy of sets of random events has the effect of making players play more of the game, but if used too much, it can make every encounter feel random.

If you're using randomization to provide a boon or variety to a player, make sure:

The range of rewards are of similar value, interesting variety, and match the risk of the action taken.
Players have the information to discern the rarity of loot or experiences.
Players can improve their chances of encountering rarer or more favorable outcomes.

Well That Was Random...

We must believe in free will, we have no choice. - Isaac B. Singer

Randomness is an absolutely essential tool in creating a game. But (and I'll avoid a discussion on religion here) none of us want to feel as though our efforts are completely determined by chance. We need to ultimately complete the feedback loop in which our preparation is in some small way validated, our plan for attack seems reasonable to us, and that we feel we will obtain new information and resources with which to formulate a better plan next time. We need to feel progress.

Artificial Intelligence

2011-09-11T11:24:00.000-07:00

What makes a good artificial intelligence?

Design Objective:
Create a "good" AI for a game.

Obstacles:

Defining "good"
Determining complexity vs results

Design Thoughts:
With my RTS background, I often hear the term "stupid AI" thrown around a lot. What makes an AI seem stupid? I believe it's not so much that it does something to leave itself vulnerable, it's that it does that thing repeatedly. A stupid AI is one with a small "bag of tricks" as it were.

Now, an AI is inextricably tied to it's environment, and often a poorly designed environment can ruin an AI's chance of appearing intelligent. That said, one can write an incredibly challenging AI for Pong, which has only two moves, up and down. In such cases an AI can appear too intelligent or even reveal its ability to cheat easily.

Process:
I set out to design a fun stealth game. In it, the player must navigate an environment and destroy enemies. The enemies have the same types of abilities as the player in that they can move in two dimensions, fire a weapon, and detect enemies within predefined sight cone and hearing radii.

First, I created the movement, pathfinding and collision portion of the engine. It's important that the player smoothly glide along walls to aid them in hiding, stalking, and running away. It's also essential that the enemies should also be able to navigate the map just as well as the player, or the balance has started to tilt too far in the player's advantage.

Afterwards, I created the weapons, ability to take damage, and a death state. I also created the rudimentary AI to let enemies walk about at random. Next, I created the sight and hearing range limitations for the player and enemies. I added footstep and weapon firing sound events which the enemies would respond to by seeking out the player if they were in range.

I found this initial implementation of enemy "senses" a bit boring for the following reasons:

The static sight range made encounters feel totally random. This one I had anticipated.
The enemies never acted in unison except by chance occurrence, also anticipated.
You couldn't fire your weapon near any enemies and get away from them. The second they were locked on to you you couldn't shake them.

I added the planned feature of "lights," which added a "visibility" rating to each object. So an object's chance to be seen is now a function of their visibility and the observer's sight range. This feature let you sneak up on enemies, which was much more gratifying.

I added an "emergency" state to each AI. Now, when thy were attacked, they would move quicker than when on patrol. Also, if they saw another friendly when in an emergency state, they would put them on alert as well.

I also added a "memory hierarchy" to each enemy AI. Each AI would receive "assignments" from their "senses" and each other. If an enemy received an instruction to walk randomly to a position from the patrol portion of the AI, that instruction would be delayed until the current emergency instruction was satisfied.

Using the memory system, I could now give the AI a series of specific areas to "investigate." Along with a few more additions, I had some AIs with a few basic behaviors and a lot of emergent behavior:

Patrol the area, preferring areas which are well lit.
Upon hearing a soft noise, investigate.
Upon hearing a loud noise, activate emergency mode and investigate.
Upon seeing a body, or the player, call for help and activate emergency mode.
Upon hearing a call for help, activate emergency mode and investigate.

I replaced the "upon hearing a player-produced sound, attack the player" portion of the AI with a "hear a sound, investigate the source area" instruction. Now when you fired a shotgun and killed a guard, other guards would collect at the point where you fired the weapon, instead of following you. This allowed you to shoot, then run away and hide.

Is this the perfect AI? Far from it. What it did was illustrate to me the importance of continually surprising and challenging a player. The "smartest" AIs seem to be built from somewhat predictable patterns that get more complex when including other game elements. In other words, emergence.

Finally, I would like to stress the importance of showmanship. This experiment in AI got dramatically more interesting when I added sounds to some of the AI's responses. An AI is only as smart as when you can see, or in this case hear, it acting smartly.

Having the enemy's footsteps approach your hiding spot, stop, then leave conveys the drama for what would otherwise be a very boring encounter.
When you're spotted and you hear the surrounding area come alive with shouting, the fight or flight response takes over and tactical thinking gets interrupted.
Simply hearing the AI "talk to itself" reinforces a sense of realism and gives a player audible cues on how to form or refine a plan.

Reception:
My friends, colleagues and I have found the little game to be quite entertaining, with plenty of room to grow and add new features.

Hindsight:
Although it sounds like a fairly simplistic game, with a few extra features and some great graphics technology a game like this would rival any FPS or Third Person stealth game on the market. The end goal was not an AI which would beat you every time, that was never the point. The result was a firm foundation for a variety of interesting interactions and which feigned "adaptation" and made you think.

FPS Maps: Death Mall

2011-09-11T09:10:00.001-07:00

Counter-Strike Source: dm_deathmall

Design Objective:
Block out a multiplayer level in Counter-Strike.

Obstacles:

Support both interior and exterior spaces
Feature some vertical gameplay

Design Thoughts:
I chose a mall because malls tend to be fairly high on terrorism target lists. There are a few mall maps out there but most are either too small or too unfinished. This alpha version of the map is also a bit brush-heavy because I chose to block out some shapes to help sell the space instead of using models.

I also wanted to have the main passage be this long, heavy collision area where snipers could do well but would have to be supported by other players. The side routes would let players clash in the corridors and flank the snipers, too. I wanted to keep the map very simple at first, and expand it later to be a bomb defuse map.

Process:
I had a general layout in mind, but I found a few mall maps during my image reference search that had some more interesting layouts and so I decided to merge the ideas a bit. I built the mall interior first, and then added the side passages.

I had the Counter-Terrorists start outside in the valet entrance. It compliments the fiction that the "good guys" come in through the front door. The entrance area is medium-sized, and the spawns are distributed around the room to discourage camping. Some parked cars provide crouch cover and far corners let a single person cover the area if needed. Rifles and SMGs work well when attacking or defending this area.

Counter-Terrorists can move directly into Mall South, where raffle cars, benches and planters provide crouch cover. The other option is to take the parking garage entrance, which empties into a flanking position in the main mall area.

Terrorists start in the loading bay area, which fits the fiction well I think. Near the starting area is an open loading van and a dead guard for effect. Shelves in this area provide close quarters tall cover, making grenades and shotguns work well when attacking or even defending.

From here, Terrorists can move into Mall North, where counters and planters provide crouch cover, and there are several surprise attack sites in the hallways and corners. An alternative is to take the roof, an open play area with a decisive corner in the middle and AC units for crouch cover. The roof empties into a flanking position on the Counter-Terrorist side.

After a few single man test runs, I felt the map was a bit too small for my tastes, and I added the Food Court area in the center. It was a good addition, and really gave the map a defined center point collision area. The food counters and planters make good sniper nests. Snipers can cover this area from Mall North or South but can get flanked easily.

Reception:
The map has had a series of local tests, all of which yielded decent feedback and notes. Overall, the response has been positive. "Texture it!" they all say.

Hindsight:
I probably should have just went ahead and made the bomb defuse map first. Although it helps my ego to have some confidence that the map is fairly balanced before adding asymmetrical elements, sometimes the little imbalances become permanent features and add to the uniqueness of a map. Not entirely fair is often fun.

Game Design Documents

2011-09-11T09:09:00.001-07:00

Does anybody really read these things?

Design Objective:
Create a Game Design Document that people will actually read.

Obstacles:

The sheer amount of topics and details you must cover
Arrangement into an easily searchable format

Design Thoughts:
In my experience, game documentation generally follows this progression:

Idea - comes in a variety of forms (back of a napkin, voice note, 2am e-mail, etc.)
Pitch - starts rough and becomes more refined as it gets used. Sometimes people skip this step altogether and go straight to the white paper.
White Paper - the precursor to the GDD, a list of intentions and features the game should have, used to unify the team and get everyone on the same page.
GDD - an ever-evolving, never entirely accurate, scapegoat of a document that requires a full time job to properly maintain.
Technical Documentation - the spin off documents created to explain the technical details of features or balance. Usually created by design specialists or engineers.
Worksheets - balance spreadsheets filled with formulas and macros, databases of items and enemies, or (more recently with social games) price point worksheets for micro-transactions.

Process:
This article covers my thoughts on constructing a GDD. Now, before creating a design document, you want to have a very good idea of the scope of what it is that you're setting out to do, otherwise you waste a lot of time.

Create an outline and be as thorough as possible. I like to use "inevitability statements." Write down what it is you want to do, and then follow that note with exactly what it is going to take to make that thing happen absolutely. Then follow that statement with another of the same. Repeat this exercise until the statements start to resemble things you could do in the next day or so. If you don't know how to do something, get some expert advice or do more research.

You can use these lists to then draft your design document. A design document is essentially a business plan or a proposal. In it you propose to the development team how it is that you plan to accomplish this fun game you keep going on about. A proposal has a purpose, problems, and solutions. These match closely to the game development terms of game idea, interface features, and their elements.

Fact: The more people you can get to read your document the less time you have to spend explaining it during development.. Purpose statements and descriptions of your game idea should:

Use short paragraphs and bullet lists, like this one! Don't throw a wall of text at people.
Include brief answers to the questions who, what, when, where, and why. Be forward, specific, and to the point.
Avoid excessive detail. Use the inevitability statement list you made earlier as a meter for hierarchy of detail.

When creating the features list, try to imagine the player's path through the game. Again, you don't need excessive detail here. Be thorough with your thinking, but allow room for the members of your team to become involved in the process and create their own documents. Use each separate "screen" of the game as a section, and then briefly go over each element of the screen. It's fine if some sections have more elements than others.

These features sections will inevitably force you to create separate, more detailed documents, describing the player's options on each screen. Sometimes these documents can be explained concisely enough to fit inside the main GDD itself. Depending on the complexity of the game, sections inside the GDD may have to link to other supporting documents.

Whether or not a supporting document is included in the main GDD depends largely on who will be using it. For instance:

Never include large lists of resources in the main GDD. These lists are used primarily by developers, and a quick-reference list doesn't belong in a grand overview document.
Overly technical documents or flowchart type explanations should exist outside the GDD. These are typically reference documents and should be easy to find and pass around.
Project planning documents are certainly part of the "solutions" to the game idea, but these documents are typically used by producers and should be located outside the main GDD.

Finally, don't fall into the "waterfall method" trap. Once your document has been drafted, it will require constant revision as the game evolves. Use the GDD as a document to remind yourself of all the game's features and elements that will be effected by the decisions you make during development. Don't hold someone's feet to the fire for failing to recognize some minute detail in your GDD. Do refine your GDD and be an advocate for it.

Reception:
I have had good feedback from my design document formats. I think the main reason for this is that they follow the time-tested method of the business proposal format.

Hindsight:
Creating a design document, or at least an inevitability statement list is a good first step in confirming whether or not your game idea is a good one. It forces you to think through each portion of the game, which can often be hard to do, especially when you are enchanted by "that one cool feature" that everyone wants to see come to fruition. Although sometimes not an option, I believe a rough draft of the GDD should be a precursor to the pitch document.

RTS Maps: Recruiting Mercenaries

2011-09-10T21:28:00.001-07:00

Lord of the Rings: The Battle for Middle Earth - Near Harad (Evil)

Design Objective:
Sauron commands you to bend the desert dwelling mercenaries to his will.

Obstacles:

Keep the game play simple
Use a desert map

Design Thoughts:
I'm not a big fan of desert maps, mainly because they tend to be large open areas of sepia tone with little distinguishing features. But I wanted this map to really feel like an open desert area. With most of Middle Earth depicted as picturesque winding passages, the art team and I had some work to do.

The mercenaries you had to recruit were the Haradrim ("Giant elephant riders" for you non-Tolkien types). This scripted map was intended to be a secondary encounter and not an integral part of the main storyline. As such, I wanted the game play to be simpler than a primary encounter, but not as simple as a default skirmish encounter.

Process:
There were basically three Haradrim unit types in the game, so I split them into three camps. One camp would have archers, one would wield spears, and the other would ride atop the dreaded Mumakil (Giant elephants). As you defeated one camp, you would gain their units.

In order to provide a some progression and encourage the player to train a properly sized fighting force, I included some small camps in the north, with bonus treasure for defeating them. As the player grew in size, the three main camps in the south would send out teams to harass them.

The map layout was fairly straightforward to create, and the emergence from letting the player decide which order they would defeat the camps was also a pleasant departure from the standard "destroy this castle" type scenario in the non-scripted maps.
The Mumakil camp was the toughest to defeat, so they were placed in the middle. If either side camp was captured, the player would have to regroup in order to sweep the map right or left. Veteran players would experience a rolling victory, while newer players were rewarded for narrow victories with large reinforcement armies.

Reception:
It was a lesser played map, being near the edge of the campaign and not critical path. Testers and other team members really enjoyed playing this map, however. I find this map to be a good example of the power of simplicity.

Hindsight:
We designed some of the scripted maps to do double duty as multi-player maps, in an effort to provide more game play. In hindsight, this map could have benefited from some heavy asymmetry in the terrain layout.

Third Person Maps: Steel Mill

2011-09-10T21:10:00.000-07:00

Unpublished Console Title - Steel Mill

Design Objective:

Create an introductory level for a third person game featuring a character which can "possess" NPCs and use a variety of powers to kill or maim them.

Obstacles:

Extremely threatening main character
No threatening enemies

Design Thoughts:

This game was very similar to the game Psi-Opsor Second Sight. The executive producer had already set a strict path for the mechanics, but no tone for the game was set. The development team, created without a designer role in place, had struggled with a game they envisioned as an action game.

My approach was to embrace this seeming imbalance of power between the player and enemies and re-brand the player as a "stalker movie monster" like Jason or Micheal Myers. If the player is immensely more powerful than his "enemies," then perhaps the fun would be in becoming a stalker. Maybe if we played up the vulnerability of these NPCs then the game would find its legs.

Process:

If the player is a stalker, then his approach should be from the shadows. He should be allowed to spy on his victims. When he attacks, his victims should run away, get help, and try to swarm the player. The overall game would then become how to stop the swarm from growing too large, or how to kill silently and quickly.

The player's exceptional prowess also made the implementation of physics puzzles a possibility. Using an ethereal hand-like power, the player could pick up and throw NPCs and objects. I was constantly dreaming up these Rube Goldberg scenarios involving unsuspecting security guards and their comedic demises.

I decided the level should take place at night, allowing us to "highlight" points of interest easily. Near the start of the level, a Security Guard would be sitting with his back to the player in a brightly lit guardhouse. Then, we'd give the player a variety of methods to off him, some which tripped alarms and others which triggered curious workmates to enter the scene. "Bob? Bob? Are you okay? Where's Bob?"

As the player progressed, they would find themselves in more and more complex stealth-kill scenarios, meaning it would become harder to kill enemies without getting unwanted attention. In the train yard areas, haulers would come through and make loud noises, allowing the player to make some noisy kills (stifled by the loud trains) but only for a short while.

Throughout the level, players would enter special areas that would allow them to "reset" their alarm status by effectively "disappearing" for a while. Cramped corridors full of steam, darkened alleyways, or loud rooms like the main steel mill production line were just a few of these areas.

Finally, the level culminated in a boss battle, requiring the player to utilize the skills they had learned throughout the level. This boss battle involved tipping large cauldrons of molten steel onto the boss several times to put him out of our misery.

Reception:

The level was artistically and conceptually a wild success. Your progression through the level as the unknown killer was made all the more real with the expert lighting technology that the game was developed on. Unfortunately, scripting never began on the level in earnest. However, I'm convinced my "stalker" approach would have absolutely unified the elements of this unpublished game.

Hindsight:
Many areas of this game were developed without regard to other areas of discipline. For instance, a single AI which was to be used for all enemies was being developed by an engineer, and design was not allowed to be involved. Game mechanics were being dictated by a non-designer as well, with no regard to progress made on AI or level design.

The reason I bring up these issues is to stress the absolute reliance of every team member on every other team member. A team with respect and trust means each member is simultaneously motivated and humbled. This creates a desire to do your job and be patient with people that gets far better results than any imposed structure could ever hope to attain.

RTS Maps: "Jarmen Kell and the Forty Thieves"

2011-09-10T18:18:00.000-07:00

Command & Conquer: Generals: Zero Hour - GLA 4

Design Objective:
Create a puzzle mission that highlights the sneakier aspects of the GLA faction.

Obstacles:

Player should command separate, small groups of forces.
Player will be invading American soil.

Design Thoughts:
"Puzzle mission" sort of insinuates a limited solution set, and that the player is going to want to have some time to think about their next move. Furthermore, if the mission is going to be more complex than the normal "build up and destroy" format of RTS missions, it can't be too punishing. We don't want players replaying a mission repeatedly that has a very limited solution set.

Regarding pacing, I was sure that there should be some degree of action involved without the player having to risk all of their units. Therefore, virtually all major challenges would probably be static, meaning non-moving stronghold-like defenses, and the player would never be pressured to retreat. There would exist some battles, but the player generally had the upper hand with stealth units.

Process:
I made a list of actions available to the GLA, and found a lot of gameplay to my advantage. A lot of unit replenishment options were available, like snipe-stealing, hijacking, capturing, and garrisoning, so I didn't have to rely completely on artificial reinforcement mechanics.

After figuring out which abilities had unit dependencies, how the mission should progress logically, and connecting the dots, I created the map. The map was like solving a puzzle unto itself.

I started the player with lots of Hijackers, a unit which steals enemy vehicles. This meant their army could grow in power without me giving them a lot of reinforcements. Hijackers would also exit vehicles when defeated in most cases, meaning the player would tend to retain more of their original units.

Some of the abilities could be used safely at range, and those abilities I used to let the teams help each other:

Team 2 uses the Radar Van could reveal mines for Team 1.
Team 1 uses the artillery to clear the path for Team 2.
Team 2 drains the reservoir and allows passage for Team 1.
Team 1 clears the garrisoned bunkers for Team 2.
Team 2 destroys the power plants and cripples the US defenses for Team 1.

Some of the interactions were simply very gratifying, so I included more than was really needed. Clearing garrisoned buildings with Toxin tractors, or bringing the entire US power grid down were some good examples of that.

Reception:
This has generally been regarded as a favorite mission by a lot of players and developers. Some have revealed that it made them "feel smart" and that it was a very nice departure from the normal RTS gameplay.

Hindsight:
There were sections of the level which could have been explained better without revealing the puzzle aspects involved. Especially during the end sequence, people lost track of the trucks, unaware that they worked like standard resource haulers. Fortunately they were not punished for this, the game only stalled out a bit.

My Resume

2011-09-10T18:00:00.000-07:00

JEFF STEWART

An experienced designer and producer looking to work with a team of like-minded energetic professionals who want to create killer, innovative games that push the medium forward. I create interesting experiences. I improve pipelines and processes. I innovate and solve problems.

Design Experience:
Casual Social Games
Real Time Strategy
First Person Shooters
Third Person Action/Adventure
Turn Based and Action RPGs
2D 8/16-bit era Engine Design
Adventure Game Design
Story and Dialogue Writing

Director of Development - A Little Entertainment – Houston, TX (3/10 – 8/11)
Pitched and produced new social games
Drafted usable design documents and Gantt project plans
* Space Trader Joe – FB Launch 2011
* Cruise Time – FB Launch 2011
* Doors to Adventure – FB Launch 2010
Unified team to improve project development times by 30%
Successfully outsourced art and audio, cutting content production cost by 50%

Senior Designer - Electronic Arts - LA, CA (8/02 – 11/04) (2/08 - 4/10)
Designed and created real time strategy maps and missions
Scripted player opponents AI, events, and cinematics
* Command & Conquer 4 - EA 2010
* Red Alert 3: Uprising - EA 2009
* Red Alert 3 - EA 2008
* Lord of the Rings: Battle for Middle Earth - EA 2004
* C&C Generals: Zero Hour - EA 2003
* C&C Generals - EA 2003
Drastically improved art target for Zero Hour by personally performing a final art pass on all maps
Increased performance by 200% or more on problem missions
Created the Battle for Middle Earth E3 Demo that won GameSpy's Best of E3 2004 Editor's Choice and the E3 2004 Game Critics Award for Best Strategy Game

Campaign Lead - Petroglyph – Las Vegas, NV (01/06 – 2/08)
Led team in design and creation of real time strategy maps and missions
Drafted screenplay and story dialogue
* Universe At War: Expansion - Unpublished
* Universe At War: Earth Assault - SEGA 2007
* Star Wars: Forces Of Corruption - LucasArts 2007
* Star Wars: Empire At War - LucasArts 2006
Introduced 3D terrain “hole” effects, dramatically improving art target for Forces of Corruption and Universe at War
Standardized modules for campaign scripting, significantly reducing mission creation time

Game Designer - Terminal Reality - Lewisville, TX (12/04 – 01/06)
Designed, modeled, and scripted first and third person maps
* Demonik – Unpublished
* Untitled FPS Demo - Unpublished
Stepped in to fill the need for story direction, providing screenplays and game dialogue documents which were beloved by the team

Level Artist - Digital Tome - Houston, TX (6/00 - 8/02)
Designed and created Action RPG levels
* Pillars of Avalon - Unpublished
* Hero X - Infogrames 2002
* Siege of Avalon - Global Star 2001
Advanced in my role to become responsible for scripting level events, writing branching dialogue, create enemies, items, and player powers

Tools Experience:XML, Lua, C-like languages
3D Studio Max, Photoshop
FPS editors (Wolf, Doom, Duke,
Unreal, Half-Life, Doom3)
Adventure Games (AGS, AGI, SCI)
RTS Editors (WorldBuilder, Alamo)
RPG (ChaptEd, Aurora)
Game Maker 5-6+

Blog:
designface.blogspot.com

First entry!

2011-09-10T17:54:00.000-07:00

This blog will be used as an alternative to a portfolio. Since screenshots don't quite tell the story of how a design comes together, I'm hoping a blog format might be more palatable. Testing image upload...

Awesome. Now let's start the blog.