next »

[Graham.]

If we relied solely on prototypes, our designs would be seriously limited by the initial direction our prototypes took. I think a lot of the barriers that the industry currently faces, such as combining art and interaction, producing an original big-budget title with little risk, are a result of being unable to talk about ideas in a clear way. I think design documents are significantly harder to create than screenplays, like, the comparison between the two is almost funny.

Animals communicate largely through action. One of the key advantages of being a human is having the ability to discuss an idea, without having to execute it, in-order to communicate what we mean. If we relied solely on product for communicating with each other about games, our abilities to collaborate as developers would be limited to the same degree that animals are limited when communicating about anything. We're obviously not at that point, but we're a lot closer to it than away from it.

The reason games don't tell narratives the way books do, and certainly not to the larger public - they play Farmville and Wii Sports more than anything else for God-sake - is because we can't talk about designs in the way that we can talk about stories. Stories are something we already understand. We tell those to each other, and ourselves, all the time. Telling ourselves stories about the world is like, not a terrible definition of what thinking is.

Game design is a whole new frontier. Talking about a game's design is like talking about a system for generating stories. The difference between narrative theory and game theory is the same difference between raising a child and explaining to a child how to raise another child. There's no wonder why our children raise other children not nearly as well as we raise our own. We're programming authors instead of just being them. Design is like talking about the programming of authors. The public is like, "games are 'simple'," and it's like, that is the opposite of true almost by definition.

Can you imagine?

Think of it this way. We program games. We draw pictures and compose music and sound. Every idea is written down in some form or another eventually. There must be an abstraction for these things. There's an abstraction for everything. We just need to go find it.

I think most of the problems we have designing come from massive underestimations of how fucking hard it is. Like anytime anyone claims to have stumbled onto reliable design theory, they are like so far off, like I can't even put into words how far off they are.

[Paul Eres]

i think both prototypes and written design docs are enormously helpful (i mean for large projects -- small projects don't need them); optimally you'd have both. i think the designer should also be able to create prototypes; the "perfect" game designer would not only be able to clearly express his ideas on paper, but also be good enough at programming that he can create a prototype of his ideas in something like game maker

[Angrymatter]

i think both prototypes and written design docs are enormously helpful (i mean for large projects -- small projects don't need them); optimally you'd have both. i think the designer should also be able to create prototypes; the "perfect" game designer would not only be able to clearly express his ideas on paper, but also be good enough at programming that he can create a prototype of his ideas in something like game maker

what exactly is a prototype? As far as I know, I would want to make platformer with some nifty mechanic, I would just make bouncing squares with that mechanic. But if I wanted to make say, a cavestory clone or a heavy story based game that is otherwise pretty generic, then what would I do?

[Paul Eres]

if you're making a clone you don't need a prototype because the game you are cloning *is* your prototype. you'd only need a game if you are creating a game in a new genre or making a major change to a genre

[Angrymatter]

So THAT explains the current state of affairs.

[Medevenx]

So THAT explains the current state of affairs.

what does that even mean lol

[tha_Chiller]

Now starts the long journey of learning different parts of development; Code, Sound & Art. You don't have to learn them on a highly advanced level, but to really communicate with your team..yep. Also it can really benefit for your research when creating new design systems. Just learn a technical skill & be on your team, you can do it dude.

Yes..no one likes an 'ideas guy' but that doesn't mean you still can't be a kick ass Game Designer. An idea is worth 2cents but it can start a revolution.

[EdgeOfProphecy]

If we relied solely on prototypes, our designs would be seriously limited by the initial direction our prototypes took.

I disagree on this, since a tenant of prototyping is realizing that your prototypes are completely and totally disposable.  A prototype is simply a tangible way to test an idea, something beyond the sandbox of your head, it is not supposed to be the roadmap to a complete game.

Let me clarify, a design doc on a totally untested idea is a tremendous risk.  You're basically guessing what's going to be good without ever trying it.  It is my opinion that even seasoned designers need to actually try out the concepts they're working with in a prototype to be sure that it's worth full production, because game design is so very complicated that it's just about impossible for a human to reliably and repeatably perform strictly in their head.

I also take exception to the monolithic design doc.  If it's something that you, as the designer, need to organize your thoughts, that's fine.  If you're trying to convey your ideas to other people (which seems to be the goal of most design docs), it's a complete disaster.  Few people are going to read or understand a 200 page document specifying every detail of a game, and even fewer are going to give a damn about it.  If you want to describe your ideas to people, or detail the implementation of features, you need to think first and foremost about how to deliver that information to your target audience in way that they will:

A)  Understand
B)  Give a shit about

