'The Door Problem' of Game Design

An anonymous reader writes "Game design is one of those jobs everybody thinks they can do. After all, they've played a few games, and they know what they liked and disliked, right? How hard could it be? Well, professional game designer Liz England has summed up the difficulty of the job and the breadth of knowledge needed to do it in what she calls 'the door problem.' Quoting: 'Premise: You are making a game. Are there doors in your game? Can the player open them? Can the player open every door in the game? What tells a player a door is locked and will open, as opposed to a door that they will never open? What happens if there are two players? Does it only lock after both players pass through the door? What if the level is REALLY BIG and can't all exist at the same time?' This is just a few of the questions that need answering. She then goes through how other employees in the company respond to the issue, often complicating it. 'Network Programmer: "Do all the players need to see the door open at the same time?" Release Engineer: "You need to get your doors in by 3pm if you want them on the disk." Producer: "Do we need to give everyone those doors or can we save them for a pre-order bonus?"'"

Comments

Will the door have windows?

[ciderbrew]

I'd like little windows so people can see into the next room. These are always missing in games.
ALSO, I want to shoot something through the doors and blow them up with things.
#FeatureCreep

Re:Will the door have windows?

[ciderbrew]

I'm going for a manager vibe. I've read the word json somewhere and I think all company use of HTML should in the Json now. So if you could just implement that and fill out this TPS report that would be great.

Re:Will the door have windows?

[Assmasher]

I love that "Feature Creep" is both adverbial and can be a noun. "Oh, look, it's the feature creep..." ;)

Re:Will the door have windows?

[ildon]

Doors infrequently have windows in video games because they are used to block visual information from the renderer and gameplay information from the player. But doors with windows do exist. Even Half-Life 1 had some.

Re:Will the door have windows?

[ciderbrew]

If you're going to disprove my point with facts and logic that's unsportsmanlike.

Re:Will the door have windows?

[BasilBrush]

I don't think so. What makes a good simulation of real life doesn't tend to make for a good game. Real life is mostly boring, which is why people turn to games in the first place.

There are categories where maximum reality is desirable, but they tend to have "simulator" in the name. Flight Sim, Formula One Sim, Train Sim, Theme Park Sim.

But what people usually want in games is problems to solve, and/or skills to develop, to make progress, all at a level that tests their ability at nearly all times, but doesn't overcome them. And trying to be more realistic only limits the amount to which you can do these things.

Take the article's example of a door, and the question of how you can tell if it's a locked door or not. In reality, you can't tell whether a door is locked without trying to turn the handle and push it. But in games it's usually better if you can tell by looking whether a door is unlocked and openable. There are plenty of games that go for the reality route, and you have to try to open all the doors to find the openable ones. And it's a tedious task that rarely adds anything to the gameplay.

Another example is the concept of health levels, multiple lives, and re-spawning. Remember the US army created a game of their own called "America's Army". It was as realistic as the could make it, including the fact that you get shot once, and you are dead, and you couldn't rejoin the multi-player game until it was over. And that made it a dull game, as you typically spent half the time waiting rather than playing.

As you say, you like Metroid (I guess Metroid Prime?) which was far from realistic. But yes, a great game.

Re:Will the door have windows?

[BasilBrush]

It's funny. In he intervening years, text adventure authoring has come a long way. It's now possible to create games in a near English functional programming language.
http://inform7.com/

BUT the games compile down to the age old Infocom game file format, and so are limited to the ancient concepts of wandering between rooms and manipulating objects. And whilst the range of user input that can be understood has expanded, it's still just combinations of "verbing" and "object" or moving by compass directions.

Still, some authors have managed to be creative even within this limited game engine, and create games that don't APPEAR to be simple rooms and objects games.

I wonder, would a truly unlimited interactive novel be fun to play? It could be tested out by a kind of Turing test scenario. Have a player play such a game, and have a real novelist provide the "game" text. Of course such a thing would entail the player waiting a considerable time between "moves". But it would mean that their input would be boundless, they could do anything in the "game".

Considering how hard it is for most authors to get things published and make a living whilst they are writing, this might even be a feasible real way of gaming, allowing authors to make a small income whilst doing their chosen activity. Though it would need to be a pay-per-move system.

Re:Will the door have windows?

[nine-times]

I wonder, would a truly unlimited interactive novel be fun to play? It could be tested out by a kind of Turing test scenario. Have a player play such a game, and have a real novelist provide the "game" text. Of course such a thing would entail the player waiting a considerable time between "moves". But it would mean that their input would be boundless, they could do anything in the "game".

Well when I've thought about it in the past, I imagined it a bit like having an old-school D&D game with a dungeon master. Of course, that'd be a hard thing to do.

