Brian Holinka

GDC Recap: Gordon Walton's 10 Things Great Designers Exhibit

2009-03-27T11:19:00.020-04:00

If you read Gordon Walton's wikipedia entry, it does take long to know he's been around the games industry for awhile. Saying his talk, 10 Things Great Designers Exhibit, was well-attended would be a massive understatement. It was absolutely packed. Every seat was taken and people were perched along the wall. Obviously, people want to know what exactly an experienced industry veteran like Mr. Walton looks for in game designers. Here's his list in priority order with my own personal interpretation of each (flawed as it may be):

#10 A Passion For Games (All Games)
While Walton pointed out this passion was obvious, he also pointed out it was the least important. I think the real point here was that he feels a designer should have a passion for all games, not just the specific type of game their working on. My interpretation of this point is that there are some common elements in games that should really capture the designers attention. If someone is only passionate about their particular specific type of game, maybe their missing the core essence of the gaming experience. If they enjoy a wide variety of games, it's more likely they can develop new innovative gameplay for their current title.

# 9 A Breadth and Depth of Knowledge
Mr. Walton posed the following three questions for any designer:

What is your level of game knowledge?
Across game platforms?
What do you know outside of electronic games (i.e. movies, current events, literature, science, etc)?

He followed these questions with the assertion: Synthesizing knowledge is the key. I found this particular point challenging for many of the aspiring designers I've met (myself included) but it's definitely something I've observed in veteran designers. Most of them are intellectuals whose interests are not merely limited to video games. They devour books, movies, and conversations about a wide range of topics. I personally think it's important because exercising your mind in other areas allows you to approach game design more objectively. You just have to get out of your own little world sometimes so that you can re-enter it with a fresh perspective.

Mr. Walton actually asked how many people in the audience read at least 1 book each month. I was ashamed that I didn't raise my hand, but honestly there a lot of things I need to work on and the one I'm least concerned about is my reading.

# 8 Problem Solving and Analytical Skills
Once again, Mr. Walton posed three general questions to would-be great designers in the room:

What is your approach to problem solving?
Can you effectively deconstruct complex problems?
How are your logic skills?

Design, in any discipline, is finding the "right" solution to a "problem." In games, our "problem" is entertaining the player in a new innovative way under a variety of technical, social, logistical and financial constraints. Finding the "right" solution takes creativity, but it also takes practical problem-solving skills. High-level design can be fairly easy, because it doesn't directly need to deal with these constraints, it can deal with them in an abstract way. But a lot of design, especially at the system level, requires a designer to find creative ways to deliver the high-level design goals through low-level mechanics despite challenging obstacles. Developing a good solution and then objectively evaluating it are core to good game design.

Now one potential trap that Mr. Walton identified is over-analyzing the problem and consequently creating overly complex designs. There's a delicate balance between designing against edge cases and falling into analysis paralysis due to over-thinking.

# 7 Flexibility
Anyone in game development can attest to the fact that the more flexible you become, the more effective (and happy) you'll be. Mr. Walton says that design can be exciting but also frustrating due to the frequency of changes involved. Designers have to toe a delicate line between championing features that really capture the game's essence, and reacting to a rapidly changing development environment. Not to mention, as Mr. Walton says, design must adapt to match the platform/business constraints along with the player feedback. Designers, by their very nature, think about their games more than anyone else. It's impossible not to lose some objectivity. You have to remain very open to criticism about the game's design in order to arrive at the "right" conclusion.

# 6 KISS (Keep it super simple)
I haven't heard this version of the acronym K-I-S-S, but it's certainly a positive twist on a classic. Walton voiced his distaste for the traditional saying, "Keep It Simple Stupid" because it suggested if you couldn't get it simple, then you're stupid. I liked the positive spin, because it tells me he sees the value in trying to treat people in a positive way. Walton then joked about a More's Law (not the more common Moore's Law). "If some is good, more is better." It's obviously sarcasm since in gaming, simple elegant solutions are generally better for both the player and developer. Falling into the "More's Law" trap is one of the most common mistakes designers make. Even the most experienced designers make it sometimes. A designer may create a "deep" (read: overly-complex) design thinking users will appreciate their "genius." However, complex designs lead to player confusion, not to mention a rough development cycle. Obviously, there's tremendous value to a designer who understands simple but powerful design and the strength of will to see that simplicity implemented.

