mouthporn.net
#ongoing series – @askagamedev on Tumblr
Avatar

Ask a Game Dev

@askagamedev / askagamedev.tumblr.com

I make games for a living and can answer your questions.
Avatar

Breaking Down Testing Chamber 16, part 2: Goals

This is a follow-up post to [this post about Testing Chamber 16 in Portal].

Today, we’ll be examining Testing Chamber 16 from a more designer-centric perspective. We’ve seen and enjoyed the finished product. Now the question to answer is “How does a level designer get from a list of conceptual level goals to that finished product while incorporating and maintaining the game’s overall themes?”

Let’s identify these conceptual level goals for Test Chamber 16 first:

  1. Introduce the sentry turret to the player
  2. Give the player the first major peek behind the curtain with the “survivor room”

These two goals are really all Test Chamber 16 needs to accomplish individually. We also, of course, need to maintain the overall game’s themes. We have established these themes to be:

  1. The world is built on the [scientific method]
  2. What is being shown is not altogether genuine

Imagine that you’re a level designer and tasked with creating TC16 with the goals listed. You have all of the pieces that you can use to build the level - the glass , portal-able materials (light grey tile), non-portal-able materials (metal tile), turret objects, and the various textured decals you can place on walls and floors like the infographics, painted Xs, and so on.  How do we introduce a new element like a sentry turret to a player who has never seen one before? 

There are several different ways to present the turret for the first time, each with its own implications. For example, we could introduce the sentry turret to the player by having it face the player down almost immediately and begin shooting, along with a safe space to avoid taking additional fire. This would clearly instill a sense of danger in the player associated with turrets. We could introduce the turret via a clearly visible laser beam first, allowing the player to approach it from safety and examine it from a distance before being shot at. The presence of danger is still there, but it is not as immediate and it is not as scary. There is nothing wrong with creating encounters like this! These type of encounters are used in TC16 after all - they just aren’t the very first encounter. The first encounter with a new gameplay element will greatly affect how they view the gameplay element in the future due to the qualities of the experience that are emphasized. 

Instead of emphasizing the danger, the level designer chose to place the first turret in the game facing away from the player where the only way to take damage is by ignoring the turret completely and pushing past it. There is no way to bypass this turret without interacting with it in some way. The player may examine the turret and its attributes at their leisure, but it is also an obstacle that clearly blocks their path. If they try to bypass it, it will shoot them. Further, there is no real portaling to be done in this first chamber either. The glass and metal tiles block the use of portals, which severely limit the use. This is as safe an introduction to the turret as possible.

This is how the puzzle elements in Portal are generally presented - especially in the testing chambers portion of the game. Whenever the player is presented with a new puzzle element (like the sentry turret) and the player is encouraged (and initially forced, as above) to experiment and interact with the new puzzle element in varying ways to attempt to solve it. This follows along exactly with the theme of the scientific method. The puzzles generally add one new element to the test each time.

We should also note that each level in Portal testing chambers is a space where several puzzles are presented in a progressive sequence. Each interaction with the turrets teaches the player something new - what a turret looks like, how the turrets detect the player, how to recognize where a turret is, different ways of dealing with turrets, and ways of bypassing turrets. The experience/tension graph for the level looks something like this:

Observe that there are little tension spikes at each puzzle during the level and the stakes at each puzzle increase. 

For sake of length, we really only tackled goal #1 above - “Introduce the sentry turret to the player”. As a bonus exercise, I encourage you to consider goal #2 yourself. If you’re feeling frisky, please reblog and add your own goal #2 breakdown with your observations and analysis! As a hint, consider where the “secret” room is placed, both in the level and in the tension curve. Why put it where it is? What would be the results of placing the “secret” room at different places along the progression through the level?

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Avatar

Game Optimization Tricks (part 3) - LODs

When you're looking at what's on screen from a video game, you (as a human) tend to naturally utilize certain concepts like perspective to provide context for things like how far away things are from each other. Things farther away are represented as smaller on the screen, while things that are closer are larger. Naturally, this means that you can see things that are closer more clearly, and have a harder time seeing things that are far, far away. This is the founding principle behind the optimization concept called "Level of Detail", or "LOD".

Avatar

Game Optimization Tricks (part 2): Backface Culling

Today we continue the talk about optimization in video games and the tricks involved with improving performance. What if you had a way to approximately halve the number of polygons you'd have to draw? You wouldn't need to calculate how the light hits them, you wouldn't need to draw the textures on them, and guarantee that your player would never even notice that they are gone. Wouldn't that be great? You could use less memory and have more CPU and GPU cycles for calculating things that actually matter. This is the concept of backface culling.