I always loved the old text adventures, but it's annoying that they were restricted to canned responses. You might come up with a great solution to a problem, but if it wasn't what the programmer had anticipated, you'll get get a message saying something like, "I'm sorry, but you can't do that." I would think coming up with something that allowed you more freedom would be an interesting problem to tackle and a good challenge for an AI researcher.

Re:Will the door have windows?

[minstrelmike]

People play games to avoid real life because it is boring.
ditto for movies and books. The reason "literary" stuff is boring is because it's too much like real life where nothing interesting happens.
Books that sell are full of violence and sex.
If you want any excitement at all in real life, you've got to troll the slashdot comments.
And if you want sex, you need to learn to type one-handed ;-)

Re:Will the door have windows?

[internerdj]

We have a feature creep here. She creeps into your office and suggests features in your project and talks non-stop until she's pitched her whole idea and creeps back out.

Re:Will the door have windows?

[CptPicard]

There is also a legendary internet phenomenon with kinda your surname. I would not recommend googling for it.

Re:Will the door have windows?

[Quirkz]

Good one. I'm stealing it and putting it in my novel about a parody dungeon crawler video game. I'd give you credit, but, frankly, "Thanks to Assmasher" isn't something I'm willing to put in print. Er, a second time, since I guess I just said it once.

Article is empty

[Noughmad]

The article doesn't really say anything. For starters, it took me a while to realize she's talking only about computer games, and then even more specifically only about first person adventures / RPGs. From what I understood from the list of problems, I got that you decide on game mechanics and then generally boss people around.

Re:Article is empty

[GrumpySteen]

Bring an axe to work.

You may not keep your day job for long, but you can wreck the hell out of some doors and go out in a blaze of glory.

Re:Article is empty

[O('_')O_Bush]

I couldn't distinguish her "doors problem" from any other mundane problem in a complex system that some of us deal with every day.

Re:Article is empty

[tepples]

Perhaps the door analogy is her way of expressing what it's like to have a "mundane problem in a complex system" to someone who has never faced a system as complex as a video game.

Re:Article is empty

[joshuao3]

Which is the authors point. A programmer, not just a person who programs, has a special way of looking at the world and its systems. The conversation she's having with people is designed to separate those two kinds of people. Systems are generally more complex than they appear on first glance--and a real programmer is very able to visualize, define, and describe the system to whatever level of complexity is required. That being said, a GOOD programmer (and his manager) is able to keep feature creep in check by not getting distracted by out-of-spec parameters.

Re:Article is empty

[bzipitidoo]

She skipped right past the first parts of game design to focus on minutae. Made good points, but about implementation details, not game design.

What game designers must do before worrying about doors is, well, design. What is the game about? Killing bad guys? Racing against competitors? Collecting money or points? Solving puzzles? Exploring worlds? Building things? The tricky part is picking the mechanisms. The question isn't which doors are supposed to open or have windows, it's whether doors are an appropriate and fun method to make reaching the goals, whatever they are, challenging without being impossible. Or they are a necessary evil to deal with limitations.

To find out if a game play element is possible and balanced and fun requires analysis and testing. It can be done in an agile way, making some elements, testing the game play, then making changes. For one example of unbalanced games, can look way back to the early Ultima games. In Ultima 2 and 3, the heroes were so powerful they could easily kill all the non-player characters in an entire city, without consequence, because to reduce memory usage on the computers of that era, the design simply loaded the initial state every time a city was entered. (Not that they couldn't have easily set aside just one bit, an "evil bit", to track whether the heroes were no longer heroes, but for whatever reason, they didn't.) Consequently, an easy way to get more money was kill the enitre town and take all the treasure, exit then reenter and do it all over again, until the player was satisified with the haul of loot. Tedious but effective. Not what the designers wanted, I'm sure, but they did go so far as to make the best of the problem by making a few towns especially juicy to loot. Ultima 3 especially was criticized for being too easy.

Or, design is often done in an ad hoc manner. As an example, many fantasy MMORPGs have a crafting system which the players can use to make equipment. These are a sideline to the main goals of progressing through the fantasy world, doing quests and gaining levels. The way MMORPGs implement it, crafting is dull, tedious, and limited. The players can't employ imagination to create novel items, they are restricted to a small set of fixed recipes. The game designers couldn't allow much latitude on crafting, or the players could and would make items so powerful that they completely unbalance the main game. It'd be rather like crafting and using machine guns, while the rest of the fantasy world continues to use swords and bows. Or the whole fanatsy world advances, and then it's not fantasy anymore. A crafting system that is just a little more realistic could inadvertently allow such things. After all, in real life, what stopped the people of the Middle Ages from having guns? Lack of knowledge, nothing more. The players will all know about modern technology, and will not be held back through ignorance, so the game designers have to resort to other methods. Science Fiction is not much help. A crafting system that allows novelty could likely still be used to break the game.