# 5 Player Empathy
Empathy is defined as the action of understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another without having the feelings, thoughts, and experience fully communicated in an objectively explicit manner. In short, a great designer can understand what a player will think and feel when playing the game. Of course, this can be partially accomplished by performing the most obvious task: playing the game!!! Playing the game and honestly and objectively evaluating the experience is certainly a required skill. But, there's something special about a designer who can foresee these problems before implementation. Of course, not all features can be evaluated simply through thought experiments, so honest evaluation (and the courage to make changes) is definitely necessary.

# 4 Continuous Learning
Walton said, "Designers are on a journey to understand the world and translate that to other people for their enjoyment." Personally, I loved this quote. It made me feel like a Shaolin monk or something. But, I feel like trying to understand the world, and all the wonderful, awesome, beautiful or ugly things in it, is a noble and virtuous goal. Then, following up on that challenge by trying to use gaming to communicate these things to a player seems an equally noble and virtuous challenge. THEN, trying to make this awesomely noble and virtuous product profitable, well that's just too much challenge for one paragraph.

# 3 Teamwork - Being a Team Player
Although this would appear to be another obvious one, I think what's important is where teamwork falls in the rankings. Walton lists it third, because quite plainly design is a team-oriented discipline, especially in the AAA industry. Designers are motivators and leaders. They gather the design from the team and help them implement it, providing direction wherever needed. Naturally, this requires a TON of interaction with the development team (an always colorful group). Game developers are passionate, opinionated, and talented. They are the ones who really make the game, so part of being a designer is selling them on the idea. Some people are far harder sells than others and at times that can be difficult. In this event, Mr. Walton recommends that if someone irritates you, get closer to them. Force yourself to get to know how this person feels about the game and what's motivating their discontent with the design. Hopefully, with better understanding and an open mind, you can find out how they're motivated and better interact with them, making both of you better team members (sounds so wonderful and easy doesn't it).

# 2 A Positive Mental Attitude
No one likes being around a cynical grump. Even though they can do good work sometimes, eventually they bring down the general mood of the team. They make everything, even the easiest things, more difficult. Game development is tough enough already, no one needs a curmudgeon (his word, not mine) around making things even harder.

# 1 Clear Communication
Walton's number one characteristic exhibited by great designers can be summarized in these three critical points:

Design is communication
Communicating to both the team and the audience
Clarity of communication drives the fastest implementation and the most effective iteration

In summary, designers must communicate the design to the developers so they can implement the design vision. They must relay the finer points of each mechanic and sell them to the team. In a different sense, the designer must also communicate the spirit of the game to the player through the gameplay mechanics. The final point is simply that the better the designer communicates the idea and details of a feature, the more efficient it will be implemented and refined.

While his talk was well-named, I actually think he should have called it something like, "10 Things that Distinguish Great Designers From Average Ones." The most interesting criticism of his list is that it could be applied to any game development discipline (or occupation for that matter). However, I haven't seen anyone really call out these items in the way Walton did and I think the traits he highlights here are often times lost. He probably should have one entry for something attune to "Design Intuition", but he felt that's just a given. If you want to be a designer, you need to come to the table with solid design skills. Of course, if it's a given, then why not list it? It would be interesting to know if he'd change his list in retrospect following that critique.

Overall, this was fantastic talk that taught me a ton and gave me aspirations for the next year.

GDC Recap: Iwata San

2009-03-26T11:19:00.001-04:00

The Death Spiral. The Ball of Death. The Third Yomi. Strike Force Panda. 4 concepts you couldn 't find anywhere else but GDC. So far the conference has been awesome as always. Days spent listening to people talk about their development experiences and nights spent catching up with old friends and making some new ones.

The day started with Satoru Iwata, President of Nintendo, keynote address. Right before the talk began, a friend turned to me and sarcastically asked, "I wonder if he's going to gloat?" Sure enough, 10 minutes later Iwata was displaying sales data that illustrating Nintendo's absolute ownage over the platform industry (especially with the DS). But after listening to him for the rest of the talk, you can't deny that Nintendo remains the wise elder of the industry. They make games the right way and it shows critically and practically.