Avatar

Game Optimization Tricks (part 1): What is optimization?

Today's post is about programming and problem solving. I've tried to keep it as digestible as possible, but these sorts of concepts are valuable to designers and artists in addition to engineers, because optimization is everybody's job. Poor performance will harm a game's reception more than anything else, because it affects every bit of the moment-to-moment gameplay that must be sufficient to engage the player.

Avatar

Game Development Myths: Longer Dev Time = Better Game (part 1 of 2)

Hey everybody. I wanted to start a new segment called "Game Development Myths", where I will talk a little about commonly held (but actually incorrect) myths about game development, and hopefully explain why they are actually myths and not reality. Today, I'm going to tackle the myth that a longer development time results in a better game. Only a handful of studios can really pull that sort of thing off successfully, and one of my favorite quotes on the matter comes from Aaryn Flynn, the general manager of Bioware - "Show me a game with infinite budget and I'll show you a game that never ships."

Let's begin by establishing some basic information. Most game development takes around two full years to complete. For some games this time is notably longer (MMOGs, for example), and others it is shorter (annual titles, like sports games). The Call of Duty franchise actually gets a normal two-year cycle to develop a game - Activision has two different studios (Sledgehammer and Treyarch) working on the games with staggered delivery dates, plus more support studios (Infinity Ward, Neversoft, Ravensoft) for additional content, DLC, and the like. The Assassin's Creed franchise also had multiple teams working on their games as well in order to ensure a steady flow of games each year after Assassin's Creed 2 became a runaway hit.

In order to take a full game from preproduction to certification in a year , you generally need some way to leverage old assets. This is why you see it most commonly with sports titles - they can reuse old animations, models, environments, etc. while updating and adding some new ones. The only other option is to massively swell the size of the team in order to create enough content fast enough. The problem with this is that it also massively increases costs, and demands that the game sales be astronomical, plus you run a much higher risk of burning the developers out by making them on that constant short cycle.

At this point, you're probably asking yourself: So why don't they just take longer than that? I mean, surely it would be better to give them more time to get the game right, right? 

One of the biggest issue with long development times is this - If your development cycle is longer than two years, you're risking your technology getting outdated. We've already established that the shorter the cycle, the less new content you can create. The issue of technology leaving you behind is a very real one, and I hope to explain why. The normal console life cycle is about five years, which means that each team will get about 2.5 games made over that console's lifespan. For the PS3/X360 era, you're looking at about 3.5 full games over that lifespan. If you push your development time out from 2 years to 3, that means that your first game will be released at around the time that most are halfway into their second game on the platform. This is a really huge difference, because any time you do something for a second time, you've gotten a lot more experience and learned from the first. This means that all of the experience your team had to earn building and shipping a game for a new platform comes later for the longer-cycle team, and those issues with just getting things to work on the hardware come later. Have you ever wondered why some games that come out a year or so after launch still have a lot of bugs that are reminiscent of the launch titles? it's because they are running old tech and they've been in development for a lot longer.

Most games with extended development times are quietly killed, rather than actually finished. One might point at Dragon Age: Origins or Team Fortress 2 as an example of a success story, but that game had a lot of issues and it is a testament to their teams that they managed to pull it all together. Let's take Dragon Age as an example here. The Dragon Age team took 7 years to ship their game. When they began, they were using the Neverwinter engine to work, and had to switch technology partway through because it just wasn't good enough. Even more importantly, the development was started at around the heyday of the Playstation 2, back in 2002. By the time they released, they were 3 years into the lifespan of the Playstation 3. Over that course of time, many huge changes came to the gaming world - the rise of Facebook and social media, the rise and fall of Guitar Hero, World of Warcraft obliterating all expectations in the world of MMOGs, Call of Duty going from an ok game to a phenomenon, and so on. It's pretty clear that they didn't choose to schedule development for 7 years - they built something, it didn't pass muster, they tore it down, and they rebuilt it... and that's what they did for years. Eventually, the game managed to ship and it even went on to be a success.