RPG Games

[fatp]

Most RPG Games I played have large number of fake doors.

Re:RPG Games

[ciderbrew]

A good thing. I'd have to open every door in the game. I don't have OCD. OCD.. OCD... O.C.D.

Re:RPG Games

[SJHillman]

It's A Long Way To The Top, If You Wanna Open Every Door

Re:RPG Games

[Remus Shepherd]

I spell it CDO, because it doesn't annoy me as much when it's in alphabetical order.

Re:RPG Games

[schlachter]

You: Walk to door.
Game: You arrive at the door. It looks heavy and old.
You: Open door.
Game: You can't, this is a fake door.

um

[Charliemopps]

Those issues sound like any feature in any other software project I've worked on...

Are there "Save" buttons in your application?
Can the user click them?
Can the user click every button in the application?
What tells a user a button is click-able?
What happens if there are two user?
Does it become read only after both users click it?
What if the UI is REALLY BIG and controls can't all exist at the same time?'
'Network Programmer: "Do all the users need to see the record save at the same time?
Release Engineer: "You need to get your buttons in by 3pm if you want them on the disk.
Producer: "Do we need to give everyone those buttons or can we save them for phase 2?

Re:um

[91degrees]

Not really. Not unless your application has hundreds of save buttons, some of which are purely there for decorative purposes. And most applications don't have multiple users sharing a UI.

For app design, all these are solved problems. The typical answers are "yes, usually, yes, unclickable buttons are faded, the first user has a lock on the file, no because that would be stupid, your UI is too complex, yes, ???, we need the save button in phase 1".

With a game, I've seen different answers for all of these.

Re:um

[thesandtiger]

This article isn't for actual software engineers, but "idea guys" who think making games is easy and don't actually understand what goes into real game design.

I know a ton of people like that - they have an idea for some awesome next level stuff, but it's only a very vague idea with a few neat things in there, without any of the actual work that is needed to turn it into a game design, let alone a spec, let alone a game. Seriously, everyone I know who is a gamer and not an engineer is constantly babbling about how games should do X or Y or Z or whatever, but when you ask them questions about how any of it would actually work, they wave their hands and say it isn't important because the IDEA that they took a whole 30 seconds coming up with and articulating is somehow the hard part.

The idea is the easy part - I can toss out hundreds of ideas for games that would be amazing. Turning that amazing idea into anything resembling a useful thing is another kettle of fish entirely.

Easy answers

[DeathToBill]

I'm not convinced by TFS. The answers are, roughly:

1. 1. Are there doors in your game? Let's say for the moment there are.
2. 2. Can the player open them? Yes. If you have doors in a 3D game and they don't behave like doors, you have failed.
3. 3. Can the player open every door in the game? Yes. See point 2.
4. 4. What tells a player a door is locked and will open, as opposed to a door that they will never open? It's a door. It opens.
5. 5. What happens if there are two players? Doors behave the same for all players. It's a door. See point 2.
6. 6. Does it only lock after both players pass through the door? See point 5.
7. 7. What if the level is REALLY BIG and can't all exist at the same time? Then your technology is not good enough to implement your vision and one or the other needs to change. See point 2.

Am I the only one who finds arbitrary restrictions in games, either because the technology couldn't cope, or because the game designer knows how you want to play better than you do, or just because, really annoying? If there's a door there, it should open. If it won't open, there shouldn't be a door there. How hard is this? Putting a door there that's never going to open just frustrates the player and destroys the suspension of disbelief. It reminds them that they're not really in this world they can see, they're in some arbitrarily limited construct devised by a "product manager" at some company to try to screw a few bob out of them. Of course there need to be some limits on the world, because the technology isn't infinite; good game design should make those limits look natural so that the player never even notices that the limit is there.

Tomb Raider games are amazingly annoying - some things you can jump and grab, some things you can't. The only way to tell is to jump and try grabbing it. If it doesn't work, maybe you can't jump and grab that thing, or maybe you just didn't quite get it right. I know, I know, this is not the point of Tomb Raider games, Lara is, but still...

Re:Easy answers

[mwvdlee]