Otherwise you're going to have people who don't read your design doc, or people who don't accept/understand it and botch the implementation of the design.

I do totally agree that this whole game design thing is a pretty new frontier.  Part of the problem is that a lot of games are rather abstract in form, and thus its hard to tap into the universal vocabulary of the human experience.  This can make it tough to explain games to people who are not already intimately familiar with the medium.

[Graham.]

I think it's tough to explain games to anyone.

Prototypes are important. I prototype the shit out of everything, like as soon as humanly possible. If I think, "here's something that has a good chance of being something I'd put in the game," I prototype it immediately. As soon as my confidence in the idea arrives, I build a minimal prototype. All of the game industry is going to learn to revolve around a couple of key points. One of those points is going to appear after we learn how to optimize that prototype loop into dust. The process goes like this:
  Step 2. Build a minimal prototype for an idea that you feel has a good chance of going into the game.
  Step 1. Have an idea that will allow you to progress to Step 2 as soon as possible.
Repeat.

However. The steps needed to do Step 1 well are complicated. It is very hard to know what idea belongs in your final product without considering the totality of your entire game. Rich experiences are about inter-dependencies. In other words, you need to know every other piece of your game to make a good decision about the current piece. Without strong fore-sight, it is very easy to take baby-steps in circles around whatever your original ideas were, and never go anywhere nearly as deep as you dream about. Games like Minecraft spent years bubbling in the minds of their creators. Notch prototyped hard. He friggin' released on version 0.01 or something. But, he thought about games, his games, other games, his "game" that he'd make when he had an opportunity, a lot. When he pumped the first prototype of Minecraft out, he was pulling from a huge mental base of insight and experience.

Great games need great insight. Big-budget games need teams. Arguably, the development of any game creator's career requires progress into a team eventually. The many are more powerful than the few. There needs to be a way to communicate the mental magic that grand designers have with each other. Why did Miyamoto pump out 3 Golden Eggs, then iterate for 15 years? Have you heard of Romero since Doom (positively)? Dude makes flash games now. Why are the world's largest action franchises recycled mechanics and AI in exotic locations? Mechanically, Super Mario World is more complex than Uncharted. The creative direction of each have huge differences. Mechanically, the statement is true.

In reality, the design and the prototype of a game need to be constantly iterated in-tandem. Someone who writes a doc then produces a game, in two distinct steps, has iterated once. Iteration is king in game-making, so, regardless of the importance of a doc, the monolithic design is a bad strategy, if - and this important - and only if you want a new creative (i.e. original) direction for your project of some non-negligible degree.

[EdgeOfProphecy]

M'yes, quite.

/bubblepipe

[Graham.]

:D

[C.A. Sinner]

Games like Minecraft spent years bubbling in the minds of their creators. Notch prototyped hard. He friggin' released on version 0.01 or something. But, he thought about games, his games, other games, his "game" that he'd make when he had an opportunity, a lot. When he pumped the first prototype of Minecraft out, he was pulling from a huge mental base of insight and experience.

just curious, where do you draw the line between prototyping and iterative development (is there even one?). because to me prototyping has always meant making a rudimentary version of the game with like colored squares for graphics and then making the "real game" based on that. with minecraft the "real game" just seems to have gradually evolved out of the "prototype."

[Graham.]

There is no line.

Sometimes you make something with the idea that you'll probably throw it out. I don't do this. Maybe if you had to demo on a schedule you would have to do this, or if you found the actual experience of doing this rewarding in its own way - like with game jams - you would do this.

If I make something, it's because I think it's the beginning of something that will become a part of the end. If it's a "new" idea (totally subjective term), I call it a prototype. Then I iterate. I use the terms game and prototype interchangeably, depending on context I guess. It doesn't really matter.

The first implementation is a dot on the screen, then I go from there, nice and gradual.

[narasu]

I don't think he's paying much attention to this u guys

[Angrymatter]

Ya, I think EVERYBODY wants to be a game designer. NOBODY wants to be a programmer(as far as I know, people preffer to want to just BRAINSTORM and not actually make anything) and a few want to be good at art and sound etc.