Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Games

'The Door Problem' of Game Design 305

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?"'"
This discussion has been archived. No new comments can be posted.

'The Door Problem' of Game Design

Comments Filter:
  • by ciderbrew ( 1860166 ) on Wednesday April 23, 2014 @05:33AM (#46821427)
    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
    • by Assmasher ( 456699 ) on Wednesday April 23, 2014 @07:22AM (#46821927) Journal

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

    • That has long been what many people wanted. Games that act like things in real life. Instead, we get things that look like real life, with high quality graphics, but think still don't act like real life. I'd rather have a game that didn't look as nice, but had things that reacted much more as they do in the real world. Breakable windows have been done, but doors and walls are usually completely solid, which, I guess, is usually why they don't put windows on them.

      Personally, I really liked the way Metro
      • I'd rather have a game that didn't look as nice, but had things that reacted much more as they do in the real world.

        I sometimes wonder, what if, back in the days of text adventure games, video game designers had not put all the money and effort into graphics, but instead put it into natural language recognition, world models, and artificial intelligence? Like imagine the millions of dollars we put into graphics, instead going to make a super-advanced text-based adventures where you can really explore a world and do whatever you want.

        Of course, knowing our civilization audience, those games would all be procedural milit

        • by BasilBrush ( 643681 ) on Wednesday April 23, 2014 @09:53AM (#46823415)

          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/ [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.

          • by nine-times ( 778537 ) <nine.times@gmail.com> on Wednesday April 23, 2014 @10:19AM (#46823739) Homepage

            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.

      • by BasilBrush ( 643681 ) on Wednesday April 23, 2014 @09:36AM (#46823175)

        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.

        • 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: (Score:2, Funny)

      ALSO, I want to shoot something through the doors and blow them up with things.

      Oh, Gawd, a believer in the Joe Biden School of Civilian Marksmanship....;-)

    • Why did they give you that proton torpedo? You make your own windows in doors. Also doors in walls.
    • by ildon ( 413912 ) on Wednesday April 23, 2014 @08:32AM (#46822461)

      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.

  • Article is empty (Score:5, Insightful)

    by Noughmad ( 1044096 ) <miha.cancula@gmail.com> on Wednesday April 23, 2014 @05:38AM (#46821437) Homepage

    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.

    • by O('_')O_Bush ( 1162487 ) on Wednesday April 23, 2014 @07:30AM (#46821991)
      I couldn't distinguish her "doors problem" from any other mundane problem in a complex system that some of us deal with every day.
      • by tepples ( 727027 ) <tepples@gmai3.14159l.com minus pi> on Wednesday April 23, 2014 @08:13AM (#46822305) Homepage Journal
        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: (Score:3, Insightful)

        by joshuao3 ( 776721 )
        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
        • Re:Article is empty (Score:5, Interesting)

          by bzipitidoo ( 647217 ) <bzipitidoo@yahoo.com> on Wednesday April 23, 2014 @02:14PM (#46826497) Journal

          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.

  • by fatp ( 1171151 ) on Wednesday April 23, 2014 @05:39AM (#46821445) Journal
    Most RPG Games I played have large number of fake doors.
  • um (Score:5, Insightful)

    by Charliemopps ( 1157495 ) on Wednesday April 23, 2014 @05:57AM (#46821495)

    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?

    • 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
      • What if the UI is REALLY BIG and controls can't all exist at the same time?'

        your UI is too complex

        So every app with more than one window (or mode) is too complex?

    • Re:um (Score:5, Informative)

      by thesandtiger ( 819476 ) on Wednesday April 23, 2014 @08:47AM (#46822623)

      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 (Score:4, Insightful)

    by DeathToBill ( 601486 ) on Wednesday April 23, 2014 @05:57AM (#46821499) Journal

    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 (Score:5, Informative)

      by mwvdlee ( 775178 ) on Wednesday April 23, 2014 @06:20AM (#46821591) Homepage

      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.

      • If it is locked, then that implies that the door opens, but it's being blocked by a device (the lock). If the door wouldn't open (ever), then it's probably just a texture that looks like a door instead of an actual, in-game door that it's just locked.

        I think it was in F.E.A.R. where there were doors whose sole purpose was to look pretty. They opened, except there were some boxes or stuff on the other side so you could never go through them. Perhaps you would go to the other side through another way, or perh

        • by mwvdlee ( 775178 )

          But did the boxes behind the door behave like boxes? Could the boxes be opened, or shoved aside?
          I'm perfectly used to encountering doors that I will never be able to unlock in real life.
          When I walk to my own frontdoor (to which I do have the key) I encounter dozens of doors for which I have no key and which will remain forever locked to me.
          Why couldn't this be true for a game as well?

          • Because in real life those doors don't come in a package you bought.
            You bought the game, therefore you bought all the doors within it. They should then have the ability to open and let you explore.

            • by tepples ( 727027 )
              You didn't buy it; you licensed it. And you didn't license the ability to charm all NPCs into unlocking all doors for you.
          • When I walk to my own frontdoor (to which I do have the key) I encounter dozens of doors for which I have no key and which will remain forever locked to me.
            Why couldn't this be true for a game as well?

            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

          • You do expect that all doors will behave like doors. If you try the handle (assuming nothing stops you from physically reaching the door), you'll either open them or fail because they are locked. If they are locked, they'll usually make a noise (either because you pull and the lock won't let it open, or because the handle will not continue down).

            The main complain about the whole door thing is that you find games that have what looks like a door and isn't: you click your action key and it does nothing becaus

    • 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. I
    • 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!

      • 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.

      • 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!

        The complaint is more that IRL, there is *some way* of opening every door out there. Most of the time it's out of simple respect of what a locked door indicates that you don't even try. The rest of the time it's usually that the effort isn't worth it. But it's totally possible to open every single door in, say, a hotel. In many games, doors are just decorative, despite that there's an implication of something behind it.

    • Arbitrary restrictions are what differentiates game design from VR engineering.

    • Let me guess, you only ever play sandbox games?

      The summary questions are essential questions to answering what kind of game you want to design, and you explained the consequences of ignoring them perfectly in your commentary. A game is a combined experience and challenge. That experience needs to fundamentally be finite, if only because you have finite designer time. What you have to do is make the experience finite without throwing arbitrary restrictions at the player when possible. Yet I wouldn't want EVE

    • It's why I stopped playing the last thief. Zounds of doors out of which 3 open, everything else is just there because... I have no idea why.
      How to beat the ultimate thief: just place the loot behind one of those unopenable doors.

    • 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 realiz

    • Re:Easy answers (Score:4, Insightful)

      by Anonymous Coward on Wednesday April 23, 2014 @08:40AM (#46822519)

      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."

    • 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 ga
    • by ildon ( 413912 )

      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 w

    • 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

  • 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=... [youtu.be]
  • by Assmasher ( 456699 ) on Wednesday April 23, 2014 @06:14AM (#46821567) Journal

    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.

    • I should have added that the real challenge doesn't lie with the Game Designer, it lies with the Gameplay Engineer who has to correlate the design person's wishful thinking.

    • It's a microcosm of a bigger problem.

      We like to think of doors as simple and easy to understand. That's why this example was picked. Imagine all of the other little things that we take for granted and it all stacks up.

      Not to say that storing patient data or doing complex modeling or whatever isn't tough. But, it's an insight in the game development process.

      • I understand, but trying to make a door sound complicated as opposed to trivially simple is a bit too far (imho.)

        The issue is that Game Design isn't difficult from the technical point of view, it is difficult from the creative point of view.
        Game Implementation is difficult from the technical point of view.

        Anywho, I know what you mean, but it still seems a rather egregious example. ;)

    • But implicit in the description is an argument between gamers if they like not knowing "the one true path" through the level (all locked doors look and act alike, but some have keys and some don't, which leads to many wasted hours trying to open doors), while other gamers enjoy seeing a door with a red light in the distance and instantly knowing it will never open; it's just decoration. As a designer, you have to know what your demographic wants. Puzzle solvers and first person shooter fans have vastly d
      • Yes, and a Game Designer will know who the target audience is, the genre, and the platform (important.) It doesn't make a door any harder to design, it does make it harder to implement.

        It's clear that the Game Designer was trying to say "It's not as simple as saying we have doors in the game", but it sounds a lot like someone saying (and I'm ripping off another poster here) "Being a model is like, super hard... You have to stand around all day, and then they expect you to walk... It's not like we just sh

        • Agreed, the summary (and the article too) seems to cover the what of the thought process when I think why this is complex is probably more interesting. They why this is necessary is the consequences when these items are not thought out.

          One example I can think of off the top of my head is, a door that is being used to prevent access to a special area in an MMO. If it isn't designed to restrict access appropriately, it devalues that room. Another question comes in when you consider if you actually need a
    • In medical and avionics the designers are forced to take regulations and certification into account because failure can have sever consequences (injury or death). This (hopefully) means the design process will get things more things right before development starts and everything right before the application is released.

      In computer game and basic application development these regulations don't exist. This means that either the designers use the same amount of discipline used up front in critical applicat
    • It's not really a strenuous activity. But it is a mental activity which most people don't normally do, because most people take real-life doors for granted. Of course programmer geeks talking on slashdot are used to thinking this way about the problem spaces that they deal with when they are programming something, so to us it's nothing new. But for someone who hasn't programmed before, or designed a rules system for how virtual stuff should work in the context of a game before, it is.
      • I agree.

        My issue isn't that there aren't lots of implementation detail to seemingly obvious logical manifestations of everyday objects, my issue is that the game designer is trying to make it sound like that aspect of their job is difficult. It isn't. It's possibly tedious, but it's not hard.

        Now, that aside, being a GREAT game designer IS hard because the creativity necessary isn't something that can really be taught - but again, this isn't what the person in the article was referring to.

  • by TheRealHocusLocus ( 2319802 ) on Wednesday April 23, 2014 @06:40AM (#46821665)

    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.

    • by OzPeter ( 195038 )

      I know what you mean. Back in the day I wrote a "multi-tasking" program in TI-Basic(*) that simultaneously handled operator keystrokes as well as performing "real-time" calculations. And disk I/O meant overlaying disk sectors (from the 8" floppies) onto arrays of variables in memory from where the program could access them.

      * One thing that annoyed me about that system was the operator stations were programmed in TI-Basic, but the control sections could be programmed in genuine MS-Basic, which was a hell o

  • The majority of games in existence nails doors and windows shut. Without bothering to justify why they're shut, or by throwing in a generic "door is locked" animation when the character tries to open them, or by stacking up debris / chairs against the door to justify why it can't be opened. First person shooters are the lamest at doing this - Call of Duty etc. where a heavily armed, fit man can't even knock a pane of glass in or kick / shoot a door open or climb over a modest obstacle. Why? Because fuck you
    • You're the kind of guy who plays chess and gets really angry that a bishop can capture a knight, aren't you?

  • by Sockatume ( 732728 ) on Wednesday April 23, 2014 @06:59AM (#46821783)

    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... [edge-online.com]

  • What happens when alleged game designers (and/or producers, etc) get bogged down arguing about the minutiae of the actions/responses of doors, to the point that it takes more than 30 seconds to resolve 'challenging' questions like: Do all players need to be able to operate the door? Does it lock behind a player? Must they all see the door open/closed? Can the door be optional DLC?"?

    Answer, you shouldn't be surprised that your project can't meet its deadlines or budget.

  • Seems entirely too coincidental [trenchescomic.com].
  • 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 h

    • What strikes me is the producer question. "Are we trying to make a good title, or are we going to bait customers with exclusive content so we get millions of people to buy our game before the reviews pour onto Amazon that it's garbage not worth playing?"

    • If you're the game designer, you're the one deciding what the document says.
  • 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?"

  • 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.

  • by Grey Geezer ( 2699315 ) on Wednesday April 23, 2014 @09:11AM (#46822893)

    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?

  • by DarwinSurvivor ( 1752106 ) on Wednesday April 23, 2014 @10:30AM (#46823899)
    How did they forget the most important question? "If the door opens towards you, does it crush you into the wall?"
  • by sstamps ( 39313 ) on Wednesday April 23, 2014 @12:19PM (#46825185) Homepage

    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.

Real programmers don't comment their code. It was hard to write, it should be hard to understand.

Working...