subscribe to the RSS Feed

Saturday, July 31, 2010

Focus, Atmosphere, Limitations: Learning from Shadow of the Colossus

Posted by Brice on July 26, 2010

Shadow of the Colossus is considered a landmark title that was developed by a highly disciplined and intelligent team.  Released in 2005 for the Playstation 2, the critically acclaimed title featured incredibly expansive, vast worlds and even more vast enemies to scale and conquer.  Set in a fictional world, the game follows the tale of a young warrior who is on a quest to slay all of the mystical massive creatures that exist in order to resurrect his fallen loved one.  As the player goes to each location to slay each colossus, they become larger and more beautiful than the last.  Between these epic battles are uneventful rides through breathtaking fields, mountains, and other terrain.

Shadow of the Colossus is useful as a smart game development model for several reasons.  The cadence of the title is very different from most games; instead of a nice stroll or job through the excitement and action of the game, Shadow of the Colossus seems to be more like walk, sprint, walk, sprint, in the way that the player has massive “boss” fights bookended by serene horse rides.  Why is that?  Secondly, the game is one of the most beautiful ever developed for the Playstation 2.  How does the world work together with the gameplay?  And third, why is the game so limited in the abilities of the main character?  Was that on purpose?

Let’s dive in to the practical development techniques that student and independent developers can learn from this title.

Learning from the Colossi: Focus

There is much to be learned from Shadow of the Colossus; the game speaks volumes about the development team that created it.

WAIT! There is more to read… read on »

Redeemed: A Design Analysis of Heavy Rain

Posted by Brice on March 21, 2010

HeavyRain1

I could hear the man yelling at the cashier.  I have to do something, I thought to myself.  I quietly started walking towards the grocery aisle behind the gunman and began to approach.  Maybe I could tackle him or something.  Suddenly my arm brushed a bottle and it began tumbling to the ground.  A button appeared for me to catch it, but I wasn’t prepared, and whether it was a Circle or a Triangle escaped me.  The bottle tumbled to the ground and the gunman looked back at me.  Drat!  Now I was in trouble.  He pointed the gun at me and ordered me over by the cashier.  So much for that…now what?

And so continued another scene in Quantic Dream’s Heavy Rain.  This Playstation 3 only game has been getting a lot of press and some pretty impressive reviews recently.  Being embraced rightfully as an “interactive narrative”, Heavy Rain chronicals the story of four characters tracking down the identity of a murderer known as the “origami killer”.  An unlikely private investigator, a hopeless father of a murdered child, and other personalities pay a central roll in the game’s unfolding, built of deep characterization and large swaths of time developing your emotional connection with the characters.

I’ve written about Quantic Dream’s spiritual predecessor to Heavy Rain, Indigo Prophecy (Fahrenheit) several times.  It was an interesting experiment in my mind, but from a gameplay design standpoint, I argued that there were some Base Mechanics that were poorly executed that completely harpooned the experience.  I’m all for games that focus on unique Core Experiences, and having a game built around story and exposition is certainly not something that is done often on major consoles nowadays.  Many players and reviewers enjoyed the game, but as the hours wore on, the poor gameplay design became too much to bear.

I am happy to say that Heavy Rain repairs much of the damage done by Indigo Prophecy’s design choices.  This studio’s game title is definitely much more mature in its development than its predecessor, likely due to feedback and iteration on the first game’s choices.  Let’s break it down. WAIT! There is more to read… read on »

The Potential of Game Design

Posted by Brice on March 1, 2010

In case any of you haven’t seen it, Jesse Schell of Carnegie Mellon gave a great talk at the DICE game development conference.  He discusses a lot of the psychological tricks that many cutting edge designs use to monetize their games (Punishment and Reward Systems and Base Mechanics).  Very worthwhile for anyone interested in learning about what lots of designers in the industry are thinking about now.

Check it out here

Why No One Plays Their Wii Anymore: A Design Analysis

Posted by Brice on January 12, 2010

Photo: BrittneyBush

I still remember back in 2005 when the Wii was announced at E3, and the entire games industry just gasped.  “What IS that?”  It just didn’t make any sense at all.  The words were coming out of their mouths and the demos were on the screen, but it just sounded like complete madness.  A revolution indeed.

While motion control seems obvious now, you’ll have to take a moment to appreciate how impossibly innovative and creative it was at the time.  No one else was anywhere near thinking something like controlling a game some way other than buttons was possible.  And thus you have the makings of a fascinating story, of a company going from just about out of business in the console world to being #1, with sales that are unmatched by any other platform, and its leaders being named the top CEO’s among all industries, not just games.  The Wii is certainly a lot of fun.  Everyone remembers their first time playing Wii tennis, hearing about it, and trying it out.  Everyone remembers being amazed that aunts, uncles, and grandparents were suddenly interested in games when they had displayed not a shred of curiosity before.  If nothing else, it makes a great first impression, and that first impression has led it to over 50 million units and the best selling single game title of all time.

