'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?"'"
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
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.
PlusFive Slashdot reader for Android. Can post comments.
Most RPG Games I played have large number of fake doors.
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?
I'm not convinced by TFS. The answers are, roughly:
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...
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
"The Slashdot Effect Problem" of websites.
I believe fallout 3 handled the issue of too many doors and not enough resources to program a room on the other side quite nicely as demonstrated in this clip (possible NSFW) http://youtu.be/WGKs9-VLgsQ?t=...
I'd point her the door.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
It's like she has never played a game before.
> Are there doors in your game?
Probably.
> Can the player open them?
Some way or another, yes.
> 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.
> 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.
> 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.
> 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?
> 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.
> You need to get your doors in by 3pm if you want them on the disk.
What's the question?
> Do we need to give everyone those doors or can we save them for a pre-order bonus?
Yes.
Whilst we're sorting out the doors, I'd also like to be able to lift my feet a bit higher and climb over small walls, rocks etc.
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.
Loading...
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.
<blink>down the rabbit hole</blink>
Your version of Windows is not genuine. Please call for further details.
...I'm inclined to believe she simply has a glitch in the engineering portion of her brain. I really can't see the problems she's painting over her walls.
Modelling, a lot of people think it's easy. But it's the hardest job in the world, isn't it?
It's very hard. Standing in heels all day, and everyone's watching you, so you have to make sure your walk is good.
And, yeah. Yeah, it's really hard, 'cause you've gotta remember, like, to put your right leg forward and then put your left leg forward and then, like, which one now? Right leg again, and then, like, the left one.
And then sometimes you even have to turn. Yeah. And especially the turn. It's so scary.
More likely it's because their lame engine or AI cannot cope with a dynamic environment properly, or their collision detection / physics get all confused by someone shooting through a door or window, or simply because they can't be bothered to make it work properly.
I don't see it as the problem of a new designer to solve, so much as the entire industry, particularly those who produce tools & middleware for physics, collisions and destructible environments. If the likes of Unreal Engine allows a building to collapse or take damage (e.g. a tank putting a hole in a wall) or to kick open a door then it is likely that many games would make use of that.
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...
No kidding!!! What do you say at this point?
I should switch my job from programming to game designing.
Answer, you shouldn't be surprised that your project can't meet its deadlines or budget.
-Styopa
Seems entirely too coincidental.
PHEM - party like it's 1997-2003!
This design of entertainment product is SO complicated. It must be stressful, no?
Thank God we don't use the same technology for dealing with people's lives, health or finances..
Lara wasn't the point back then.
See GP. Technology wasn't good enough to implement that vision.
Producer: "Do we need to give everyone those doors or can we save them for a pre-order bonus?"'"
My opinion, who gives a crap about the doors, but fire the producer.
If the game design document says "All doors should be openable, provided the door is unlocked, the player has the key or the player is willing to take a reputation hit by breaking and entering", then your job as a game developer is to implement doors as specified in the game design document.
If the game design document says "Doors are graphic inserts for effect only", then your job as a game developer is to implement the doors as specified in the game design document.
If the game design document doesn't say how to handle doors before people start building the game, then the game design document is incomplete.
Incomplete game design documents, like incomplete architect blueprints, lead to stupid things like what you get by googling "architecture fails".
Programmer: Welcome to the 21st century. We can distribute content these days that isn't included on the disk. Gigabyte-plus launch-day patches are not uncommon, now. Stop being a dumbass.
Producer: No. We're making a game for you that will make you lots and lots of money. Stop being a greedy douche.
Add doors as DLC at day 1
Then patch door opening and other stuff during the next year.
Then later when people start to whine that the doors are too difficult to open, make them always open :)
Add pandas
???
Profit!
You mean they didn't want to spend exorbitant money to implement that vision.
What tells a player a door is locked and will open, as opposed to a door that they will never open?
Why include a door in a game at all if it will never open. Isn't that really more of a "wall?"
Budget problems? For parts of a map that need to look plausible but whose precise arrangement isn't critically important to the story, try something procedural. Don't design a hotel room; make a program that designs hotel rooms. It worked for the space trading sim Elite, the shooter .kkrieger, roguelikes, graphical dungeon crawlers inspired by roguelikes, and Orteil's Nested tech demo.
Tech limits? Why can't the game just drop everyone to 1997-class graphics when it detects that what the players have chosen to do has hit fundamental limits of popular video gaming platforms? If it was good enough for GoldenEye...
Back in my day we had to code our doors in hardwood assembly. Ah, how remember the moment I saw the work of a master craftsman for the first time! Jimmy... you know Jimmy from the old office on Alameda? Jimmy was motherf*ing unhinged! He hooked the hblank to update the color ram with a rich mahogany, and then the vblank slurped up code straight from $A000 and used it as random 1bit texture for the wood grain. My only contribution on that project was realizing that the door hinges and the knocker could be clipped from the same sprite. That saved upwards of 1.5K by itself! There was a funny easter egg since the bounding box was so simple, if you got in just the right spot, you could "knock" the lower hinge. Kevin in marketing thought it would be funny to also make it have a doorbell ring if you kept doing it, but I was like "Come on Kevin, that doesn't make sense."
You stated that incorrectly.
Those doors are locked but can be opened. Usually with equipment that an RPG character carries around "in-game". Whether that equipment is "lock picks" or "an axe" or "a rocket launcher".
What stops you from opening them is that you do not try to. Why you do not try to is because you do not want to go to jail.
Criminals "open" doors you consider to be "locked" in the real-world all the time.
90% of the doors in the game are fake and you can not get into them. Honestly, all that does it make players think the developers just half assed the game, and in RAGE's instance it is... 2 full DVD's and it has a shorter single player game than most of the War games that are designed to be not single player.
Do not look at laser with remaining good eye.
Teach the player early on what the difference is between a openable door and a purely aesthetic door. Some games (particularly ones with a sci-fi aesthetic) often use doors with green accents to represent openable doors and red accents for permanently closed doors. Some games like Deus Ex often have the door slightly depressed into the wall to signify a usable door, whereas purely aesthetic (closed) doors are generally flush with the wall.
Provide a different set of door types very early on in the game and the player will learn very quickly which doors to try and use. After a while it becomes automatic. To be honest I'm surprised this is seen as a problem anymore - I've never really thought about it for years. Maybe the next generation of game developers don't know much from history.
I'd also like to be able to lift my feet a bit higher and climb over small walls, rocks etc.
Climbing I'll give you, but what feet?
The list of questions is incomplete. The final question should be: "Did you even come up with these questions before attempting to prototype your door?"
Being a games designer is often simply knowing which questions to ask and where to look for answers. Brainstorming, user feedback and intuition are all valid design tools. Also, knowledge of at least some general programming practices goes a long way as a lot of programmers will BS you with typical "no, this can't be done" malarkey just to shut you up.
Holy crap, you mean game development is like work? I thought you just copy/paste levels and pew pew pew...
Seriously, these are questions that ANY large scale project requires. Instead of whining about how difficult it is to answer checklist questions, how about preaching the ease of new IDE's, or how accessible documentation is on almost any programming language. We live in an age of over privileged, spoiled children. What happens if you are on my lawn? You get off.
Will there be door prizes?
Will Jim Morrison be a playable character?
Were you born in a barn? (Shut the door!)
I'm a good cook. I'm a fantastic eater. - Steven Brust
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..."
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?
The USA is only 4X older than me...perspective
I'm less worried about doors I can't open than I am about wooden doors that are impervious to rocket launchers.
The biggest door problem in game design is getting in the door to get a job in game design
It all depends on how much real imagination you've got. I designed a text adventure many years ago for the BBC Model B. Doors were based on reality. Some opened inwards, some outwards, some had locks (and you had to get the right key). The nasty ones would swing shut behind you and you'd find there was no handle on the inside.
:)
There were, of course a host of appropriate messages
What is far more important is that you have a game plan, room list, alternative routes/actions, and most important of all an objective.
How did they forget the most important question? "If the door opens towards you, does it crush you into the wall?"
Hmm, interesting article. Thanks.
That article is silly exaggerated self-promotion. Most of these decisions are inferred, the real problem with game design today is game designers want to be movie script writers. Also many game designers get away with a lot because there is no objective measurement of good game design.
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.
-SS "Teach the ignorant, care for the dumb, and punish the stupid."
I want to be able to meet Jim Morrison, but not Robby Krieger. And it would be nice if I could Light My Fire.
The parents point is that all doors need to behave the same way. If one door can be locked, they all can be locked. The question is not "can a door be locked" but "should this door be locked so the player has to find a key?" If a player can block one door, they all need to be blockable. There should not be two doors that look identical but one will swing through a player, and the other will be blocked by the player.
It's about consistency of behavior. If one door behaves differently than another door then it needs to look different. If a door cannot be locked, then it shouldn't have a key hole. Any door with a keyhole should have a key somewhere in the level and it should be able to be locked and unlocked with that key. The only question is the starting state of the door and how many copies of the key there are.
It's not really a hard concept. It's about consistency of behavior.
Work Safe Porn
Thing is, there's really only two schools of thought on doors in games.
School 1 (Silent Hill, RAGE, early Resident Evil games, Half-Life): No graphical differentiation between real doors and fake ones. Many doors are fake. Silent Hill and RE handle this by having a text box mention that the door is locked/bolted/broken/whatever. RAGE was just sort of lazy and didn't even bother doing that. Half-Life did it by having the door handles on fake doors make the "thunk" noise and have a visible effect of the handle failing to move much when toggled.
School 2 (THI4F, Dishonored, Hitman Absolution): There is a single door model that means "this door opens" and a single door model that means "this door is fake". Usually, the latter is characterized by an extremely low polycount, while the former has an excessively high polycount, usually accompanied by shining brass or chrome handles and/or a "halo" effect in Instinct/Thief Vision/whatever the "everything gets a glowy outline" casual mode is.
School 3 (1st and 2nd-gen Pokemon games): All doors are enterable, buildings or rooms that aren't enterable don't have doors. This school of thought is largely dated and rarely used anymore. Mostly seen in older games where memory limits were a bigger concern than they are today.
Game design explained in one post: Make a loop, inside that loop, put graphics in it's own loop, input handling in a loop, sound in a loop and networking in a loop. Start writing your game. Seriously fuck these people who say you can't do it. Fuck the courses and training. Just make a game. features, and what you want to put in it, are a matter of what you choose to throw in and what things you like. Commercial game development is different, but then it always has been. Still the indie scene seems to work well for a lot of people these days. If you want tp make games, there's nothing stopping anyone. The instructions are on google. How to program linux games by Loki software is a great intro. They designed it around 2d games, but the theory is exactly the same for 3d. You just have a 3d graphics loop rather than a 2d graphics one. I recommend the OpenAL,OpenGL and SDL tutorials and books.
that this door issue was handled in Doom. Don't have the key? Circle back, lock and load and hope for the best. Incremental saves are a plus.
I imagine that a renderer could use a window in a door as a cue to use a lower level of texture and geometry detail, especially if the window is tinted.
The door is a lie.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I'm not convinced by TFS. The answers are, roughly:
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...
It's called Critical Path. The path the game designer needs/encourages you to go to "win" the level. With the exception of sports games, simulations, and sand box games: There is always a Path, even if it looks like you are not following one. A good game designer knows all possible ways to go from Point A to Point B and either rewards you or obstructs you from going that particular way.
The whole experiment with the door is to demonstrate how different players in the design process view something like a door in a game. This is to be expected though. Each person in the development process has a different view of what would happen in the world they are creating. This also demonstrates the concept of Critical Path being key to a good designed level/game world.
As for doors opening/locked: The only way I see it breaking the suspension of disbelief is if doors that normally were always closed suddenly became operable near the end of the game without explanation or doors that were open-able become disabled even though they are clearly marked as open-able.. Marking them? At first that might break the perverbable "4th wall", but if they get immersed into the world all the signs and indicators become second nature and no longer have that much impact. It becomes "normal" to press a button to open a door even with a mysterious floating text there to indicate it. They don't even read it: They just instinctively realize that door is open-able because the indicator is there.
homestuck at MS paint adventures started in the mode of a collaborative interactive novel. It was updated 5 times a day by the author with input from all the players/readers, although as the audience grew beyond the thousands it was not possible to maintain this method going forward.
It may we worth checking out if you have not seen it yet.
Yes it would be more realistic if all doors and windows could be opened! As well as Weather changes from calm to fierce weather! This goes for as well day to night! So let's have this in all our games, $60.00 these games cost today and I think sorry to tell you this what a waste of a great gone to the dog pound!! I can't stand restrictions in the Video Game Industry today!! So wake up Sony! And Microsoft!! This is getting so annoying that it's not funny anymore! 1976-2015..
I would like a game that does not penalize a player for having a life away from the computer.
Imagine a game where someone who logs in a few times per week, can still enjoy as much as someone who has no life and plays for 8 hours (or more) straight and you get the idea.
Also prefer games where you have a mission and are flying/driving a tank, plane and/or spaceship more than the personal shooter games. The Activision Battlezone and Wing Commander games for the PC come to mind, they were excellent! Would love to get those running on my Linux boxes, even if I had to slow down (or ignore) clock cycles to get it to run right. Loved those.
The First person shooters make me yawn.