Sunday, October 15, 2006

Persistent myths about Game Design

The straw man concept of game design involves the sole genius game designer who writes his thoughts on a golden tablet and passes it down to the production minions to build.

There are several beliefs about the process of game design and development evident in this stereotype.
  • Heavy upfront design and preproduction are critical to the creation of a great game.
  • When these activities are not done early in the process, there will be mistakes made later in the development that are almost impossible to correct.
  • A single individual must drives the creative design process. Otherwise there will be a lack of vision that cripples the project.
To this day I still come across designers who enthralled by such philosophies. How often have you heard comments like:
  • “If only we had more preproduction time, we wouldn’t have run into this problem.”
  • Or “If only I had been given more creative control, the product would have turned out better.”
These statements sound quite reasonable and many of us can bring up examples where such practices appear to have worked. However, as the industry becomes more experienced, many have come to understand that traditional upfront design presents a myriad of problems including delayed schedules, conservative design choices and years of our lives spent producing game designs that customers simply don’t want.

Our development beliefs have deep roots in the creative processes that have been historically promoted as the right thing to do. Let’s look back at why they are so prevalent and why they fail when applied to modern game design and development.

Historical Roots: Software development as an engineering discipline
Back at the turn of the century, manufacturing believed that heavy upfront planning was the key to efficiency. The mantra was “Do it right the first time”. There is a rich history of ‘time and motion’ process development where learned men with stop watches would plan out manufacturing steps performed by their laborers to the second. Software development, in an attempt to add rigor to their fledgling discipline adopted the manufacturing philosophies whole heartedly.

The following are wisdom gleaned from this ancient era. In small doses, they are quite beneficial. When they are followed dogmatically, time and experience has proven that they destroy projects.

Myth: “Upfront design reduces risk”
We all are familiar with waterfall style preproduction, production, post production cycle. The idea is that by planning upfront you think through problems early and avoid stupid mistakes. In this line of reasoning, the longer you think about a problem, the more edge cases you’ll discover.

When teams are given plenty of time for upfront design, they will typically design elaborate systems for problems that do not really exist. The interaction of software with users is notoriously difficult to predict. Problems emerge from the most unlikely areas and other issues that take of dozens of hours of planning end up not being all that important. When a team plans in isolation from feedback, the result is bloated software that either poorly solves the actual problem or does not connect with the users needs.

A better technique is to test your ideas early and often.
  • Build working systems that you can show to users as early as possible. This allows you to gain real world knowledge at the earliest possible point.
  • Try multiple paths early in development. This results in the cross fertilization of expert knowledge necessary to create truly innovative solutions.
  • Do the simplest thing possible. Instead of worrying about every contingency, do the simplest thing that will solve the problem at hand. If you get feedback that it needs to be improved, go for it. This dramatically reduces feature creep.
  • Defer decisions as long as possible. The longer you can gather information, the more likely you’ll make the right decision. This may smack of being wishy-washy, but it is an attitude that encourages building flexibility into the system and allows you to adjust to feedback more easily.
  • Iterate: By building rapid feedback cycles into your development process, you’ll converge on an optimal solution far faster than you would if you spent time in planning.
  • Include customer feedback. Play that game constantly. Watch others play the game. Collect real world data and share it with everyone on the team. Act on the problems you witness.
There are two forms of risk, execution risk and design risk. Execution risk is the risk that the project will not be completed as planned. Historically, it is what our fledging industry has been overwhelmingly concerned with. “Can we even make a game?” Design risk is the risk that you will complete the wrong product. This is where mature developers should be focusing their effort “Am I making the right game?” Upfront planning focuses on reducing execution risk. In reality, long preproduction delays the production effort and results in a product that is disconnected from the needs of the market.

Rapid iterative development reduces both production risk and design risk. Design risk is reduced by constantly reconnecting with the customers. Production risk is reduced because you find that you often need to do a lot fewer features in order to satisfy the core customer’s needs. It is amazing how you can cut production schedules by simply doing half as many features. Just make them the right customer focused features instead of the flights of fancy of a planner locked in a dark room.

Myth “The cost of change increases exponentially as time goes on”
Many conservative design decisions are motivated by fear of change. We are told that a change late in the process will cost 1000 times as much as a change early in the process. The argument is that it takes five minutes to write a spec, two days to program the feature, two weeks to test it before deployment and a month to write a patch that fixes a problem after deployment.

This belief encourages logical people to optimize their behavior in peculiar ways. The first inclination is to create highly detailed plans of action that are presented to the production teams as the Bible for the game. Some common problems include:
  • Locking into design details before real experience based information is available
  • Locking the development team into a design that is guaranteed to be wrong.
  • Discouraging ‘Aha’ moments that occur later in development as the team learns about new and exciting attributes of your emerging gameplay. If it isn’t in the plan, it doesn’t get developed.
Second, you want to choose the lowest risk designs as possible. Changes are expensive and low risk designs are less likely to change. The result is a glut of surprisingly narrow minded design decisions made early in product development.
  • Choosing well known designs that are already implemented in other projects over new designs that have multiple unknowns.
  • Discouraging experimentation after preproduction in the belief that it will lead to difficult to plan for innovation and feature creep.
It turns out that the act of attempting to control the cost of change through waterfall techniques bloats the cost of even simple activities. The team puts on spec blinders, focuses on low risk designs and fails to consider the surprising solutions that appear when smart people slowly attain mastery of a complex system. The process itself of excess upfront planning causes the exponential cost of change, not the inherent nature of the work.

When you take the same activities in put them in a software development environment that emphasizes rapid feedback cycles and modern coding techniques, you see a much flatter cost of change. This requires systematic changes throughout the team, not just in the area of game design.

Introduce flexibility into programming activities:
  • Refactor religiously. Use a language that lets you refactor and make refactoring part of your daily coding habits.
  • Use modern source control and coding standards.
  • Reduce rigid code ownership. This ensure that the right person is available when the time comes to make a change across multiple areas of the program.
  • Encourage unit test suites. This builds a safety net that allows programmers to experiment without worrying about irreversibly breaking existing code.
Introduce flexibility into artistic activities:
  • Create highly reusable artwork that follows a standardized format. Procedural content is a must. One shot disposable artwork such as cinematics or in-game cut scenes should be avoided.
  • Reuse artwork from previous projects. Prepare to ship with some of it.
  • Use easily replaceable dummy artwork to prevent bottlenecks during rapid design iterations
Introduce flexibility into design activities:
  • Keep design documents simple. Try post-it notes stuck on a wall in a team area.
  • Use prototypes instead of design documents. If you can’t play a game mechanic, you are just waving your hands. This is often worse than useless since it can hide really bad mistakes for surprisingly long periods of time.
  • Rely on reusable game mechanics instead of one shot level design. Think football, not Disney rides.
  • Be very willing to cut scope. 80% of the designs that you suggest should not ship. Reevaluate your design after everything iteration.