But for every Dragon Age, there are many failed games that couldn't manage to pull it together after that constant cycle of build, fail, rebuild. It's really hard to get continued funding from publishers when the studio has to show them a work-in-progress that isn't even close to good enough to sell, and instead they need a lot more time and money to get it to that state, especially when there's no guarantee that the market will be the same when the game finally does ship. Does anyone remember the game Warcraft Adventures: Lord of the Clans? It was a game that Blizzard started shortly after they shipped the Warcraft 2 expansion pack, and they had some issues and delayed it. But the delay was critical to the failure of the project, because the game just... wasn't right for the market anymore. In order to make the game that it needed to be, they realized that it would take a lot more content - more animation, more voicework, more developer time. The game was already looking dated by that time, and they didn't think that they could make (or sell) a good enough point-and-click Warcraft-themed adventure game by the time the game reached shelves (late 1998) that they cancelled it. Similar stories exist for their failed Starcraft: Ghost game as well. 

Technology for games is a strange thing, because most customers don't notice the better changes going in, but they do if you try to go back to older content. It's never just one big thing, but think back to how fuzzy everything looked in SD, how characters' hands used to just be basically mittens, the old sort of weird angles and low polygon blocky people, and the like. It's easy to dismiss, but even if you don't necessarily objectively see a difference, your subconscious certainly sees it. That's why going back to play old games make them seem a lot more "video gamey" than the newer ones. When you go back, you start to miss the things you have grown accustomed to, and it translates to a feeling of general discomfort, even if you aren't sure why.

Next time, I'll continue talking about why a longer development time doesn't necessarily equate to a better game. The dreaded schedule, and why adding extra time doesn't always make sense financially.

Got a burning question you want answered?

Avatar

So you want to be a game designer... (part 2 of many)

Another of the common questions I get from would-be game designers is how to become better at designing games. Today, I'll share some exercises for any would-be designer to try flexing your creative design muscles.

#1. Play a lot of games.

This should go without saying, but any designer worth his or her salt should play games. A designer should play a lot of games, and as many different genres and platforms as possible. This means playing games that you may not actually enjoy. This also means good games and bad. I can't count the number of designer wannabes who come up to me and ask me about becoming a game designer, and then scoff when I tell them to play mobile and tabletop games.

"But I don't want to make mobile, board, or card games! I want to work on MMO/FPS/RTS/RPG/Fighting/Sports/whatever games!" they inevitably say. I cannot emphasize enough how important it is to understand that you need breadth of experience, especially if you’re starting out. 

Once upon a time, as a camera engineer on a project I worked on, I was looking for a way to reinforce to the player that (s)he had actually pressed a button and did something. Sure, the player's avatar on screen would start an animation, but some animations have longer start-up time, others needed time to blend from whatever they were doing, so just playing an animation wouldn't give that instantaneous feedback that the player would want to see, if only on a subconscious level. That response time is the difference between a game feeling responsive and a game feeling sluggish. But all I had were camera tricks. How would I reconcile the problem with the solution?

I found the answer in Street Fighter 4, actually. Take a look at this video:

Do you see the camera work here? If you look closely, whenever Akuma connects with his heavy hit attacks, the camera will actually zoom in slightly. Look at the lines on the floor for reference when the hits come. You'll see them shake when the heavy hits land, and stay mostly smooth between hits, or when the weaker strikes land. In the game I was making, I added a similar camera zoom effect that got triggered when the player pressed the button and performed the action, which resulted in a better-feeling experience. The players may not consciously notice, but their subconscious certainly did.

It's incredibly important to try playing a lot of different games, and figuring out how and what it is they do can help. Each new feature you come across can go into your mental toolbox for exploration later. The more you experience, the better prepared you are to handle the unknown.

This will lead us to exercise #2.

#2. Play games analytically.

When a designer play any game, (s)he should always think about what choices were made, and why they were made. Everything that a player interacts with in the game is deliberately placed there. Most decisions outside of bugs were a conscious choice by somebody, and as a designer who is analyzing another's game, you get to play detective as to why they chose to do this.

It's also important to look for things and features that games do well, even if the game itself is not good overall. Even if the game is awful, it still represents a significant amount of a entire team of developers' lives, often for months or years. It's also almost impossible that anyone out there would purposely set out to make a bad game. They spend weeks, months of their lives working on this every day. There's no reason that developers would subject themselves to that sort of punishment for little reward if they didn't like what they did. And believe me, the vast majority of game developers are not paid exorbitant amounts of money.

Go into each game trying to identify its good features, and try to figure out why it works. The feature doesn't have to be huge, it can be as small as a camera shake whenever a fierce attack hits an opponent. Maybe it's a camera system that works well. Maybe it's some UI elements that work. Perhaps it's something in multiplayer that they did well. Learn from them. Use them.