But there’s something wrong, isn’t there?

Isn’t it odd, that though so many Wii’s have been sold, they are actually played significantly less than other consoles?  Isn’t it strange that despite how much fun everyone has swinging their arms wildly during Wii Sports tennis, eventually they are reduced to simply flicking their wrists?  Doesn’t it seem unusual that while there are seemingly hundreds of Wii games on the market, you could count the ones worth playing on one hand? WAIT! There is more to read… read on »

Canabalt: Taking a Base Mechanic to the Limit!

Posted by Brice on December 20, 2009

Canabalt

Run for your life!  That’s the Core Experience delivered by Adam Atomic and Danny B’s hit browser game, Canabalt.  Created for the Experimental Gameplay Project, Canabalt was designed to use only one button.  That’s right, only one button.  Our intrepid survivor runs automatically to the right of screen, while the player presses a button each time they want to jump.  By dashing over buildings and avoiding obstacles, the player runs and runs and runs as birds leap off the rooftops and military ships fly overhead.  The game really is a thrill.

Canabalt was an absolute breakout hit in the indie game world, so what can other developers learn from it?  How can we apply the principles that made Canabalt so popular to our own games?  Why, by breaking out our old friend, the Game Design Canvas!

Breaking it Down

As we said, the Core Experience of Canabalt is to make the player feel like they’re running for their life.  Games that achieve their Core Experience well are the ones that we dream of and latch onto, and so the trick is to understand exactly how they did it.

Careful choice (and elimination) of Base Mechanics. To begin, you’ll notice that in Canabalt, the player’s character runs automatically.  There is no Base Mechanic for making the character move forward; that was purposely left out.  The effect?  A sense of urgency, a feeling that you have little control.  He’s going to run right into that wall in just a moment unless you do something!  This simple subtraction of control is a beautiful example of design through simplicity.  By causing the avatar to move automatically, the player becomes panicked from the first second the game is being played. WAIT! There is more to read… read on »

Why “Casual” Doesn’t Mean “Easy”

Posted by Brice on December 9, 2009

wii-sports-tennis

“Casual” games have been all the rage in the games industry over the past few years.  From the explosive growth of online games to the major First-Party support of the Wii, the “casual gamer” and the entire supposed market space has become a great buzzword and mainstay in game development.  Entire divisions of large companies have cropped up solely around the idea of casual, and smaller companies and developers striking it rich in this wild west of an audience.

But seriously.  What does “casual” really mean?

Of course anyone can point out games that are casual versus hardcore.  Wii Sports and Farmville are casual games, sure.  Call of Duty and World of Warcraft are not.  But what does that actually signify?  And if you’re going to base independent or corporate projects and future sales figures on these genres, doesn’t it make sense to understand what they are and how they work?

By using the Game Design Canvas, we can break down both casual and hardcore games and find out what really makes them tick.  When we contrast them as you’ll see in a moment, there aren’t as many differences as one would assume.  However, one major difference betrays a casual game as a casual game, and that one difference influences the game’s audience, the viable platforms, sales methods, everything.  It is the difference that sets it apart from the hardcore titles and gives it its soul. WAIT! There is more to read… read on »

The Game Design Canvas: Base Mechanics

Posted by Brice on December 7, 2009

Image: oskay

Dave is working on his blockbuster indie game title.  He knows the genre, and he has a general idea of what he wants it to be about.  It’s an action/adventure title about vampires and he wants the player to be able to steal blood from victims.  He’d also like the player to have to avoid light in the day, and it would be a story about love and romance.  Sounds like a great game!

He expresses this idea to a friend of his who is in the industry.  His enthusiasm is apparent in his voice and his excitement about the idea, with the main part of the game revolving around the vampire stealing blood.  But then his friend asks him…

“How does the player actually steal blood?”

Dave reminds his friend that the vampire will be able to go up to anyone and suck their blood, and that’s how it occurs.  But his friend reiterates, “But what actual buttons will the player be pressing?  How are you going to convey stealing someone’s blood as a vampire through pressing a button?”

Dave looks down at his shoes, realizing that although his idea may be exciting from an elevator pitch, he may have jumped the gun.

You Can’t Build a House without Bricks

Dave’s idea may be a good one, but will it come to fruition?  It depends; all of his thoughts are fine ideas, but there’s no structure to them.  Dave hasn’t taken to the time to build the foundation of his game; he’s just started with random anecdotes.  Odds are that if good old Dave just goes ahead and starts coding in his idea without connecting the dots first, he’s going to end up with a mediocre game that feels kind of like…well, every other game.  Which is to say it won’t really feel like anything. WAIT! There is more to read… read on »