There will always be major features that are difficult to change, but these should be the exception, not the rule.

Myth: “A specialized workforce organized into functional silos is the key to productivity”
The heart of the concept of mass production is that complex system can be decomposed into a series of easily manufactured pieces. The production of these pieces can then be streamlined and created by a specialized workforce that sequentially processes each step of production. An underlying assumption is that if each one of those pieces is built in a high quality fashion, the assumption is that the system as a whole will be of high quality.

Many game developers embrace this strong division of labor. The game designers sit in one area of the office and plan the game. The programmers sit on another floor and implement tools and game systems. The artists are outsourced. Each group is managed based on meeting individual goals associated with their specialized task. The work then flows through each team in a regimented fashion with very narrow bandwidth communication between each group. The design documents and Gant charts describe who should pass off what materials when. And the whole system hums along like a giant clockwork machine.

This does not work. Developing each aspect of a game in a vacuum leads to the following:
  • A rigid inability to change. When an artist realizes that they can improve their process by changing up a few steps, there are often few channels of communication or incentives for communicating these changes to other groups. Often each silos will actively attempt to kill change in other silos in an attempt to “stick to the plan.”
  • A lack of an overall vision for the product. When change does occur (and it inevitably will), each silo begins to drift out of sync with one another. If the drift goes far enough, each group will end up with distinctly different visions of what the end product should be.
  • Isolated silos of workers protecting their own turf. With separate goals and visions comes conflict. Dominance games, unhealthy compromises and apathy are common.
  • Massive integration costs. Often games are integrated together at the very end of the production cycle. Many projects that are not playable in whole until only 20% of the schedule is left. The cost of shoehorning divergent systems and teams together after months of primarily independent development tends to bring up substantial technical and personnel challenges that no one predicted.
Having a team filled with skilled experts is a good thing. It ensures that you don’t end with jack of all trades, but master of none. But once you get those experts, you should seat them together and encourage cross training between disciplines. This ensures a shared vision and helps reduce sub-optimization.
  • Sit cross functional teams together. Being within shouting distance of your artist or your programmer increases the bandwidth that you have for communication by a factor of 1000. This means that the vision for the project is constantly reinforced. It also means that experts from each discipline can come together to solve very tricky problems in a relatively straightforward manner. You’ll come to decisions in 1/10th the time and your decisions will be more well rounded and better informed.
  • Make each team no larger than 10 people. When you get more than 10 people, communication suffers. Maintaining group cohesion requires more management and ape-like ‘social grooming’ time. Teams of around 5 to 10 typically have the highest per person productivity. String multiple teams together with a system like Scrum if need be.
  • Build working games, not isolated systems: Integrate early and often. This goes hand in hand with iterating rapidly and prototype driven design. Each cross functional team has everyone they need to make a complete working game from the start of development. By integrating early, you’ll exercise your development pipeline and you’ll encourage each discipline to being working together early in the project.
Myth: “There is one game designer who holds the vision for the project”
The artist of the previous century has been lionized as a lone creator who imagines a visual in their head and single handedly copies it onto paper, film or clay. On the traditional art project, single artiste owns the creative process from concept to execution.

Shakespeare, Picasso, Rodin dominate our art history. As tribal apes, our innate bias is to assign ownership and dominance to a few individuals at the top of the social pyramid. If the vast majority of publicly celebrated creative works of the past have been attributed to a single artist, then surely game design must follow the same model?

The only problem here is that most games are not created by a single person with genius level skills in a mature craft. They are team activities that involve the creation of complex, new-to-the-world interactive systems.
  • Games represent a class of problems that benefit greatly from collaborative problem solving and use of specialized skills. It is difficult (though not impossible) for a single person to make a modern game. Teams typically produce more enjoyable, more fully realized experiences.
  • Communications issues dominate the creative process, not individual creativity. It is more likely that 10 moderately creative people who can communicate will create a great game. A massively creative person who cannot communicate is outside the game design sweet spot.
  • The ability to solve new problems is more important than the mastery of craftsman-like skills. Game design involves exploring and manipulating complex system that have highly unpredictable results. Every day presents a new set of problems that no one in the entire history of the world has ever witnessed. This is very different than a person getting to spend ten years working in a stable medium such as oils or clay that haven’t changed in the last century.
These are big beefy differences between game design and traditional art that have a deep impact on the process of creating a game. When your team insists on following the model of a single grand designer, expect the following:
  • Communication issues come to a boil: Team conflict increases as people feel they are not being heard. Talented team members may leave the team.
  • Artistic quality is low: When one person makes all the decisions, they tend to ignore the expertise that is inherent in all the other team members. A thousand little decision that could have been made with expert knowledge are left up to a single person who cannot possible understand all the nuances. The result is Star Wars Episode One.
So when you get down to the practical matter of making games, the historical metaphor of the lone creator offers few if any practical lessons. Certainly, the tale of the lone creator is appealing and perhaps inspiring, but by no means does it represent the pragmatic sweet spot of modern game development. Instead consider the following:
  • Train everyone on the team in design. There can still be someone who champions design concepts, but everyone on the team should know the techniques, practices and philosophies of game design. If the lead designer is hit by a bus, the rest of the team should be able to quite merrily finish up the project.
  • Use a coaching model to lead the team. Instead of saying that there is a king figure from which all design flows, push out responsibility to the team members and use leadership positions to encourage learning and transfer of wisdom. The best game design ideas will come from the devs in the trenches. It is the leader’s job to unblock the flow of ideas from bottom, not push ideas onto the team from the top.
  • Reward the team, not just the leadership: Everyone on the team makes the game, not just a few leaders. It is easily to fall into the trap of ascribing success to the inspired leadership and failure to the team. Act against the biases inherent in our damned monkey genes to prevent stratification within the team.
What happened in the rest of the world
Much of this advice may seem counter intuitive or impractical. The majority comes from hard won experience trying to fix systems that were broken.

Just as software development was discovering the tenets of “Do it right the first time,” manufacturing was abandoning intensive upfront planning and design. About three decades ago, Japanese firms introduced the concept of lean manufacturing with an emphasis on strong team work, continuous innovation and just in time delivery. Decisions are made as late as possible when the most information is available. The workers at the lowest levels of the organization drive innovation, not planners detached from actual work conditions.

Lean manufacturing brought about a revolution in manufacturing efficiency. Quality and innovation increased while development times plummeted. The massive planning phases and risk avoidance of previous generations turned out to be more of a burden than a benefit. Those who did not adopt the new agile methods of production where driven out of business.

I expect a similar transition to occur in the game industry over the next decade or two. The market abhors waste and our industry is currently very wasteful of its development talent.

Lessons from the straw man
There are many game developers who no longer build their games using massive upfront design with regimented silos of specialized workers. Throughout the industry there are bright spots of individual developers doing great things to make the process of game design more agile and responsive to customer needs.
  • Valve is known for its cross functional Cabal system.
  • Spore is known for its strong prototype driven development and procedural content
  • High Moon is known for its agile software development techniques.