I like your world where no locked doors exist; it's so very much like reality where I also need no keys to unlock doors.
Also in reality nobody can ever block a door. If somebody else (let's call him "player 2") blocks the door from opening, I'm still able to open the door. Because "It's a door. It opens", the door will magically pass right through the other person.
Also; what is behind every opened door? If there are doors behind an opened door, they should open too, right?

In my world, a locked door is normal. How can I see if a door is locked in real life? If it has a hole for a key and closed, it's probably locked.

Re:Easy answers

[Drethon]

It has little to do with technology coping and how you implement these behaviors in code in a way that works smoothly and consistently.

So what I read is you think the "technology" should be able to implement reality? "Technology" does not exist, code written by humans does and writing this code takes time. Say it takes ten hours to implement code for a non realistic door to be coded up, a hundred hours for a fairly realistic door to be implemented and a thousand hours for a completely realistic door. Is the developer going to go with the simple door that cost $250 to implement and makes most users happy or the complex door that cost $25,000 to implement?

Now look at the fact that that door is 0.001% of the total complexity of the game. If the entire game is implemented with the same complexity, how many people have to buy this $2.5Bn game for it to be profitable?

5. What happens if there are two players? Doors behave the same for all players. It's a door. See point 2.

Great, it behaves the same for all players. Does that mean when one player unlocks the door it always remains unlocked for everyone or do we have a door that automatically relocks after it is closed? Say access to an area is restricted as part of a high level quest. When one player completes the quest after hours of questing and gains access to the special area we want all players, including those who just started the game, to be able to enter this hard to attain room?

It isn't just about making a door behave like a door, its a question of what does this door mean to the whole game, what does each door mean to the whole game?

Re:Easy answers

[Dan East]

If there's a door there, it should open. If it won't open, there shouldn't be a door there. How hard is this? Putting a door there that's never going to open just frustrates the player and destroys the suspension of disbelief. It reminds them that they're not really in this world they can see, they're in some arbitrarily limited construct devised by a "product manager" at some company to try to screw a few bob out of them.

What kind of world do you live in that you're able to open every single door you see? You actually believe that is realistic? Especially for games like the original Half Life, set in this huge commercial / industrial type top secret research setting. I would expect that EVERY door would be locked by default!

Re:Easy answers

[Thruen]

This is a huge problem for me in exactly those types of levels. I do want to open every door, every single one, and I very rarely can. Admittedly, my favorite games are open world games which shouldn't have many areas inaccessible to the player, but I also play shooters and want the same thing. Battlefield 4 is full of elevators that only go from the lobby to the top floor or roof, I want to get out on the 32nd floor and kick the door in to the corner suite and set up my rifle where I won't immediately be spotted, taking that option away never makes sense from an immersion point of view. It only makes sense from a technological point of view. Does it create the possibility that 64 players will be roaming room to room with silencers in a hotel while ignoring the rest of a large map? Yes, and that's perfect. The previous post is entirely correct, while doors are important these questions are easy to answer.

Don't get me wrong, I believe game design to be rather difficult, but this is a poor attempt at explaining why. "The Door Problem" is not nearly as difficult as budget problems, working within technological limitations, or keeping a coherent storyline while letting the player make meaningful decisions. I speak from years of experience, in unrelated fields but experience none the less!

Re:Easy answers

[FlyHelicopters]

In the world of Half Life where there is an emergency and aliens are invading and I have a gun, I can open more or less any door, one way or another.

Normally shooting open doors is frowned on in polite socity, but that same socity understands when shooting open doors during an alien invasion.

What is REALLY stupid is to give me a rocket launcher that can't destroy glass walls.

Re:Easy answers

[QuasiSteve]

As I have been playing this game lately (friend invite)

2. Can the player open them? Yes. If you have doors in a 3D game and they don't behave like doors, you have failed.

Or succeeded - not every door in real life can be opened.

3. Can the player open every door in the game? Yes. See point 2.

Not necessarily.

4. What tells a player a door is locked and will open, as opposed to a door that they will never open? It's a door. It opens.

Unless the door knob is missing. Then it doesn't open - and every player realizes this visual cue pretty quickly.

5. What happens if there are two players? Doors behave the same for all players. It's a door. See point 2.

Agreed.

6. Does it only lock after both players pass through the door? See point 5.

Except for certain doors that require all players to have passed through. The door opens/closes just fine, but only locks if all players are either in the room, or outside the room but dead. How do players know? It's written on-screen - but after a while, people just know.

7. What if the level is REALLY BIG and can't all exist at the same time? Then your technology is not good enough to implement your vision and one or the other needs to change. See point 2

Or you load/save as applicable and call each section stages/chapters.

The game? Left 4 Dead 2.

Now, should all games be designed that way? No. But it's certainly a solution to the problems put forth, and fits within the game's overall design.

Re:Easy answers

[Anonymous Coward]

Sorry, DeathToBill, but you failed her test.You're making the classic wannabe game designer mistake of putting technical issues and your interpretation of realism above all else, because you don't like "arbitrary restrictions." So, so many games have failed because of designers who thought that way.

What you're saying is that you can't build a game with doors unless they're all openable and there's actual stuff behind them. For starters, that just blew your level design budget by 2x, so you need to trim somewhere else to make that back. Second, you don't want players getting bored walking into all these useless areas that you added just so there wouldn't be unopenable doors, and now you need to work that area into the game design itself. Your scripting budget has just gone up substantially.

While one person has a hang-up about doors, other people will be obsessed with arms clipping door frames (requiring some kind of IK solution), that you're putting things into a backpack that wouldn't fit in real life, and others will hate the fact that cars have infinite petrol. The end result is you make an unfun mess that a couple of purists praise as "realistic."

Re:Easy answers

[SirSlud]

For all practical purposes, you're probably within 40 feet of a door that can never be opened. Or let's go the other way - hey, given enough time, you could probably find a crane and a wrecking ball, and destroy the building you're sitting in. Therefore, games without fully destructible environments are frustrating to you, because in real life, you can destroy everything? That's a silly line of reasoning. You're marking the line between what is reasonable and unreasonable that is clearly out of whack with the majority of players who accept that some level of suspension of disbelief is required in order to enjoy a video game. Game design conventions and art design directly addresses the concerns you're laying out in the vast majority of games with visual cues as to which objects are interactive and which are not. Anybody can be obstinate about those conventions, but to argue the point without acknowledging that they are a standard part of game and art design is being utterly disingenuous.

Re:Easy answers

[ausekilis]

These answers are short-sighted and don't get to the real questions a game designer should be asking. Lets look a little bit closer:

1. Are there doors in your game? This is really asking about portals from one area to another. Do a web search for an analysis of the Doom 3 source code and you'll see what I mean. Is your game broken into logical sections and how do you navigate between them?
2. Can the player open them? This is really asking if there are restrictions in place to prohibit free movement in the game world. Doom had key cards and colored doors. Mario has Pipes, paintings and stars, etc... Zelda is famous for "soft locks", where you can see something, but you need a new ability to get there, like the hookshot or bow and arrow.
3. Can the player open every door in the game? This is more of a visual style question. Again with Doom and the doors, some did not open, such as the one you came through to get to the beginning of the level (the ugly flat silver doors). Uncharted, Tomb Raider, Resistance, and even Halo are intended to take place in a beleivable world. All of them have a point A, a point B, and a path between them (sometimes 2 or a really wide path). Would you honestly want to go into every single building, every single floor, every single room in Saints Row? Infamous? Crackdown? GTA? Assassins Creed? Do you have any idea how long the development time would be? How much storage space you'd need to store an entire city the size of Brooklyn?
4. What tells a player a door is locked and will open, as opposed to a door that they will never open? This is a question about visual queueing. AVGN had an episode on Aliens that touched on this, the doors weren't distinguishable from ones that opened and ones that did not. Castlevania Simon's Quest was actually pretty good about it, open doors could be entered, closed doors could not. Gears of War had little green lights over doors that could open, particularly those that the player was supposed to go through.
5. What happens if there are two players? In Doom, if the door was open any player could pass. If they didn't have the key, the door didn't open. Simple. Resident Evil 5 allowed players to go through almost any door, only a few required teamwork.
6. Does it only lock after both players pass through the door? In Doom, no. In RE5, yes. In Gears of War, sometimes.
7. 7. What if the level is REALLY BIG and can't all exist at the same time? This is really a question of separation of media within the game. How do you handle having too much for your 2GB of RAM? Do you simply crash and tell the user they need to buy more RAM? Do you detect that limit and begin streaming? Given that almost every PC is separate, distinct, and unique from almost every other PC, you can't possibly know exactly how much video RAM or system RAM a user may have. Best you can do is "minimum suggested", which in many cases is only going to store a fraction of a level. Castlevania SOTN did this very well, those odd rooms with no music were loading rooms. No loading progress bar, no "Please Wait". It would load a good portion (if not all) of the area (e.g. Marble Gallery) into memory and let the player muck around. In other games the loading may just be of the needed textures, while only loading the level geometry for the immediate large room. To say "Your technology is not good enough" is taking an elitist approach to design. An XBOX360 is not capable of loading the entirety of Gears of War 3 into RAM all at once. Most computers aren't capable of loading the entirety of Skyrim into RAM all at once. WoW is over 20GB, compressed. Uncompressed who knows, but Windows is not going to allocate that much RAM to a single process, not when you also have web browsers, music, youtube, netflix, whatever loaded too. The doors provide a logical separation of data, I believe that in many cases they are used to queue the game engine to drop one set of textures/geometry and load in another.

Re:Easy answers

[Chris Mattern]

In real life, there is no such thing as a door that won't ever open,

But as far as the game is concerned, a door that won't ever open is just a door that won't ever open *for you*, and the real world is full of those.

Re:Easy answers

[ildon]

First of all, you've failed to understand the premise of the article. The article is not intended to answer any of those questions, it's meant to communicate to the reader that these are all considerations that have to be made not just for a simple and seemingly obvious object like a door, but every single object and potential object in a video game.

As for your assertions:

> 2. Can the player open them? Yes. If you have doors in a 3D game and they don't behave like doors, you have failed.

False. When you walk down the street in your neighborhood, do you walk up to every single door trying to open it? No. You ignore 99% of the doors you pass in real life. They can usually be opened, but it's often not relevant or important to you that you open them. If a door is not relevant to gameplay, but your environment is one that in real life would contain a lot of irrelevant doors, then it's expected and correct to put a bunch of false, graphical-only doors to make the environment feel more familiar and natural. The important part, and what's alluded to in the article, is that you create a clear visual logic for the player so they can recognize which doors are important and openable vs. which ones are just there to make the environment look more interesting.

> 5. What happens if there are two players? Doors behave the same for all players. It's a door. See point 2.

Again, it's not about how it should work, but rather that you have to consider every possibility and account for it. If you create a door with a set of states and triggers, but only consider one player, then the second player could potentially cause problems with the state by triggering states out of order in a way that a single player could not. If, for gameplay reasons, you want the door to immediately lock behind the player to trap them, and you introduce a second player who does not pass through the door when the first does, you have now separated the players and potentially prevented one of them from participating in your gameplay encounter because you forgot to consider there might be a second player in your multiplayer game.

> 7. What if the level is REALLY BIG and can't all exist at the same time? Then your technology is not good enough to implement your vision and one or the other needs to change. See point 2.

Most games these days stream level and texture data from disk rather than keep it all in memory. This allows more complex scenes in each area and disguises or obviates load screens. Doors can be a good way to section those areas off and control the flow so you can optimally stream that data from the disk without the player noticing. The scope of the project could be fine, but now the level designer has to design his levels with this aspect in mind. The design has to be understood all the way down the line, from project lead to engine programmer to level designer to quality assurance (so they can try to break it in a way a customer might accidentally break it) in order for the result to prevent this from becoming an issue in the final product.

It's not that hard to develop a visual language within your game to make it clear to the player which objects are interactive and which are not. That's why some of the questions in the original article are things like "Do you put rubble in front of a door to indicate that it won't open?" It becomes a clear visual metaphor for the player that doors with rubble in front do not open, and ones without rubble do (or at least can given proper conditions). For your ledge grabbing example, all you have to do is look at the Uncharted series. Climbable ledges in Uncharted have a distinct color and texture that makes them stand out from non-climbable ledges. This is *exactly* what the article is talking about. You didn't know which ledges in Tomb Raider were climbable because their visual metaphor failed to inform you of which ones were climbable and whi

Re:Easy answers

[nine-times]

If there's a door there, it should open. If it won't open, there shouldn't be a door there. How hard is this? Putting a door there that's never going to open just frustrates the player and destroys the suspension of disbelief.

I don't know if I agree. Games are, in many ways, about presenting the player with illusions. If you have a big open world, you might put stars in the night sky with no way to reach them. The stars aren't really there, and you're artificially limited to traveling along the ground, but you're being presented with the illusion of being immersed in a complete world.

For another example, in the Grand Theft Auto games, there were many buildings that the player couldn't enter, but a few that he could. Should they have gotten rid of all the buildings that couldn't be entered? Then you have a big empty world.

With doors, I think it's often stupid to add doors that can't be opened, but sometimes that's part of the game-- to find out which doors can be opened. Sometimes it's just adding texture so that you can imagine that there are many things beyond those doors you can't open, adding to the realism and immersiveness of the game. If you're going to add doors that can't open, then the person designing the video game needs to make sure that they play the appropriate role in the game. If you're supposed to know that you can't open the doors, then there might be an appropriate visual cue. If you're supposed to try to open them, then you don't want an obvious cue, but you do want there to be something to indicate whether the player should give up or keep trying to open the door.

I think what's being pointed out is that there are many subtle decisions made by game developers that game players don't notice. It's not that they're necessarily hard decisions, but if you're presented with 100 of these decisions, it can be hard to have your choices result in a game that's both technically feasible and fun to play.

Re:Easy answers

[ildon]

In real life, there are plenty of doors for which you will never find the key lying around. More importantly there, are millions (billions?) of doors that are of no interest to you, ever. In a video game, it would be very difficult to set up a series of long term societal detriments for going around trying to open every door, or to easily express to the player why the character they're playing has no interest in one door vs. another, or why what's behind most doors is not of interest to the gameplay or the plot of the game. But it'd also be extremely strange to walk down a city street environment and have there be no doors into any of the surrounding buildings. So we put up false doors as window dressing so the environment looks familiar, but then we build a visual metaphor that lets players see at a glance which doors are unimportant so they don't bother to try them. This can be by leaving them as a flat texture instead of modeled, making openable doors a different color or have specific lighting or highlights, making openable doors have handles and unopenable ones not have handles, or as the article suggests, putting rubble or something (depending on the context of the game) in front of unopenable doors. You can even make unopenable doors make a specific sound effect when approached, such as the sound of a handle jiggling on a locked door, or the sound of the character specifically saying "It won't open," etc. (although only communicating it once the door is approached can be tedious for the player).

Re:Easy answers

[rainmaestro]

Obligatory comic:

http://www.screencuisine.net/h...

Lol, yeah, that's real tough...

[Assmasher]

Compare that to "we need to store patient data..."

Do you know what HIPAA is?
Is this going to be accessible over networks/internet?
How are you planning for archive/restoration?
How will we handle auditing?
Should it be over web services or custom server?
How are we going to manage permissions?
How do we securely persist on the client side?

Seriously? The door exercise is strenuous mentally? Anybody with actual software engineering experience will tell you that ALL software features result in design complexities, and a door in a game is pretty simplistic one - whether networked or otherwise.

Re:Answers:

[Goaway]

Well, thanks for demonstrating the point.

Back in the day...

[TheRealHocusLocus]

We'd call 'em overlays.

One project I did, a series of mods c.1981 to bring real POS invoicing to an early version of Peachtree Accounting, was a BEAR. It was written in MBASIC running under CP/M -- Interpreted tokenized BASIC running on a machine that started with a 64k transient program area. No extended memory then!

Minus OS call kernel, COMMAND.COM, minus BASIC interpreter, your program was born with ~32k to use in its lifetime. So 32k minus the size of the program itself left you with a memory heap for variables. The heap grew downward with every string assignment and when it bumped into the code there would be this pause for "garbage collection" while the heap was de-fragged and re-written to the top of memory again.

No comments, too much room! No long var names! You'd use CHAIN to jump to another program leaving vars in memory. But if you your were clever you'd carve out line number ranges and place temporary functions into 'overlays' that loaded over existing portions. When you did a MERGE no p-code optimization or block was going on here, any load command did its work line by line, it was like a really fast monkey typing in the program code.

So in place of Peachtree's default invoice which was clunky and required lots of input steps (mostly useless for cash sales) to implement a streamlined invoice was difficult. They use lots of strings. My first attempt worked great --- but every couple of line items the heap would touch and trigger global garbage collection -- ~3 to 5 seconds where the machine would be unresponsive. In those THREADLESS 8-bit days when garbage collection began your keyboard controller would save ONE keystroke but the rest would be LOST. This is a total wash. Clearly it needed a whole re-write.

The only way I could make the entry portion useable was to throw out the programming concepts that made things 'easy' (yet caused heap movement). Don't assemble a string of spaces, use a loop to emit them one CHR$() at a time. Don't assign to strings, pre-allocate a number of strings of reasonable length and use MID$() to replace its contents, keep a separate string length var so you can only emit the portion of the string that was being used.

It was sorta like coding in C, in BASIC. That was kind of a 'door' problem. But it worked. Then the world went CBASIC and all our problems magically vanished.

A similar piece from Clint Hocking

[Sockatume]

Clint Hocking (of Far Cry 2) wrote a similar article last month, using the design of reload systems as an example:

http://www.edge-online.com/fea...

Re:Answers:

[91degrees]

> Are there doors in your game?

Probably.

Not the case for every game ever. Maybe not even a majority

> Can the player open them?

Some way or another, yes.

Do we even want access to every single room? We may want to illustrate that we're in a corridor. It would make no sense to be able to open all the doors and it would requitre a lot of level design time and memory space to have something on the other side of each door.

> Can the player open every door in the game?

Unlikely. Some doors will be locked, if only to remove the expectation that doors are no obstacle.

If no doors are locked then why do we need to remove this this expectation?

> What tells a player a door is locked and will open, as opposed to a door that they will never open?

A locked door conventionally makes a distinctive thud sound when the player tries to open it. If there needs to be an indication that the door will never open, those doors don't make a sound (and typically have artwork indicating that they're not really usable doors.) There may be visual indications of a lock status (keypad, etc, with display, red=locked, green=unlocked) nearby.