"The Death Spiral" was his analogy for the vicious cycle developers enter when they bow to external pressures to release a game before it's done. The game enters the marketplace before its ready, sells poorly, resulting in less revenue and more time pressure for the next project. This might not be anything revolutionary, but I think Iwata was pointing out the tremendous institutional strength of will it takes to toy with multiple game ideas at once but only release products when they're really done.

I came away from this talk feeling the same way I did when heard Miyamoto talk two years ago. Nintendo, as a company, is brilliant.

Game Designer: Year 1

2009-03-25T10:26:00.002-04:00

Today, I head to my third Game Developer Conference (GDC) in four years (I skipped one in Santa Cruz 2 years ago). This is one of my favorite weeks of the year from a totally self-absorbed career-oriented point-of-view. It's an annual reminder that in a small way, I've arrived and in many ways, I have a long way to go. Like many other people in the games industry, I playfully dreamt of one day creating the video games I played incessantly. I didn't really take that dream seriously until I was in graduate school many years later, unhappy in a world with little practical application but lots of paper writing. I came to an impasse where I had followed an academic progression I thought I was "supposed" to follow and I was ultimately miserable. Two years later, with some military service time, luck and late night elbow grease, I was making video games for a living. GDC is my annual opportunity to take stock of how my dream is progressing. I evaluate my career, set goals for myself, look for the best opportunity to achieve those goals, and try to find the right place for myself within this industry.

Of course, like a lot of industry veterans may tell you, game development and design aren't always joyful and frustration-free. We deal with people too after all. The job of game design is most likely not something you'd expect (I certainly had it wrong). On my more cynical days, I describe the job, game designer, as arguing for a living and writing documents that no one reads. On more positive days, I'd probably (more accurately) describe my job as:

Championing the design vision to my fellow developers
Helping our developers understand features
Helping our developers identify challenges created by feature requirements
Ensuring all features in our game have the highest level of quality possible
Funneling and sorting the creative design ideas of other developers at the studio

Now, I've only been doing this job for a short time, but slowly I'm starting to discover alot of the skills someone needs to be a designer. Likewise, I'm coming to realize where I'm strong and where I'm weak at each of these skills. GDC provides me a great opportunity to reflect on my recent work as a game designer and the skills I think I need to have or improve on. So, in no particular order, here they are:

Patience
The one thing I've had to learn, more the anything else, is patience. As a designer, you need patience on a number of levels. First, your decisions are challenged on a regular basis. Everyone that works at a game development studio has some level of design ability, but not many opportunities to demonstrate those abilities. But many times, by no fault of their own, they don't have the same perspective as someone in a designer position. Designers spend a lot of their time in meetings with other departments talking about different parts of the game. They have to keep a game-wide perspective about everything and often times design decisions are influenced by this gamewide perspective. While it could involve how one shooting mechanic may interact with some vehicle mechanic, it might also be with respect to production costs and project scope. Regardless, a designer has to be prepared to be challenged constantly about their decisions and explain themselves on more than one occassion. In the end, we're providing that service to everyone else in the studio, so we need to ensure that we engage in that conversation openly and often with great patience.