We are all trying to design a great game. It is worthwhile to note what does not work. More preproduction is not the answer. Bigger teams are not the answer. Finding the one right game designer is definitely not the answer. Game developers need it burned into their skulls that project that follow the “Get it right the first time” philosophy tends to be devoid of innovation, over budget and lacking creative cohesion.

The process of game design is undergoing a fundamental shift. As an industry, we moving beyond our primal fears of failing to complete a game and are beginning to ask “How do we build the right game?” In order to do so, we must throw away many of our borrowed practices.

So if game design is not the act of a creative genius passing down tablets to the team from on high, what is it?
  • Game design is about listening to customers and getting rapid feedback on working software, not writing fantastical design novelettes.
  • Game design happens throughout the development process, not just in the pre-production phase.
  • Game design is a collaborative team activity, not a solo activity.
Take care

Lean software development: An Agile Toolkit for Software Development Managers
This book is a good overview of how lean manufacturing concepts can be applied to software development. Of particular interest is the concept of ‘waste’. Highmoon claims that some of the exercises suggest a 50% reduction in cycle time is possible in their current development techniques. That is awesome.

Valve’s development process
Valve is a fascinating example of applying many of the principles mentioned in this article to a linear “Disney ride” FPS.

An illustrated explanation of reality of game design planning
I love these pictures. They are so spot on.