This is one solution. Should we have a message saying the door is locked? If so, what message? Should all doors make the same thud? Does that make sense for a metal door? If we go for different thuds, is the inconsistency too jarring? How much space do the thus assets take up? Is a keypad the correct design given the setting of the current level?

> What happens if there are two players? Does it only lock after both players pass through the door?

Depends on the kind of event that you want the player to believe is the cause of the locking.

So which events will cause the door to unlock or lock for both players and which will cause the door to lock or unlock for only one?

> What if the level is REALLY BIG and can't all exist at the same time?

Does a tree make a sound if there is nobody near to hear it?

Yes. Now, how do you propose we deal with the memory issue created here?

> Do all the players need to see the door open at the same time?

Yes, if they can see it and the status of the door is relevant to the game mechanics.

What if the door is only usable by players with a certain key or character type?

> You need to get your doors in by 3pm if you want them on the disk.

What's the question?

It's not a question.

> Do we need to give everyone those doors or can we save them for a pre-order bonus?

Yes.

Sucks for those who didn't pre-order. We're now the subject of an internet hate capaign because our game is broken. Or, we don't get as many pre-orders as we otherwise would have.

Every one of these questions is a decision that has to be made. The decision depends on the type of game, the resoucrces avalable (both in terms of hardware and developers), and all the decisions you'e made already.