A Broader Perspective
Before I was a designer, I was a programmer. I was constantly frustrated by design, because I didn't understand why they would make decisions about the particular area I was working on. Now that I'm sitting on the other end of the table, I have a better understanding of how a game (especially a larged complicated, "fully-featured" one like those I've worked on) can be a complicated web of dependent mechanics. Decisions made about one feature may have profound effects on another feature. As a designer, I have to keep this in mind at all times. Is this decision or feature consistent with our vision and furthermore is it consistent with decisions we've made about other features? Is this feature the straw to break the camels back adding unnecessary complexity to the game? David Sirlin recently wrote a terrific article about subtractive design. The basic concept is that we should be able to identify the essence of a game and remove everything else. I think this is important when evaluating and prioritizing features. Does this really support our game's essence or are we just really attached to it because we think it's cool? Big picture thinking is a definite necessity to avoid making a bunch of inconsistent decisions that result in a kludge of a game.

Debate
As I stated before, design will be and should be challenged on a regular basis. People usually feel passionate about the game they're working on so we're regularly going to be engaged in conversations about design decisions. First, as a designer, I shouldn't be attached to "my" ideas, I should be attached to the "right" ideas. My ability to identify the "right" idea amongst the pool of ideas is what either makes me a good or bad designer. It's ludicrous to think designers are the only ones who can manufacture good ideas when everyone has them and wants to share them. So we need to consider and evaluate all ideas, choosing the "right" one based on its merit. We then have to commit to trying to making that one work. If we're placed in a position where we have to defend an idea, it shouldn't be because we "like it best". It should be due to our research into other games, the synergy between this idea and another one, or it's alignment with the rest of the game. On several occassions, I've done research, analyzed alternatives, gathered feedback from several parties, and made the decision I've felt was the "right" one. The area I've been falling short on is debating my well-researched position after the fact. It's silly, because I've done my homework, but I haven't internalized all of that data and developed solid arguments against potential detractors. This is an area I really need to focus on in the next year and beyond.

A Humble Ear
I've gone through a lot of leadership training courses in my young life, stuff in high school, ROTc, active duty military professional development, etc. A common theme is always communication with an emphasis on listening. People can easily talk about themselves, their opinions, their problems, etc. It's not hard for me to go spouting my rhetoric to anyone who will listen. Anyone who knows me will tell you I can easily steer a conversation to my favorite topic: me. But it's tough to stop talking and to start listening to someone else and their thoughts. I mentioned before that I felt designers really need to funnel a team's ideas, and being a good listener is paramount to doing this well. Three things we were always told to focus on were:

Eye Contact
Looking someone in the eyes can be difficult for a lot of people, but it's really important for creating a intimate conversation. It shows you're engaged and focused on the things they're saying, not distracted elsewhere. Obviously you don't want to freak someone out with an eerie non-blinking always tracking goon stare. You should always break up direct eye contact occassionally so that the speaker has an opportunity to relax and feel they're driving the conversation.

Body Language
Even when you're not speaking, you're communicating. You're speaking volumes about how you feel about what the other person's saying. As a designer, what message do you want to send to the speaker? You want them to know that you value what they have to say. You're processing their idea and considering it against other ideas. This is demonstrated through a lot of your body language including posture and head movement. Are you slouching like you're tired of talking or sitting up straight to demonstrate you're actively engaged in the conversation? Are you standing there, towering over the speaker in some false position of dominance? Or are you sitting along side them as peers? Are you nodding your head to show you understand or staring at the ground like you just can't wait for this conversation to end? Being a designer requires engaging everyone at your studio and gathering all the ideas and opinions about the game you can.

Reflective Speaking
One tool the Air Force stressed was speaking reflectively when someone else was talking about an idea. Basically, let the developer explain what he's thinking, then repeat it back to him or her in different terms. It demonstrates that you understand their point and that you're actually listening. If I explain an idea to someone and they just respond, "Ok," then I have no idea on whether they internalized a single word I said. Speaking reflectively allows a one-sided conversation to become two-sided with the developer coming away from the conversation knowing you really have considered their idea and opinon.

Personal Detachment
One of my biggest challenges as a designer has been compromising my own strong feelings of ownership over anything I work on with ensuring that I make the "right" decision for the game. I could invest significant time documenting and detailing a feature that I personally love and want to play. But ultimately, someone else could point out that this feature just doesn't make the most sense for the game. I have to make sure that I discount my own personal attachment to the idea and keep the game's best interests in mind. Likewise, I can't get attached to something I've invested alot of exploratory time on. Consequently, I've then had to distinguish between my own personal feelings about what's "fun" and what's "right". For instance, as a gamer, I may be in the minority in terms of preference about a certain control scheme. I need to pick the "right" control scheme, not the one I "like." Otherwise, all of my design decisions will be suspect.

Organization
In my particular case, the game I work on is large and complicated. Our team is equally large and complicated. Keeping track of everything I need to do and everywhere I need to be requires more organization and scheduling than I really like to have. I like to just "see how it goes" but that's not going to fly when you have 80 co-workers ready for design direction and pulbishers giving you a multi-million dollar budget. People want to know there's a plan. People want to know that they aren't wasting their time and effort. People want to know that their issues will get addressed in a timely fashion. More than anything, this can be solved by a great production team (like ours). But as a designer, you need to cooperate with production and buy into their organization and structure. This isn't something I've ever been good at, so it's been an interesting challenge for me. However, I am trying, working harder to organize my schedule, set deadlines for myself and work hard at meeting them in a timely manner.

Communicating Every Way Possible
Once I started designing, the first thing I learned is that no one likes a wall of text (like the wall-of-text above this). I haven't written a design document yet that I simply handed off to a developer. I consider design documents to be conversation aides. They are a tool for me when I talk with a developer and a reference point for them afterwards. When I write a design document, I'm trying to provide brief bulleted points that we can review together. I try to provide quick visual reference that will communicate an idea far better than two thousand words. But most importantly, I try to include something they can come back to once they've forgotten what it is we talked about two months ago. While written and graphical documentation can be great down the line so a developer need not rely on me, ultimately, the idea will be best communicated to them directly in person. I need to be eloquent in expressing the feature or mechanic. I'm still working on being a clear speaker about abstract ideas, but I have found that I'd be a lot better if my Photoshop skills were more advanced.

Understanding Scope
One of the things I feel I really have going for me as a designer is that I've worked as a programmer in game development and to a much lesser extent I've worked as an artist and producer on amateur projects. As a result, I can empathize with the developers. I understand that adding the smallest feature can be a significant undertaking or lead to unpredictable results. Even the smallest change can have profound effects that adversely affect larger systems. Some times developers may be apprehensive about making a change because there are a tremendous amount of unknowns. I know firsthand that it isn't easy, so it's important to do our very best as designers before work is started to avoid making changes. But I also know that the best developers want challenges (especially challenges they're interested in tackling). Sometimes, the best features come as a result of matching the right challenge to the right developer. As designers, we have to understand what features are worth challenging our developers with and which just aren't worth it.

Whenever I write something like this, I reflect on 18-year-old Brian Holinka, who really thought he had it all figured out. It almost makes me reluctant to write something like this down. But now that I'm older, the only thing I'm sure of is that I don't know everything. I have a lot to learn. But I think I'm heading in the right direction. For the next 3-days at GDC, I hope to hear alot of other people's opinions about the skills and talents they think designers should have. Hopefully in a year, I'll be able to add (or delete) to this list and I'll be a better designer as a result.

Conscientious Content Creators

2009-03-23T11:56:00.001-04:00

One of the earliest things I learned about game development is that most game artists are half-technician/half-artist. I think this is something people outside the industry, or new to the industry, might not understand. Creating wicked art content, especially for consoles, takes as much attention to memory as visuals. In a way, it reminds me of stories I hear about old game programmers optimizing every bit of code just to fit the executable on cartridge memory. Basically, we want the game to look great, but in order for it to run on a console with a poorly fragmented memory system (read: PS3), meshes need to get smaller, shaders need to be simpler, and textures need to be lower res. While there certainly remains a place for the pure artist to provide artistic direction, an artist understands how to make simpler smaller pieces look great is a true asset.

Oh yeah, by the way, not only do we want it smaller and sleeker, but a game artist needs to produce it faster too. Watching game artists get setup to work is amazing in it's own right. It's almost like watching a musician setup their instrument. They setup their tools with keybindings, scripts, macros, etc to make their workflow as efficient as possible. Not only do they need to have a skilled eye for color and form, but also the innate ability to identify redundant or repetitive tasks and find creative ways to automate them.

Of course, AAA titles require a significant amount of content. The sheer quantity of the content requires it to be labeled, organized and stored in such a way that a team of artists, designers, programmers and possibly external contractors can easily access it. I haven't been to art school, but I'm guessing it's tough to prepare people to work in such an environment, let alone establish this structure for a new project. Like everything else in this article, these intrinsic skills, so valuable to a game artist, are gained primarily from experience. Experience that can be gained from amateur or professional projects. Either way, game artists have far greater toolsets that simply creating great looking content.

Picture Albums From New Zealand

2009-01-30T16:31:00.006-05:00

Departure

Auckland

North Island Travel

Wellington

Traveling to Queenstown

Milford Track Day 1

Milford Track Day 2

Milford Track Day 3

Milford Track Day 4

Milford Sound

Queenstown

Traveling in the South Island

Fox Glacier

Greymouth

Transalpine Railroad

Christchurch

Antarctic Experience

Akaroa

Auckland Hilton

My Bungee Jump in Queenstown

2009-01-30T16:29:00.002-05:00

Long Hiatus

2008-09-09T00:22:00.004-04:00

Yikes, the last time I wrote about anything Game Design related was August 18th. I've just been so distracted with games quite honestly, that I haven't had much to talk about yet. But I can at the very least brainstorm some possible ideas for articles out loud.

Soft-lock and Adhesion: Used in most console first-person shooters to help players move the crosshair over their enemies. Soft-lock slows the look speed down when the crosshair passes over an enemy. Adhesion rotates the players look rotation towards an enemy when the crosshair is over an enemy and the player is strafing or firing
Ironsight Snap: Most prominently a feature of Call of Duty 4. When the player pulls the trigger to go to aim down sights, the crosshair is rotated so that the player aims at the nearest enemy
Fantasy Football: This is one of my non-video game hobbies that I think has taught me some important lessons about gaming in general. Specifically about persistence, statistics, anaylsis, and shit-talk
Nike+: The running shoe giant is turning jogging into an MMORPG
World of Warcraft: I had better write down my lessons from WoW before Warhammer Online comes around and I'm focusing more on what's wrong with WoW. I learned a great deal playing this game for almost two years. Persistence and measured progress being the most obvious take aways. The game did it so well (leveling) and so poorly (honor). I think Infinity Ward played alot of WoW when desiging CoD 4

So those are some good goals for content. I'm going to start pounding away at them this week to give this page some meat so that hopefully, someone will care enough to look at this stuff

Last Trip to Yankee Stadium

2008-08-30T13:42:00.000-04:00

I love the Loge. Shade, cover and no idiots.

Bus Crash

2008-08-22T13:23:00.000-04:00

Our studio was heading out on a paintball trip but our bus hit another
bus that went over the guard rail and into a ditch. No one was
seriously injured.

Very Fast Response

2008-08-22T12:55:00.000-04:00

Another Bus Crash Pic

2008-08-22T12:35:00.000-04:00

Work Rules

2008-08-19T13:46:00.000-04:00

What I Learned From Playing...

2008-08-18T23:10:00.011-04:00

Ninja Gaiden: Dragon Sword (NDS)

I've been playing Ninja Gaiden: Dragon Sword on my Nintendo DS for over the past two months. This will sound terrible, but it's the perfect bathroom game. The save points are almost perfectly paced 10 minutes of play time apart. I've thoroughly enjoyed the game and it's been well worth the money. So here are a few things I've learned from playing it.

1. Being a ninja bad ass is cool

This seems pretty self-explanatory, but obviously the point is a bit more profound. The point isn't the obvious, that I want to be a ninja, but rather that this game does an incredible job at making me feel like I'd be a totally badass ninja. I think the game's controls are really core to creating that illusion. In a way, the combat reminds me a lot of the Phantom Hourglass but a bit more engaging. In the Zelda offering, you simply tap on an enemy with the stylus and Link will attack it. I think you can also slash at an enemy, but it's far less reliable and, well, just tapping them is so much easier. Dragon Sword, on the other hand, requires you to slash repeatedly at enemies either vertically, horizontall or diagonally. There are a few combo moves in the game, but this game has created the stylus equivalent of button mashing, stylus frenzy. My DS screen is pretty scratched up as a result of this game.

However, you can perform this slash attack on any enemy on the screen at any time, and Ryu, the game's hero and player's avatar, will deftly step in that direction and perform a well animated and dynamic slashing attack. Through frantic stylus swipes, I'm guiding my katana of death from enemy to enemy in a well-coordinated whirlwind of destruction. I really feel like I know what I'm doing. This is the real point. Player's want to feel powerful and skillful when they play these games, but they can see when the game is playing itself. I really like Dragon Sword because I know when I screw up, the enemies will jump all over me. But through very simple actions, I'm unleashing some real ninja badass.

2. Repetitive actions, even when they're fun, need a fresh twist every once and awhile

I'd have to Dragon Sword falls short here. They try to switch it up with new magic spells, some unlockable moves, a new glowing sword and some explosive tip arrows, but I'm really just swiping the stylus like mad the whole time. I think they could have done some cool things with combinations of vertical and horizontal slashes that would have made the game more interesting. Even the monsters later in the game that start to block more are ultimately defeated by just swiping at them non-stop.

3. I should not play Ninja Gaiden or Ninja Gaiden 2 for the Xbox 360

I loved this game and loved fantasizing that I was this uber cool ninja. I never really could get into the idea of fighting demons all the time. I think I'd prefer uber cool assasins or other ninjas. But playing this game really made me want to play the 360 titles. But then, I made it to a difficult boss battle. I've heard legend of Ninja Gaiden having some freakishly difficult/random boss encounters.

I was ready to throw my DS at one point. I let out many yells and gasps of frustration. My wife was not impressed. No explanation would make her understand my anger with this fiend from the underworld. Of course, I eventually beat the boss and I was happy again.

But this experience reminded me that I'm 30 and not 13. Life is a lot bigger than a silly video game. Video games can be paused. Video games are their own challenge, but they are inconsequential to many other things in life. Video games are games. Simply put.

4. There's nothing wrong with frequent saves.

Some people feel like save points can result in making the game easier, but I think they end up making the game more accessible (especially on the DS). If this game had any fewer save points, I wouldn't have played it for very long. It would have been way to frustrating. Early on, the bosses were the only real challenge besides finding time to play. I would never have made much progress if the save points weren't so well laid out.

When I played Max Payne, I used to save almost every single room. I didn't have a lot of time to play games back then, so I really didn't want to waste alot of time if I made a mistake. I think planning for players to play through an area more than once is stupid. It counts on player's getting a nasty surprise they can't overcome the first time through. This is just poor design and should be avoided.

5. The Nintendo DS is awesome

This game looks incredible and plays so well. The DS is so lite and easy to bring along. It's by far the best portable system ever invented and the sales numbers back that up.

Summer in the Streets

2008-08-16T16:23:00.000-04:00

NYC closes down Park Ave for 6.9 miles on Saturday mornings on August.
Feels like, "I Am Legend"

Average Friday Night Pregame

2008-08-16T09:30:00.000-04:00

Around 7pm, beer and soul calibur take over the board room.

Wow! Email to blog has horrible formatting

2008-08-14T01:14:00.000-04:00

I'll have to look into that

Brian

Good day for Apple! Bad day for Dell!

2008-08-14T01:10:00.002-04:00

My next goal for the blog was to spend some time capturing footage from COD4, Halo and Frontlines to discuss some of the widely used adhesion and autorotation methods used in console shooters. Just last night I was explaining to someone how fundamentally different shooters are on PC and console because of the controller interface.

Unfortunately, I've had two big distractions. First, this iPhone which I'm posting from right now, has turned out to be one of the sexiest things I've ever owned. I just can't stop toying with it. I'm glad to see that what I view as it's biggest flaw, no push gmail, is widely viewed as a huge miss by google and apple. Clearly, apple wants a bigger stake in the email market.

Secondly, my Dell desktop, on which I would normally capture and write, has been fried. A stereotype-fulfilling tech showed up today and manhandled my computer. The computer was fixed when he left but died later in the day.

So go joy lately for me on the blogging front but hope to get some more momentum and solid content soon.

Brian

Mobile Blogging!!!

2008-08-12T17:11:00.002-04:00

Sweet! Blogging straight from the iphone now. Hopefuly this will mean more posts.

Brian

Infantry Algebra

2008-08-04T21:46:00.006-04:00

More Call of Duty 4 transition goodness!

My friend Dave Arata and I were talking about ironsights the other day in the context of all the actions that can occur when in ironsights. What happens when you reload? Go prone? Throw a grenade? If a programmer is going to work on an ironsights system, they are going to need to know all these details.

ACTIONS
Call of Duty 4 is easily the king of modern infantry combat on the modern generation of consoles (modern generation eh? what happened to next generation).

The game has some of the fundamentals that almost any modern infantry shooter would want. As a result, we decided to enumerate all of the actions in Call of Duty 4 we felt were fundamental.

Cook grenade - Pulling the grenade pin but holding it before throwing it
Throw grenade
Reload
Fire
Aim Down Sight - Players need to actively hold down a button to look down the sights
Sprint
Switch Weapon
Melee
Jump
Landing - When the player falls from a suitable height
Vault - If the game has some type of vaulting system
Prone
Prone Move - Moving while prone behaves differently than moving when standing/crouching
Change Stance
Climb Ladder
Moving
Enter - For vehicles or mounted weapons

Great! Now we have all the actions a player needs in a first person shooter. We can easily create a 17x17 matrix of these actions to define their relationships. But what are those relationships and how can we define them?

OPERATIONS
So what's the problem at hand? How can we define the relationships between these actions in a way that makes sense? Then, how can we translate those relationships into a language a programmer can work from (and possibly create a finite state machine).

First, we have to think about our basic formula. At any time, one action is in progress while another wants to start. So,

A - The action in progress
B - The action requested

Then, we need to define the different operations that can occur between these two actions.

Affected By

A affected by B
A and B can occur at the same time, but A will behave differently

Blocked By

A blocked by B
If B is in progress, A cannot occur

Ignores

A ignores B
A and B can occur at the same time

Interrupts

A interrupts B
A will occur even if B is in progress, B will immediately transition to A

Queued By

A queued by B
If B is in progress, A will occur when B has completed

This gives us 5 operations to build our matrix. We can start each action, then iteratively examine and note what happens when we try to do another action. A gameplay programmer can then use this matrix to develop the animation transition systems for our infantry.

Note: If you're really into algebra, you might care to notice that only ignores is commutative. In other words, if A ignores B then B ignores A.

Of course, I've created a matrix of my own, but what would be the fun in giving you everything you need after all? There are a few notable observations though:

Change Stance ignores almost everything except Sprint, Vault, Climb Ladder and Enter
Looking ignores almost everything except it's affected by Aim Down Sights
Almost everything interrupts Sprint
Vault blocks almost everything
Most everything ignores looking and moving

These relationships can help a designer write a clearer game design document for infantry movement and combat.

Ironsight Transitions

2008-08-04T21:23:00.002-04:00

After spending a bit of time looking at CoD 4's ironsights in the context of single player, I started to pay more attention to the actual transition.

They make a few changes between their From the Hip position to their Aiming Down Sights position.

Animate raising/lowering the gun to the player
Change the field of view, but blend that change over time
Increase the depth of field blur on the parts of the gun closer to the player

What I really found interesting was the order in which all these changes happen. You can see in the video above, that the animation begins ever so slightly before the field of view change.

I think this is a direct result of IW spending a lot of time watching soldier rifle their weapon. Obviously, a solider wouldn't start focusing their vision until the weapon is in their line of sight.

Of course, everything blends linearly between the two positions. The blur is applied gradually. The field of view adjusts throughout the transition. The bullet deviation, represented by the crosshair, gradually decreases/increases while the crosshair fades in/out.

Nailing this transition is critical. I once read that Miyamoto told Retro Studios that if they didn't nail the transition between the ball and first-person in Metroid Prime, then they couldn't do the game. Transitions are key to keeping the player immersed at all times.

If the player believes the transition, they'll believe the entire experience.

First post!

2008-07-29T20:04:00.005-04:00

I thought I'd start this blog off the right way, a picture of me playing drinking games on the beach in a viking helmet!

Time to get my life on the internet started.

Call of Duty 4 Ironsights

2008-07-29T00:17:00.005-04:00

I've been spending a lot of time lately looking at Call of Duty 4 and how effective their ironsights are at the most fundamental levels. The entire mechanic is polished and well thought out.

Indulge the player's fantasy that they are a professional soldier, well-equipped and well-trained, fighting in a real battle. The entire feature seems to be built around providing immersion and ease of use.

First-person shooters have a fundamentally simple mechanic at their most fundamental level: Find the bad guy, move the screen so the bad guy is in the crosshair, then pull the trigger to kill them. On the PC, where first-person shooters have always thrived, the mouse works as a natural interface for looking around. On the console, however, the analog thumbsticks are neither as precise or natural. Therefore, console shooters take a number of extra steps to help the player.

I'll discuss two techniques, soft lock and adhesion, that actually influence the look speed and view rotation explicitly in another post. For now, I want to focus on how Call of Duty solves this problem in single player.

This auto-lock and snapping technique is only used in the single-player. The console game plays radically different from the PC version in terms of controls. The player is constantly scanning, moving their view to find another target. When they are within a reasonable distance to another target, they pull the left trigger to take aim, then pull the right trigger to fire. Instead of wrestling with the controls to look at the target, it is easy and tactical.