Agile development blogs


  1. Danc,

    Your perspective is unique, and your insight is deep. Any chance you're going to apply any of this to actual game development anytime soon? ;)


    Here, over two articles, is another point of view, in case you have tens of minutes to spend reading at some point:

  2. That is profound stuff I'll apply well to the company I'm helping to found.

    Thanks for writing this.

  3. Hi Danc,

    I've been reading your articles for some time now, and I always enjoy learning from your experiences and your words of wisdom. Interestingly, my own game project's direction follows much of the design concepts you describe above.

    As a hobbyist developer, I've more or less had to become a jack-of-all-trades, working on the engine, graphics, sound effects, writing theme music, and so on. Though I try to find help where applicable, it's not necessarily a simple thing to find like-minded AND interested folks willing to dedicate spare time to someone else's project :)

    (On a side note, with regard to the graphics-side of my project, I'd like to thank you for the amazing tile graphics articled elsewhere on your site, which I plan on featuring in my game!)

    One of the most useful design examples I've found is the .plan file, or some variant progressive versioned feature list. Starting small with a basic "navigate and interact" engine, then add features as time passes, according to the plan. Though it's sometimes necessary to re-evaluate core components and how they interact with other sections of the engine, leaving them relatively open to restructuring benefits the game project as a whole, if a previously-unplanned feature needs to be exposed.

    I expect the rise of the hobbyist will become more popular as time progresses, given the seemingly stagnant nature of the game industry at present!

    Looking forward to your future articles...

    Best regards,
    - Peter K.

  4. Danc,

    I'm currently teaching a class that's entirely focused on rapid prototyping. I've been teaching WHAT to do; thank you for writing such a solid essay on WHY it's important to do it that way.

  5. *Grin* Harold, you keep me honest.
    Right now I'm happy providing folks with the occasional free graphics. They help folks like Peter K. make games without needing to expand to a two person team with a full time artist. Other than that I'm just a guy with a blog. ;-)

    I've read the Steve Yegge posts. He is ranting against the hype. Good for him! People hate having Big Capitalized Things imposed upon them from above. Even the best idea tends to fail if you don't believe in it. Lean manufacturing is widely considered to be an overwhelming success, but there are dozens of US companies (*cough* GM) who are still struggling with the concept because they tried to force it onto the workforce. So stupid actions by managers throwing buzz words are bad. Agreed. But small teams that have close contact with customers and can react to new information is still a good thing. I *know* that you live this scenario every single day of your life. :-)

    Peter K.
    Being a successful single developer is a fascinating topic. It is a hard path, but one that is certainly possible. One trend I've noticed is that most successful indie developers have at least two people working on the project. Sometimes you'll find someone who is a designer / coder who outsources their graphics work. I remember a game called Faery Tale on the Amiga where one person did everything.

    I believe that individual developers lives can be made easier through the use of mature tools and readily available collections of art (like those tilesets). This lets them mash together interesting games instead of wading through all the nitty gritty of building a game from scratch. I don't know if you get the full creative boost of having multiple minds look at a problem, but some folks manage to produce great stuff in spite of all that. :-)

    take care

  6. Ho boy, that's pretty dense. Nice comeback after all the wedding break.

    Of course, I'm obliged to shoot you down in a hail of bullets, so here goes :)

    There's three things that I think undermine this essay:

    1. Game development isn't software development, it's entertainment development.

    2. Entertainment development has historically always relied on single or small group voices, and games are not that different. This is because game development, like entertainment development (but unlike most product development, including software) has no optimal condition.

    3. Entertainment development has always scaled badly when poor methods and poor people rule the roost. Just ask Hollywood.

    The fact is simply this: Most game developers are poorly trained creators. That's why the games they mostly make suck. They are great at developing things, they are sucky at so-called vision holding. And worse, most designers old and new are pretty bad at that doing that too.

    In the US TV industry, successful shows usually have what's called a "showrunner" at their head. He's the Executive Producer who is also the head writer who basically holds the whole thing together in his head. In film, this position is occupied by the director.

    Both film and television have required generations of people turnover to come to that point, however. It took that long for the requisite understanding skill to emerge and for the business conditions to be right for that sort of person to step up. Games are just not there yet.

    Are there things wrong with the methods employed today? Yes yes yes there are. Largely this is because these methods are borrowed and applied badly. Whether it be the silly-long game design document or the milestone process, there's a lot of bad ideas still floating around. They will take time to purge.

    However, the big myth coming from the other side is that the small iterative team can scale up. The history of game developmeny counters that to a huge extent. Many many are the companies who have had very successful small roots only to see their fortunes turn to ashes once their production needs got big. Those small teams were fast iteration houses exactly in the mould that you describe. They don't scale up, and when the indie houses of today making their neat little games like Puzzle Pirates decide tomorrow that they want to grow and make more elaborate games, they will run into the same problem. They don't scale up.

    The simple fact is that when you're working at a certain size, you have to work in a different way. That's what the film industry and the TV industry discovered, but those discoveries took time. It took time for people to become sufficiently aware of the medium away from the technical or business considerations to understand its strengths and weaknesses.

    This process is happening in games today with the promotion of the designer and producer classes to the running of projects, but it is painfully slow because these people are learning what's involved for the first time, most of them are ill-suited to the task and a lot of the pressures that come upon them come from all sorts of sources wholly unconcerned with how good the game is or not.

    What we need, and what we will get in time, are gamerunners. People who understand what videogames are and what they are not, what documentation is for and what is not for, what teams are able to do and what they are not, and mostly importantly what audiences are primed for and what they are not, and they will deliver. In whichever model we choose to operate, be it retail or subscruption, the mid- to large- scale project needs a gamerunner, someone who can hold the whole thing in his head, enable his team to be creative, foresee the pitfalls and basically bring the whole thing home.

    That person's day is coming, and has arguably come in Japan to a limited extent. The West will get there eventually, but it will take time.

  7. It's surprising how many of those could be summarized as "use your common sense and don't be a zealot". :)

  8. Strange how we came to so close conclusions via so different roads...

    Still I'm not sure I'm getting the "Rely on reusable game mechanics instead of one shot level design" part right. Let's take Shadow of the Colossus. Reusable, simple game mechanics used for solving each problem/level/colossus all right. But each of those's still got an interaction unique to it, and that's part of what makes such a (beautifully) sparse game work.
    Psychonauts, for just opposite reasons also comes to mind: given the strong relation between character/level/story design choices, loads of things end up being not reusable. You wouldn't want it any other way (the infamous Milkman Conspiracy level works, like lots of this game's levels, by contrast. The wacky use of props can't be replicated if it is expected to hold full effect, the same way the voluntarily clunky control of Lungfishopolis can only work gracefully once).

    (Of course, it's just that the "Rely on reusable game mechanics" rule is superceded by the golden rule: "use what works"... stupid me.)

    Though I'm pretty convinced you got the working structure right, I still feel a good artistic direction is key to a great game/artistic creation (though not necessarily to a good one). The example you used of Star Wars Episode One as the end result when "one person makes all the decisions" immediately sent me back to that counter exemple: Akira Kurosawa's Ran.


  9. Danc,

    hehe, I didn't mean to call you out. I was just poking fun. You're definitely on the middle path to software development enlightenment, and I thank you again for sharing your glimpses of nirvana. (:


  10. Can small teams scale:
    Yes. The trick is to have multiple small teams instead of trying to add more people to the same team. This is not an obvious solution to many people, so it takes a bit of discipline. High Moon is doing this right now. The company I'm at now does uses feature crews with reasonable success. Scrum teams scale this way quite often.

    Here is one book on the topic
    Agile Software Development in the Large

    "Rely on reusable game mechanics instead of one shot level design"
    This is certainly a mildly controversial idea in the essay that I'd like to expound upon more at some point. It requires a major rethinking of the need for level design, one of the big pillars of many modern game genres.

    Games are about helping the player enjoyable explore a possibility space generated by the interactions of various game mechanics. One technique that we use is to present the player with easy to digest slices of the possibility space in the form of preset levels. In a large sense, these levels are tutorials. Unfortunately, hand crafting a series of static levels is expensive and tends to result in throwaway content. The player uses the level and moves on. The player would like an infinite supply of unique content. As a developer, you must strike a balance since any content costs you money.

    Developers who can figure out how to create more interactive and compelling experiences for a lower cost of production gain a strong competitive advantage. The invention of such techniques tends to obsolete genres over time. I have an essay around here somewhere that ties the lack of economies of scale in adventure games to their eventual demise as a genre. All that one off content (or Kleenex content) became too darn expensive as quality expectations increased. So part of my answer is “Throw away genres that require inefficient production models”, which is something a lot of genre addicts really don’t want to hear.

    Since the current industry is still fixated on Kleenex content, a good blunt rule of thumb to keep in mind is "Any content that is only used once should be eradicated from the design." Trust me…you can’t help but create something innovative. :-)

    One leader to rule them all:
    The ideal of the single person with vision runs deep in our culture and our personal dreams. When you argue for the predominance of an artistic leader on the project, aren't you often picturing yourself in that role? "My children and mate will feed well during the dry season if I ascend high enough in the tribe." Such beliefs are built into us. They also happen to be encouraged by our culture (especially for young men)

    Putting aside that ego when working in a coaching role with a team of talented people is difficult, but certainly worthwhile. Done correctly, you end up with a half dozen creative sparks instead of just one. This experience can be quite delightful. :-)

    Is there still a need for leadership? Absolutely. I find, however, that the leadership role will shifts from person to person remarkably often in a well functioning team. People take responsibility. This is a good thing that is to be encouraged. Won’t there be conflict if there are too many cooks in the kitchen? It is good to have some agreed upon fallback mechanism for breaking ties. Honestly, the best thing is to have a strong shared vision of the product. Having an identified customer that everyone respects and can listen to is a wonderful way of building that vision.

    Is game development software development?
    I borrow a lot of metaphors from software development because that is what I know. I also know art quite intimately. Game development has aspects of both. On the whole, I feel the games industry has borrowed far too much from the movie and television industry and not nearly enough from the strengths of our own medium.

    The key to games is that they are interactive. Without that, there is nothing new worth talking about here. We all might as well go back to making film or some other horribly dry method of entertaining the masses. This is games we are talking about! Where is your sense of adventure? ;-)

    Of all the activities in our history, the creation of tools and the development of software offer the most lessons on how to create interactive products. Let's suck the tender marrow out of these disciplines and use it as additional material to build our own unique language.

    take care

  11. Can small teams scale:
    Yes. The trick is to have multiple small teams instead of trying to add more people to the same team. This is not an obvious solution to many people, so it takes a bit of discipline. High Moon is doing this right now. The company I'm at now does uses feature crews with reasonable success. Scrum teams scale this way quite often.

    In software development, sure. But like I said, game development isn't software development.

    The typical entertainment development cycle works in a scenario where a small nut of people (or individual person) spends a long time developing an idea, prototyping it if you like. Novelists go through dozens of drafts, songwriters spend ages just messing with music to see what they can discover and so on. This is the equivalent of the fast iterative process that you'v described above, with which I have no issue. The issue comes in when you scale up.

    I don't know if any of you have ever been involved in producing a play. I have. Plays are anarchic affairs, let me tell you. Everybody has ideas that they want to explore, from the actors to the costumers, about what they could do.

    Typically, a good director uses workshops to explore the play. This is the equivalent of the scrum technique, in which many different avenues of ideas are explored by different groups, but they are so under the gaze of the director. Why? Because since there is no optimal condition in entertainment development, unlike product development, somebody has to make sure that all these workshop teams are steering toward the correct goal. Lack of direction means ideas pulling on each other in a dozen different directions rather than complimenting each other.

    Eventually the good ideas from the workshop which fit the director's vision are kept. The good ones that don't are not. At that point, production becomes much more military. The pressure is on to get the play made and ready on time for opening night, and everything drives toward that.

    This is the same process that drives good game development, although in game development the scale is typically longer. Poor game development arises either from the overly-precious central designer/developer who won't let his team workshop from the start, or the directionless do-anything team that never makes a decision. Lacking any sense of an optimal condition, a directionless team will faff around doing whatever, agile scrum or no.

    What developers need is a gamerunner, like a theatre director, that fills in that optimal condition. Following on from that, what many developers need (and sorely lack) is a convenient way to prototype ideas that doesn't involve big spends of cash. I'm amazed at the number of developers who have not cottoned on to the use of the likes of Blitz 3D as a prototyping tool. Rather than waiting weeks or even months for a C++ engine to be ready to test ideas in, prototyping an idea in Blitz takes days. It's quick, it's dirty, but it gets that job done. Many developers do not work smart that way.

    Is game development software development?

    I borrow a lot of metaphors from software development because that is what I know. I also know art quite intimately. Game development has aspects of both. On the whole, I feel the games industry has borrowed far too much from the movie and television industry and not nearly enough from the strengths of our own medium.

    The only thing that I ca see which the games industry has borowed from film and TV is the mis-applied use of the language of storytelling in most places. Developers often talk long and loud about storytelling possibilities of the new medium etc etc, but their production methods are classic software development in most ways.

    The other thing that the games industry fails to take away fro the film and TV ideas is the sense of the importance of fresh ideas. TV and film, for all tat you might say of them, are 80% original content. Games, by contrast, are about 20% original content. TV people have an innate understand that ideas matter. Games people do not know why ideas matter and think that the idea doesn't matter because the consumer is an idiot anyway.

    Games have actually borrowed a hell of a lot more from the recording industry than any other. The recordind industry is what has determined how developers get paid. It is also the industry that has informed most of our thinking about who we target, the almost mechanical process in which we do that and so on. Most software publishers think of games as an equivalent to the other great Youth Entertainment, pop music, and they spend money in the same way, looking for the lavish glitz (i.e. the music video) and not really caring so much about the quality of the product because they feel that their core audience is too dumb to tell the difference.

    The key to games is that they are interactive. Without that, there is nothing new worth talking about here. We all might as well go back to making film or some other horribly dry method of entertaining the masses. This is games we are talking about! Where is your sense of adventure? ;-)

    I watch Battlestar Galactica every week. Dry it aint :)

    So here's my view on that. Yes, games are interactive. But unless you have a creative vision to do something with that, so what? You're just going to end up making shooters, Match 3 and the like. Without a gamerunner in the middle the mid and large sized game team inevitably drifts toward blandness, committee thinking and the idea of an optimal condition. Unless someone knows the direction that the whole game is heading in, what you get is something without any soul.

    Of all the activities in our history, the creation of tools and the development of software offer the most lessons on how to create interactive products. Let's suck the tender marrow out of these disciplines and use it as additional material to build our own unique language.

    They also carry one huge non-lesson, which is the optimal condition. I've used that phrase a lot, let me explain it.

    "Optimal condition" is the sense that something is on the track because it feels good. In software design, for instance, the interface of an application has an optimal condition where there are enough buttons to use so that most of your customers find it pleasing to look at, not confusing, but also not like it treats them like a simpleton.

    A lot of product development follows the same course. Car manufacturers want to make their customers feel great, toothpaste manufacturers likewise. As a result, there is a definitive sense of what the product developer is aiming for, and that sense is all about obvious customer satisfaction.

    The problem for entertainment developers is that there is no optimal condition for entertainment because the goal of entertainment is not obvious customer satisfaction. It is customer satisfaction achieved through surprise.

    So for example, first person shooter games. There are equal cases to be made in first person shooters as to whether you use a target locking system or not, whether you use a strafe system or not, whether the enemies move quickly or slowly, and all of these decisions have no optimal condition. There is no one definitively right solution. Instead, it's all about context, about whether the decision is right for the game in question. That decision can only be made by someone who understands the whole game, just like in theatre by someone who understands the whole show.

    A director figure is essentially a substitute for the optimal condition in entertainment development. Since there is no definitively right answer, he or she becomes the source of that answer. And games, being as they are entertainment development, are no different.

    If games are going to move forward and become a sophisticated medium then this is a problem that they have to face. Many developers believe, as Danc does, that games in fact DO have optimal conditions and if they can only find the right mechanics and technology then all will be well and the next evolutionary step will have taken place.

    This is, in my view, not true because there is no such thing as the right mechanics and technology. There is only the right mechanics and technology within the context of the game that you are making. There is no optimal condition.

  12. While I agree that the game development process has to evolve to accept more user input in the latter portion of development, I don't necessarily agree that preproduction does not have signficant benefits.

    For complex game systems, particularly for computer RPGs, detailed game systems can be designed in pre-production prior to any coding or art beginning, and a large number of game problems can be eliminated at the paper stage. Furthermore, detailed predesign of these features allows the common elements to be abstracted out, allowing the game to be designed as a collection of *systems* rather than as a large number of ad hoc implementations (as most cRPGs are developed, to their infinite detriment!)

    The same argument applies to strategy games, and particularly to adventure games. It does not apply to all game styles, of course. :)

    Then there is the Japanese form of preproduction, making a prototype which you later scrap. Also a powerful tool for ending up with a better game, although an approach that doesn't necessarily contradict what you say here.

    I think you're too hard on the preproduction phase, although I recognise many of the issues you mention as valid.

    When I look at the games I have made, however, the preproduction phase has been of equal importance to the user input phase - for Discworld Noir, the preproduction phase was vital; there would have been no game without it. Deferring decisions to later in the process was simply not possible for this style of game - the story and gameplay are linked, and had to be developed more or less completely before anything else could begin.

    However, I recognise this says more about the styles of games I make than it does about the game design process in general. :)

    Best wishes!

  13. Great stuff. This is exactly how I work myself. I think i will send that article to my project planner in order to help her understand why I give her so much headace by not giving her 3 months in advance final answers :)

  14. Your Agile development points remind me of Extreme Programming. Anyone reading might want to take a look at:

  15. Is preproduction bad?
    Hi Chris! I'm a huge fan of many of the activities that occur within preproduction.
    - The exploration of game systems
    - Prototyping
    - Concept development (and perhaps even testing)
    - Market research

    What I'm proposing is mixing preproduction, production, and testing together so that these important activities are happening constantly throughout development (bundled together in self contained iterations) instead of being separated into long blocks of time. Instead of 3 months of preproduction, you might have a 4-week iteration near the end of development where you are still able to prototype a design.

    The phase I'm probably most hard on is production: that highly expensive period where people are sitting around making Kleenex levels and polishing Kleenex graphics. :-) Many teams could certainly benefit from more play testing and regular integration during this phase. The rapid adoption of in game editors and short testing pipelines are a great step towards making production more responsive.

    But if you really want to take these suggestions to their logical conclusion, adventure games are the least likely genre you'd develop. Their content requirements introduce a massive amount of fragility into development. Change the flow of the game mechanics in the small way and all the art for a particular section must be reworked.

    A better example of a title that could benefit from this is something like your Fire game with a few modifications. Instead of having a large number of puzzle-like levels that are manually created by the developer, you can offload the fragile/rigid aspects of content development to either:
    - random map generation (something I know that many find abhorrent, but has its place if you build the game around it) or
    - User tools that allows users to build, share and sort levels easily.

    Either method reduces the rigidity associated with having fragile content tied to game mechanics...I think of it as decoupling or 'refactoring' the game design from a production perspective. This in turn allows you to iterate more rapidly on key game mechanics without worrying about smashing your game to bits as you near release.

    *grin* On the other hand, many companies are successfully applying many of these techniques to existing genres so I shouldn't be too crazy in my descriptions about the types of games such practices suggest. :-)

  16. One leader to rule them all

    Well, I do think a head of devellopement of some sort is necessary to achieve greater results. As I said, the collective/consensual way of doing things may prove incredibly efficient at making competent/succesful products. I'm not convinced it is fit for making greater ones. Making decisions collective, when it works, tends to end up with that blessing and curse of democracy: mediocracy.
    Don't misunderstand me, I agree that an empowered pro-active (set of) team(s) is the way to go. I also agree that for day to day menial managment, leadership can be swapped. But I still feel the need for a tight leadership (even if a collective one, which I think is adapted to the specificity of game making, I'd say three persons no more is good, two for games aiming at being non-narratives). Impulsions and energy need to come from the whole team. From personal experience, I don't think direction can. Even the loose and hyper decentralised structure giving birth to a product like a newspaper need an editor in chief who ensures the paper's keeping its supposed defining characteristics.
    Look at Kojima's team.

    Honestly, the best thing is to have a strong shared vision of the product. Having an identified customer that everyone respects and can listen to is a wonderful way of building that vision.

    To keep things clear, I have first to say my personal interest is in video game as a narrative (the term is deceiving, but I haven't been able to find a better one for now) medium, which I believe it always is, even in a simple form, when it starts to differentiate itself from pure games.

    That being said, I fear listening to the customer proves in the end to be really limiting. Enternaiment is the providing of experiences, this is all the more true with games. You cannot expect a customer to ask you for the experiences he cannot yet conceive, or for the ones he wants to be shielded from.
    Listening to the customer limits you to pure escapism (a worthy genre, but only part of what you can offer).
    Listening to the customer for creating experiences won't give you Evangelion's masturbation scene. It won't give you music like Sylvain Chauveau's or Alva Noto's. It won't give you Un coup de dé jamais n'abolira le hasard (a verse that kept me pondering on game making for quite some time) or 1984's torture scene.

    I know...this is where the respect part comes to the fore, respecting your customer is knowing when not to listen to him. A really rare skill, difficult to devellop.


  17. Well said MD.

    There's just no way to get around the fact that entertainment and surprise go hand in hand, whereas product and recognition go likewise.

    As I said before in a blog post in the distant past, this means that some types of games can be viewed more in the product mold, particularly sports games and creative toy sets, but some games just can't (including most single player games).

  18. "You can't optimize games"
    I've yet to see a game made that doesn't shape itself in a major fashion based off customer feedback. Oh, except perhaps for the ones that absolutely sucked.

    - Play testing = user feedback
    - Prototyping with customers = user feedback.

    These are optimization activities. They are seeking to make an 'optimal' product. Most good games do them. Almost all great games do them as often as possible.

    You can stick yourself in an sensory deprivation box and play the game alone with no external feedback and you will fail. Congratulations, you brought something pure and wonderful up from the bowels of your individual mind. This is like driving to Texas with a blindfold on. Sure, you can do it, but why? The goal is to make a great game. Use whatever is available to you and don't let ego stand in the way of greatness.

    Listening to the customer is a source of inspiration, not a set of shackles. It gives you a broader perspective outside of your own limited world view. Do you want to make a game that multiple people will enjoy or just yourself?

    Enough with the references to great Kleenex experience you had in other media. Yes, you like Battlestar Galactica. Go make a TV show. Yes, you like Evangelion. Go make some anime. If you want to use games as an excuse for getting people to read your novels, just write a novel in the first place.

    Games are about interactivity. They are about player learning and exploration, not Disney rides. Deep understanding of how players interact with complex systems comes from watching players interact with those systems, not artistic hope that it will all work out because it sounded good in your head.

    Happy day,

  19. Enough with the references to great Kleenex experience you had in other media. Yes, you like Battlestar Galactica. Go make a TV show. Yes, you like Evangelion. Go make some anime. If you want to use games as an excuse for getting people to read your novels, just write a novel in the first place.

    God, I wish I had a nickel for everytime someone gave me a dirty look for saying the same thing. While Final Fantasy might be an enjoyable entertainment experience for someone - it is not actually a game. I think there is obviously a market and art to making such products, but the are something quite different than games.

    There's a lot of good debate in this thread, but in the interest of brevity I'll only add the following:

    - Nothing beats having a clear idea of what your making, and a few simple comparisons to backboard anything against. For Guitar Hero, it was simply "Does it rock?". Everyone knew exactly what the game was going to be from day one, and just went on instinct. We've also realized that this kind of clarity is hard to manufacture - sometimes you just get lucky.

    - There is value in Cowboy approaches, and I prefer them over waterfall approaches or a badly implimented agile approach. Both GH and Asheron's Call, probrably my two best games, were incredibly light on planning and incredibly strong on cowboy. Don't get me wrong, a little process and planning can be a great thing, but I've noticed people can waste as much time on these issues as they do worrying about some design feature they won't impliment till next year.

    - There is simple relationship between creative control and company heriarchy. As you go up in the heriarchy, you should loose creative control over details. The higher you go, the more you are a condiut and the less you are a decider. Failure to recognize this is one of the largest problems in the industry.

    - If someone is to have final say (which I view as a good thing for comunication/ownership issues), then they're goal in life should be to use it at the absolute last expense.

    As usual, always a good read..

  20. But Danc!? I like Poke'mon... and that's both a show and a game!



    PS> Had the baby... sent you an email...

  21. All right, I guess I need to explain myself a bit more, for I'm being taken for what I'm not.

    Every game can be described as a movement/collision system as defined by Deleuze in Cinema2 (the tool was created for movies, but it works even better with games I think. Maybe I'm wrong in my approach, and if you can prove it to me I'll be happy, it would help my work progress) founded by an artificial rule, and destined to be experienced (best translation I could find for "éprouvé", you'll have to indulge I'm translating from my personal notes in french).

    Games focusing on collision are the ones we call ludic. Chess is a perfect exemple of a ludic game: you can record a whole chess match just by recording collisions. In such games, collisions make movement. Space is only the margin (bad translation of french "jeu" as margin + looseness) necessary to allow new collisions.

    Games focusing on movement are the ones we call paidic. A role playing game is a perfect exemple of a paidic game, you can throw out the window the whole complex system of rules of such a game and it will still be playable and enjoyed as it is supposed to be enjoyed. In such games, collisions are only useful to keep the movemnt going.

    Now in that lecture grid, the real specificity of a video-game isn't interactivity. As of now a role playing game is infinitely more interactive than a video game.

    What makes a video game a video game is:
    a) the actualisation of game as space. When you play monopoly the board isn't the game: it's just a tool helping you grasp the space founded by the rules. You could just as well play without it the same way you can play chess: by recording collisions. In a video game the space is the game (I'm over simplifying here, the relationship is a bit more complex and fascinating, but I hope I'll get the idea accross).
    b) the possibility of time. A pure game doesn't know time. It's inexhaustible. You can play tag till the end of your life once you started playing (there is a nice short story on that subject by Bruno Leandri). You can always replay chess, each party being a different iteration added to the previous. Video games are the only games who can know time, a result they get from their ambivalent relationship with narrations.

    Now when I use the word narration, I don't necessary mean "stories". Lets take a simple exemple of time creeping its way into game. You create a simple coordination game called Space Invaders. Then you decide to update the game and add a new, harder problem of the same kind to add some tension. That new problem becomes a threshold to the next difficulty level. It is soon affectively called "End Stage Boss" by players.
    Time has appeared. Narration is the tool by which it came. They go hand in hand.

    What I meant by "my personal interest is in video game as a narrative" is that I'm interested in the time aspect of video games. I'm not interested in creating "kleenex" media for anyone. In all probability I'll hate the consumer of anything I produce, and it's not worth it on the economical level (I'm a pretty mean spirited individual all in all, I guess). I'm not interested in making a game.
    What I want is crack open the problem posed by video games. By extension I'm interested in the making of a game.


  22. While I'm a it, to me, heads of project:

    1) Game designer (synchronic elaboration of the functioning of a game)
    2) Level designer (diachronic elaboration of the functioning of a game)
    3) Writer/Author/Whatever you'll call it (temporal elaboration of the game)

    I'm still not sure about 3, it's the latest addition, and I'm not certain it needs to form a triumvirat with 1 and 2. But I'm going that way for now. What I'm sure is that whatever you'll call it, it will need very peculiar skills and tricks, and not just importations of some from other media.


  23. Hey Danc,

    RE: Optimization

    What I said was that entertainment has no optimal condition. What that means is pretty simple. It means that there is no gold standard always right solution for a piece of entertainment. You can have two perfectly valid ideas in entertainment development which both have equal merits, and yet sometimes one works for one project, while the other works for the other project. And the only thing that divides the two is the nature of the project itself.

    This is not the same thing as optimization. Optimization is the point at which, the major decisions and direction of the project having already been taken, you get into the business of refinement, tweaking and editing. That happens in every form of entertainment as well.

    To go back to my theatre example, it is very common in shows for one or more full rehearsals to take place before opening night. During these rehearsals, the team is basically testing whether their project is not quite working or not. Other members of the production crew watch the rehearsals and give feedback, which is analogous to testers. The two most important rehearsals are the technical rehearsal (to make sure the light and sound cues are working) and the dress rehearsal, in which members of the public come in and watch the show, their feedback is judged and so on.

    Depending on the results of these rehearsals, the director will make changes to the show. Sometimes a line that everybody in the cast thinks is funny just doesn't work in dress rehearsal. Sometimes a technical sequence turns out to be not what it was hoped. Changes changes changes. They're basically optimising.

    On the other hand, there is no way that you could develop a play by bringing the intended audience into it from the ground up. It's simply ridiculous because you don't know at that stage what kind of show you want to do, where you want to take the direction, what scenes you want or need. Because shows have no optimal condition, feedback-oriented creative processes result in loops which try to discover something. Usually discovering nothing.

    This is fundamentally different from developing, say, a web application, a toothpaste, a car, a credit card service, a tomato ketchup, a cigarette, a brand of whiskey or a bicycle. Why? Because in all those cases the key factor in product development is customer satisfaction based on appeal and familiarity. With product development, you know when something is not working because it doesn't match up to the optimal condition: customer satisfaction. With entertainment development, you never know that because the goal of entertainment development is different.

    That's why this thesis of yours of games-as-products fundamentally falls down. We are entertainers, not application developers, and the rules are different.

    This is like driving to Texas with a blindfold on. Sure, you can do it, but why? The goal is to make a great game.

    I can define "great car" because that means "Great to drive, feels great, great features, great fuel economy" etc. Define "great game".

    "Great gameplay experience"? In what context. Gameplay is as varied as football and Chess to puzzle solving in Maniac Mansion or solving a Sudoku.

    "Great challenge"? Many games incorporate challenge, sure, but many do not, including those creative games, mmorpgs, toy games like Animal Crossing etc.

    "Great exploration?" Some games, sure. On the other hand, many games, especially sports games, have sweet FA to do with exploration.

    "Great rules?" Maybe. But then again what about games like Grim Fandango and Neverhood where nary a rule number ever turns up?

    "Great storytelling experience"? For a few perhaps. But what about the great many games that have nothing at all to do with stories?

    "Great emotional experience"? Perhaps. Then again most strategy games are not noted for their emotional content.

    And so on. It's exactly the same as answering the "great film", "great scultpure", "great stand-up comedy" and all the other forms of entertainment. What defines the greatness of any one piece depends on the goal of the piece itself, and that depends on the creative minds who came up with it. Unlike a car, comedy has no optimal condition, neither does music, neither do games. That games are cloaked in software appears to confuse the issue and make us think of software methods, but this is misleading. They are sources of entertainment above all else, and the rules of entertainment development apply.

    Listening to the customer is a source of inspiration, not a set of shackles. It gives you a broader perspective outside of your own limited world view. Do you want to make a game that multiple people will enjoy or just yourself?

    And how do you do that if by entertaining the you are trying to surprise them first and foremost? How do you surprise people if you keep asking them for their ideas and replicating them. You don't.

    A great example is these Pop Idol style shows, where the nation chooses a pop star in a talent show. It's a great expression of what the customers actually value and want, right there on television and text voting. And the vast majority of these people-chosen stars vanish without trace after a short period of time.

    Because they are boring.

    On the other hand, many musicians who explode onto the scene with a hot new sounds remain a good deal longer because they are interesting. Madonna and David Bowie are both fantastic examples of artists who understand that in order for a musician to remain a hot ticket they have to change their image regularly and refresh themselves in surprising new ways.

    Because it keeps them interesting. Hell, even Dylan went electric eventually.

    Surprise factor is vital in entertainment and you don't get that by pandering. Surprise factor is not vital in product development, and so keeping a careful eye on your customers and responding to them is vital. Product customers want comfort, and the golden rule of product design is that when a customer uses your product it should do what they feel it should do when they push its button.

    In entertainment, the button should do something unexpected. Something FUN.

    Enough with the references to great Kleenex experience you had in other media. Yes, you like Battlestar Galactica. Go make a TV show. Yes, you like Evangelion. Go make some anime. If you want to use games as an excuse for getting people to read your novels, just write a novel in the first place.

    Sort of missing the point there, Danc. The point was that these media that you're all too ready to label as dry are, in fact, not at all dry. It's a nice romantic world view to buy into the idea that interactivity = not stale and therefore all else = stale, but it's nonsense. Lots of interactive experiences are rubbish and you know it.

    Games are about interactivity. They are about player learning and exploration, not Disney rides. Deep understanding of how players interact with complex systems comes from watching players interact with those systems, not artistic hope that it will all work out because it sounded good in your head.

    Games are not about interactivity. That is the equivalent of saying that music is about rhythm. It is not. Games function through constrained interactivity and music functions through rhythm, but they're both about whatever the hell we choose to make them about.

    Some games are about exploration, some are about learning. Some are not. Some are about deep interaction, and again, some are not. Some games ARE Disney rides (best example being Rez).

    Knowing the field is important, having a feel for it likewise. This is also true of any creative field. A showrunner worth his salt just not just waltz in and make a bunch of stuff up. He knows his craft and knows the people that watch his show.

    That said, a showrunner worth his salt ALSO works from a deep artistic hope that it will all work out because it sounded good in his head. Vision is just that. A complex, subtle drama does not spring into life from audience interaction, and neither does a complex Japanese roleplaying game, or a game like Ico, or a game like Planescape, Grim Fandango or Deus Ex. Vision, that sense that the whole creative effort of the team is going somewhere that they may not see yet is absolutely vital.

    Yes, iterate.
    Yes, listen.
    Yes, experiment.
    Yes, observe.

    No, do not assume that this is all there is. That way lies blandness.

  24. I had a larger comment, but it started to get too wordy, so I deleted it and decided to go with this synopsis.

    Tadhg is right about the usefulness of having a highly skilled "gamerunner" with a detailed understanding of what the game should be.

    Danc is right that no one can ever predict what will appear down the road in a field as complex as this.

    I believe a fine example of the middle ground of both of these truths can be seen in David Milch as the leading vision (being the executive producer and head writer) of the show Deadwood. The man will spends hours agonizing over an individual paragraph of dialogue, delicately crafting every little detail of a script (think design doc) in advance of shooting. But when he gets out onto the set he's always tweaking the scene as a result of actors' and cameramen's input, and of the other insights that only appear when one is directly "in the trenches".

    An iconic all-aware leader with a complete and flawless vision of a game's eventual design and technology is a nice ideal, but no such person exists.

    That said though, a highly experienced designer who's job isn't to act as the design doc’s iron fist, but to instead act as the information-dump/go-to-guy(girl) for all of the emerging info about the game as it grows would probably end up creating a very optimized, glitch free, cohesive, and (dare I say it?) fun game.

    -Ian Dickson

    PS Since this is my first post here, I do kinda have to say that Danc, this really is an awesome blog. I always leave your posts with multiple new concepts and perspectives. If Psyconauts where to platform about my cranium, there's a reasonable chance they'd encounter a genre-king-concept based end boss or two. Soo, um..yeah, thanks for that!

  25. I can't help but feel that tadhg is missing the point somewhat.

    It's certainly the case that a project that lacks some manner of unifying vision will flounder but it's not the case that such a vision always needs to reside under the control of a single individual. Film, TV and theatre are all made created in roughly analagous ways and to some extent this makes sense, the fundamentals of acting, scripts, staging and audience are basically the same. But it really doesn't follow that because Film, TV and theatre are forms of entertainment then other forms of entertainment (computer games) should be created in the same. You certainly wouldn't write a novel under the guidance of a director. Also just because theatre then film have spent a couple of hundred years making (forcing?) the "single savant director" approach to work doesn't mean that it's the only approach to creating good theatre/film, it is merely one approach that can work that has been used extensively to the exclusion of all other methods. But, as an approach, it still often fails, there are plenty of crappy films and plays out there.

    What game development needs is to develop it's own methodology for effective game creation, cribbing too much from other entertainment methodologies is always going to leave you with a suboptimal development strategy. Those other strategies (TV, publishing, music production etc...) just weren't developed to handle game content creation. It's all well and good to say that game development is entertainment production and not application development but I think this is fundamentally incorrect. The game creation process today still owes more to and is more akin to application development than it is to anything else. Also there is a strong customer satisfaction component in game creation; I expect widgets to function in certain ways; I expect menus to work in certain ways; I expect collision detection to work in a self-consistent manner; and so on and so on. The games market is also heavily genre driven, once some group implements a game or mechanic in a notionally optimal way the consumer expects all other games to perform at least equivilently, most gamers have a huge amount of experience in what did or didn't work in given genres (although this also applies to other forms of entertainment, I know I poorly directed play when I see one). Consumers approach all products, be they games or toothpaste, with a set of preconcieved ideas and as such customer satisfaction is as measurable for games or TV as it is for cars or toothpaste.

  26. Thanks for the clarifications, Danc! It makes your position very clear, and quite sensible too. :)

    (Of course, I'm not actually making Adventure Games at the moment, in part for the reasons you cite and in part because there's just not a big enough audience for it anymore. Shame but what can you do).

    Because International Hobo is not a developer by themselves, i.e. we have to work with programmers and artists elsewhere, we can't integrate the preproduction phase with the production phase very effectively, so what you propose would be an ideal case for us at best.

    I'm certainly leaning towards agile work where possible, and Play with Fire (nee Fireball) was an example of an agile experiment, you could say.

    Nonetheless, I'm still going to draft and redraft cRPG mechanics 3-4 times before even going to the developer. ;) I find that there is practically no limit to the refinement (in terms of taking disparate elements and abstracting them into common systems) that can be achieved in the cRPG genre, and the cost of starting development without a solid design in this case is just too high - but this is definitely the exception and not the rule. :)

    And besides, I've chosen to work on projects I think are fun, and not specifically those that are have strong commercial prospects. For those commercial software developers that are still making games "the old way" the template you put forth here is a solid alternative to the rigid game development process that has become almost standard.

    Best wishes!

  27. My excuses for losing my temper and polluting with material unrelated to the problem at hand.

    Thanks to Ian Dickson for posting something closer to my own position and what I should have posted myself had I not allowed childishly my ego to get in the way. What he said was what I meant with my "Look at Kojima's team" comment.

    I know a poorly directed play when I see one

    Yes, but can you make it right ?
    I know poorly produced music when I hear it, that doesn't make me able to point at why it is so.
    As a linguist, a problem I'm often confronted with is native speakers being able to tell me if a particular use of words is wrong in practice even if it's grammatically correct, but unable to point to me to the reason as why it is so.
    Customer feedback is invaluable for tweaking. You cannot count on it to point directions to you (it can happen, but you can't count on it).

    You certainly wouldn't write a novel under the guidance of a director.

    Well, why would you need a director for a one-person job ?
    Actually our problem is slightly reversed here, but we do have some kind of a director: generally you've got an editor who'll give advices to the writer to help make his work marketable.