And the point is, this is just doors. You have a similar lot of questions for any other item in your game.

Re:Answers:

[91degrees]

The point is, most people don't realise just how much minutae you have to deal with in game design, and the job isn't as easy as a lot of people who want to work in games seem to think.

Most people think "Hey, wouldn't it be awesome if we ha could blow holes in all the walls and just kick down every door and we have an entire hotel toplay in with hundreds of rooms.

Yes, it would. But there are other things to consider that people don't think about.

Re:Why is this even an issue?

[91degrees]

If you're the game designer, you're the one deciding what the document says.

Manager vibe, you say?

[Anonymous Coward]

In games industry it's more like this: "I don't like the main character, change it to something more contemporary, a special-ops operative maybe? I don't care it doesn't fit with your theme of magic unicorn land, make the other magical creatures into taliban and we're sorted, right? Well then make it an FPS, no one plays plaforming games any more anyway. Oh, and throw in some realistic explosions, fancy mo-cap and destructible environment. No, you can't have more money. Just make sure the story is coherent and up-to-date. I don't know, look at the last 3 CoD titles' storylines and mix it up a bit. Heck, I DON'T NEED TO TELL YOU WHAT TO DO - YOU'RE THE DESIGNER HERE! NOW MAKE IT HAPPEN! And fix me up with a Gantt chart so that I have something to fiddle with while I'm talking to you next time..."