So here I'm going to give you aspiring designers a homework assignment. You don't actually have to turn it in, but it's a good way to get some practice in doing some actual game designer work.

I want you to play a game in a genre you normally don't like or care for, and I want you to identify at least 3 features (big or small) that you think are good, along with why you think they are good, and what changes might be needed to use them to improve an existing game you do like. I would suggest mobile or facebook games, card games, board games, or PSN/XBLA type downloadable games. You don't have to play it exhaustively or even finish it. Just play enough that you learn what it's doing and how it is doing it, and look for the good features in it.

Avatar

So you want to be a game designer... (part 1 of many)

I get a lot of questions about what it means to be a game designer, and how someone can get that job. I also get asked by a lot of people just what a game designer actually does. A game designer has many duties, and it's the designer's job primarily to answer questions. Questions like:

  • How much damage does this attack do?
  • What happens If the player is spotted by the guard?
  • If the character has to block incoming attacks, what happens when two enemies attack the character from both the front and the back at the same time?
  • What if the player kills the boss before it can finish its death monologue?
  • Are these feathers big enough?

It is typically up to the designer to come up with not only answers to these types of questions, but the questions themselves. The designer then writes documents which explain to the readers how the game system/area/mechanic/etc. works. The documents are most important because the goal is to have the people who read it not need to ask any more questions about how to create the feature in the document. While this starts off seemingly pretty simple, it can get complicated very, very quickly. 

Let's take an example to help illustrate this.

Let's say that you were tasked to design a stealth system for a simple game - the player is a thief who is sneaking into a warehouse full of crates and guards, and need to retrieve a file from one of the rooms. Your goal is to find the room with the file in it, take the file, and exit the warehouse. Simple, right?

Or is it?

So we'll start with a very simple design. Guards either know you are there (state: AWARE), or they don't (state: IGNORANT). Guards who are aware will chase you. Guards who are not will continue on their pre-set guard paths. That's a very simplistic design. But it doesn't really feel stealthy, nor does it feel like the guards are believable. So let's begin breaking down why it doesn't really feel good.

What happens when the guard doesn't see you any more? In reality, a guard who spotted an intruder, then lost sight of that intruder would probably remain suspicious. That guard might call for help. So what this means is that we need a third state - SUSPICIOUS. If the guard no longer has line of sight to the thief, the guard must go into the SUSPICIOUS state, and sets all nearby guards into the SUSPICIOUS state as well. When they are suspicious, they will check around more corners and potential hiding spots.

But what if the player actually gets seen by a guard? Maybe he gets into a fight? Now the guard should be concerned for certain. Some unknown just showed up, beat him up, then ran away. Will he call for help? Will he behave differently than he would if SUSPICIOUS? Maybe this needs a new state, like ALERTED. But it's still got to be a different state than it would be if the guard has visual contact with the thief, right? Because then the guard would probably try to subdue the thief. Possibly call for help. Maybe the guard would be afraid if the thief had already taken out several other guards, and he would wait for backup.

You can start to see how creating a system like this can quickly spiral into extremely complex scenarios. Then you have to factor in logistical questions like:

  • How long would it take to get something like this written and scripted?
  • What sort of support would I need from programmers and artists to do this?
  • How can I create tests for this feature to make sure everything is working right?

It's extremely important to be able to answer these sorts of questions before they come up, and think about these sorts of constraints. There are often many constraints on the creative process as well, and they must be taken into account when designing a system. Here are a few examples:

  • The engine can only support 10 fully animated characters on screen at once before the frame rate drops
  • The license-holder has a checklist of things that the character absolutely will not do
  • The feature development time must be shorter than four weeks, because your boss needs you to move on to another more important feature after that.
  • How will this feature work in multiplayer?

I expect that some of you haven't really thought about questions or answers to questions like this. It's a lot of what goes on as a game designer - coming up with questions, answering them, and writing them down in a clear and concise way such that somebody who reads them can understand what is going on without needing to ask you further questions to clarify.

The most important qualification to being a professional game designer isn't actually creativity. It's always, always, always excellent written/verbal communication skills. Check any job description, and you'll for sure see that at the top of the list. Ideas, even great ideas, are a dime a dozen, but being able to communicate those ideas to others who don't have your brain is a much more difficult endeavor.

You are using an unsupported browser and things might not work as intended. Please make sure you're using the latest version of Chrome, Firefox, Safari, or Edge.
mouthporn.net