Will there be public restrooms

[Grey Geezer]

in your game? Will the stalls have doors? Can the user open the stall doors? Can the user close the stall doors for privacy? Will users be able to leave the restroom without first washing their hands?

Re:Answers:

[ildon]

Woosh.

The point of the article is that these are questions a designer has to consider for every single object and system in the game, interactable or not. There are no obvious answers because the answers will be different depending on the nature of the game one is trying to design. Some of the questions aren't even relevant to most games (which is intentional on the part of the author). The point is that designing video games is not just coming up with fun gameplay, but handling a lot of tedious and mundane details for a complex interactive system, and coming up with answers and solutions for things that most players will never even think about (until it breaks).

Also the second set of lines are demonstrations of how a person from that area of production might influence or interact with the design of a game system or object, not questions to be answered.

Re:Door problem

[91degrees]

To visually represent a scenario that typically has lots of doors (a hotel, for example), or as an entrypoint to the location you've just left.

Yes, it's a wall as far as level design and internal game logic is conerned. It's a door as far as visual cues are concerned.

Killer doors

[DarwinSurvivor]

How did they forget the most important question? "If the door opens towards you, does it crush you into the wall?"

As a game developer...

[sstamps]

I don't think she does a very good job of explaining why good game design is difficult.

It's not that game design itself is difficult, it is that GOOD (ie, fun) game design is difficult. She's basically addressing the wrong problem set. What she is describing is simply software design and engineering issues, which boils down to 3 real categories:

1. Functional / feature design: the rules which govern whether they exist and how they can function. AKA "business rules" in normal software development.
2. User Interface design: how the user (player) interacts with it.
3. Engineering/Implementation issues: how do you make 1 & 2 real and work, while reducing undesired side-effects.

1 & 2 generally form a specification for the feature's design, and 3 is the specification for how to implement it.

This is not unlike many common design and implementation processes for standard software design and engineering of complex systems. The real difference is that, while a software system designed and implemented correctly may fulfill all the intended design objectives, there is an additional objective which games add to the mix that is not generally present in normal business applications: fun. Unfortunately, it is not an objective criteria, and requires "play-testing" to discern whether a particular design is fun or not. It is very difficult to design-in "fun" from the very start of a project.

That said, with the advent of Serious Games, adding the "is it fun?" criteria to real-world business applications is happening more often.

Lastly, as a game developer, the single greatest challenge I have encountered is simply to keep going through the "hard times". Like any difficult software development project, there are times when things get dark and depressing for whatever reason, and there is difficulty keeping motivated to continue, but you have to bear down and power through the hard parts. The reason most game development projects fail that I have seen is that people don't really understand how hard it can be at times, and give up when the going gets tough. To me, this is a more difficult hurdle than in typical business application development, because many people get into the development of games with an incorrect level of expectation about said difficulty.