Games are code, ergo, programmers design gameplay.

The programmer would have to show the designer who would decide if the feature/gameplay mechanic could make it into the game. Alternativly if a studio is large enough to have an R&D department he could show them and they could add it to the studios code base.
Or he could keep it under his hat and save it for when he starts his own breakaway studio and changes from programmer to designer and implements his game that he has had hiding away in his back pocket since he first entered the game industry.


If the programmer thinks up a new gameplay idea he doesn't just include it in the game thats not his job.

In the same way that because movies are filmed with cameras, only the cameramen are required to make a movie?

I think you're getting things a bit mixed up. Yes, because a programmer actually *implements* the gameplay, it's is certainly possible for a programmer to come up with good gameplay ideas. But what does it take to create good gameplay? Coding skills are not required. Look at board games, for example. How much coding was involved there? They just had some people who knew what made games work, and used that to come up with rules that made for a fun game.

The exact same applies for computer games. What matters is that the guy who comes up with the gameplay knows what makes for a good game, and what doesn't.

Taking another example, in any online game you can find lots and lots of people whining that the game would be oh so much better if only this or that restriction was removed (For example, I recently saw a guy say that Guild Wars would be vastly better if you weren't limited to 8 active skills at a time)

A game designer has to be one who doesn't fall into that trap. Taking the Guild Wars example, that exact limitation is what adds variety and dynamics to the game. You have to choose your skills in advance with care. And once in a battle, you have to make do with the few skills you chose, no matter what you're faced with. If that limitation was removed, a major part of the challenge and depth of the game would be gone.

You can always find people clamoring for bigger, better guns in FPS games too. Don't they realize that giving players a "kill all enemies" button *ruins* the game?

So the game designer has to be someone who understands this. He doesn't have to understand code. He can just tell the programmer "do this, do that". And if the programmer says "Can't do this", he'll have to think of something else, but he can do that, because he knows how games work.

So no, game design is a very different role from programming.

Of course there's overlap, and knowing both can only help. As you say, the programmer may be able to use his knowledge of the code to come up with new and better gameplay ideas. But that doesn't replace the need for *game design* knowledge. A programmer might well realize that "ooh, I can make this awesome mushroom cloud shader effect. We need a nuke so I can show it off", but it's a really bad idea to just include that in your game unless it also fits into the *game design*.

So basically, one person may be able to do both, yes, but they're still different tasks. A game designer is concerned with coming up with gameplay mechanics and dynamics that are not only "cool", but also give a balanced game with enough depth and variety to be fun. A programmer is not required to think about, or know about, or understand about these things. At a minimum, he just has to know how to code.

Quote:

After all, what is gameplay (use any sport you like as an example) if not a series of rules + cause and effect?

You could say that. But designing the game involves *choosing* those rules, and a programmer doesn't neccesarily understand how to do this. He knows how to enforce the rules in the game, but nothing in his education teaches him how to come up with the right rules.

The big flaw in your argument is the idea that "because games are code, those that write the code must be best qualified to do everything about the game".
The end result of any game may be binary data (code as well as all data resources), but it still takes quite a few *different* skill sets to produce it.
In the same way that anything you see on your TV is "just pixels", but that doesn't mean someone working in MS Paint is all you need to make a TV show.

Let's say your programmer designed a script-parser, that allows the artists to define all the game-specific behaviour. Which, to some degree, is quite common. Would that mean that the artists design the gameplay, and they alone?

The programmer, or the artist, or anyone else may implement the rules, but that doesn't mean they designed them in the first place. It doesn't mean he understands all the effects of those rules either. And while I agree that those people certainly influence the final game, and that everyone can come up with interesting idea's, whether or not they realize it, that doesn't mean that you should let your programmer design your game, if he lacks the deeper insight into what 'works', gameplay-wise.

See, there's a difference between designing something and implementing it. If you've been around in some modding or mapping communities, you'll be amazed at the influence that level-designers have. Some levels are terrible, absolutely boring, while others are amazing, good fun. While the underlying technology, the resources, the AI, and what not, didn't even change. And this goes further than the difference in fun: some levels contain whole new gameplay idea's, which is possible as long as the game is sufficiently data-driven.

Almost all my favourite designers are or were programmers: Richard Garriot, Sid Meier, Peter Molyneux, Will Wright, etc.

Games are simulations of mathematical models. The gameplay stems from the interactions with the model and the definition of said model. These are the two key factors that differentiate one game from another.

The designer designs the model and its interface.

The programmer takes that design and translates it into a form the computer can understand.

The artists create the data the model processes.

That really is all there is to it. Sorry, but it's just not that hard or complicated. The reason we hear so many horror stories is because good _management_ is hard.

Look I could make a big fuss on this but I am not. But lets make something clear.

Designers and programmers are extremely different. Though you find people who blend the jobs due to industry conditions. Especially in very small or starting game houses.

Game designer: Focus on fun factor, entertainment, and enjoyable game play for the player no matter what the story or setting happens to be.


Programmers: Make the ideas of the designers work. They play a role in the design in certain circumstances.

I am not saying you don't have one with out the other in many circumstances. But to say you must be a programmer to be a designer is an ignorant statement. I am not calling you stupid. I am saying that you need to do more research.

The thing is, major studios produce their games in a very extensive fashion. Everything is decided upon ahead of time, all the classes that will be needed and all the different aspects of the gameplay mechanics. Then programmers are given the task of coding these individual pieces. It isn't exploratory programming where they are trying things out and tinkering with the system. They're coding something from a design document.

That's why a game designer should be very intimate with the programming, since he/she will have to know all the little details of implementation (this is also why when people come to this site saying "i don't know how to program, but my ideas are so great!" they get ridiculed.) Faded Phoenix, I think you should do some research yourself.

Quote:

Original post by asdzxc... I find it very difficult to accept the notion that specialised "game designers” would be better at designing gameplay than programmers, in general. After all, what is gameplay (use any sport you like as an example) if not a series of rules + cause and effect?

In the example you site, I must say: Building an entire game mechanic around bounding boxes leaves a little something to be desired. I dunno -- I'd have t'see it before I passed full judgment.

In my experience, some of the most entertaining games I've played are the ones where the designer and programmer are the same person. This is not because he was a programmer but because the design was simple and it afforded the programmer opportunities to have fun and add bits of style and moxie to the gameplay experience.

The problem isn't usually because the designer is a separate entity from the programmers but because the designer is basing his designs on market research and statistics -- never once asking himself the question: Is this gameplay something I would enjoy playing?

There are too many programmers who get caught up in the "look what I can do!" phase of their game design. . . they end up sporting a big variety of technical know-how but very little in the way of actual, meaningful gameplay elements.

It really doesn't matter _who_ designs the game --- as long as they're good at game design. Like you said, too many people assume that story or just plain features is gameplay. It's not. It takes a lucid perspective of what you're doing -- constant introspective criticism, and reckless abandonment of life away from the keyboard (unless you're insanely lucky and can afford to do it for a day job -- HAH!).

Quote:

Original post by Funkymunky The thing is, major studios produce their games in a very extensive fashion. Everything is decided upon ahead of time, all the classes that will be needed and all the different aspects of the gameplay mechanics. Then programmers are given the task of coding these individual pieces. It isn't exploratory programming where they are trying things out and tinkering with the system. They're coding something from a design document. That's why a game designer should be very intimate with the programming, since he/she will have to know all the little details of implementation (this is also why when people come to this site saying "i don't know how to program, but my ideas are so great!" they get ridiculed.) Faded Phoenix, I think you should do some research yourself.

You're talking about software architecture. This isn't the same thing as game design. You cannot design the software's architecture without first understanding what the game's going to be. The process breaks down as follows:


1. Game Design Specification.

- This does NOT specify code, but might specify specific algorithms if these are key to the gameplay.)


2. Systems Analysis.

- This is where the Lead Programmer(s) sit down with the Game Design Spec. and work out how best to turn it into a piece of software.


3. Software Architecture.

- This is the nuts and bolts process of identifying _exactly_ what software components are needed, how they need to be bolted together, in which order, by whom and in what timescale. It's the bit where you sit down and start naming object classes and nailing down middleware choices.

- Since games are media-heavy, this stage is ALSO the point when you start defining (or modifying, if this isn't your first development cycle) your workflow, defining the assets you'll need -- graphics, audio, tools, etc. -- and so on.

- Testing procedures are refined at this stage and a testing regimen is arrived at.

- Project Management is also a key element here: it's at this stage you start to find elements of the original Design Spec. which aren't going to be doable by the release date. It's also the point when your Project Manager gets his first draft project diagram into MS Project.

- So it's not JUST about the programming.


4. Development.

- The point when programmers, artists, musicians, audio engineers, etc. actually sit down at their workstations and start cranking out code and data, bickering with producers over milestones, keeping the managers from interfering with the original spec on behalf of the marketing and PR folks, etc. Basically, this is the "fun" part (if you're a manager), or "The Marriage Killer" if you're a front-line, coal-face developer and your manager sucks at his job.

- Testing also takes place in tandem with development. (At least it should be.)



Those are the key production phases.

Quote:

Original post by Kylotan Almost all my favourite designers are or were programmers: Richard Garriot, Sid Meier, Peter Molyneux, Will Wright, etc.

I'd guess they were programmers/designers, having that rare balance of brain function that combines both the left and right hemispheres. I'd like to think that I'm one of those, though I can't compete in sales with those legends of game design.

Carpenter != Architect

Quote:

Now, the base of my belief lies in the simple fact that games are made from code. Because of this, as a programmer reviews his own code and improves his technique, a new gameplay idea may hit him like an epiphany in a totally organic way. I’m sure most programmers have experienced that tingling feeling. The actual code itself, and the act of programming, begets ideas and makes them possible.

A brickies labourer puts the bricks together to make a house. Therefore the brickies labourer should design buildings.

I don't think many people would agree with that.

Continuing the building analogy: Modern Programs (like games) are towering skyscrapers. Would you trust the guy pouring the cement to design it? Years ago (in thee olde DOS days), games were much simpler. They were more like the back shed. And most people who knew how to slap together some code (like people can slap together a bunch of bricks and mortar to build the shed), could put a game together. Modern games are much more advanced than that, so we need someone who knows how all these complex things fit together to make the game. Knowing how to build a shed in not like knowing how to build a skyscraper.

a new gameplay idea may hit him like an epiphany in a totally organic way.

...snip...

Quote:

For example, the programmer implements an invisible bounding sphere around the player which keeps track of all entities and events within its radius. Just from this one concept, a multitude of new gameplay features become possible, and they are all realized from the moment the code is typed - this is the mind of the programmer.

And thus is feature creep born.

If you had 20 programmers working on a game and each was working like this, how long would it take until the entire code base was a complete mess?

Games do not get designed by pandemonium. They need to be structures in their development.

Quote:

Almost all my favourite designers are or were programmers: Richard Garriot, Sid Meier, Peter Molyneux, Will Wright, etc.

But how many programmers are not game designers and how many game designers are not programmers?

This is a small minority. Yes they are the big names, so knowing how to program is most likely an advantage to a game designer, but even these guys know the difference between game design and programming. I am sure that none of them would consider the "organic" approach of a lone programmer coming up with a "cool" idea or a new algorithm and then just plugging that into the game.

That kind of approach might have worked on the small games with just the one or teo programmers, but if you add more programmers into the mix, that approach becomes unmanageable and you end up with something that is a complete wreck.

Allright guys, I think some of you have broken rule 2 of this discussion here, I’m not really trying to say WHO should be designing gameplay, but rather considering the creative process itself.

Its probably true to say that nearly every original genre of computer game was created by a programmer, and that they came upon these ideas while experimenting, without a clear goal in mind. This comes back to the “games are code” concept - with the right mix of features and technology + a little inspiration, a new game idea practically asks itself to be made.

Consider something as basic (and original) as Asteroids, did the programmer wake up one morning with a crystal clear image in mind of what he wanted to create? Did he painstakingly plan it before hand? I think its far more likely he was just mucking around, implementing new concepts (like gravity) and scrapping crappy ones, in much the same way a musician might create a kickass track just by fooling around - but that’s not to say he didn’t have a “rough” idea of what he wanted in the first place.

I suppose when you put it that way you do have a point it is the programmersin some situations that would come up with a new way of doing things. I suppose when you look at Doom befor it was released there weren't a whole lot of games using BSP trees to render fast 3d envioronments.
However in a lot of cases once a programmer comes up with these concepts and design a game around them they cease to be a programmer and become a designer.
Peter Molyneux already mentioned in this thread no longer programs games.

Quote:

Original post by asdzxc Its probably true to say that nearly every original genre of computer game was created by a programmer, and that they came upon these ideas while experimenting, without a clear goal in mind. This comes back to the “games are code” concept - with the right mix of features and technology + a little inspiration, a new game idea practically asks itself to be made.

Not really. I would say that every original genre of computer game was either created by a designer, or was originally a genre which existed outside of computers. The question of which side most genres are on comes down to the granularity of your definition of genre.

And of course your statement is much weaker than your original one; most game design, no matter who is doing it, is not a matter of creating an original genre.

Quote:

Its probably true to say that nearly every original genre of computer game was created by a programmer,

In a way, this is true. Most original computer games were made when there weren't many computer games already made. So, this would have been when computer games were small and could be made by a team of 1 or 2 people. Most likely, in a team of 1 or 2 people, the people would have both been programmers, and as the industry was getting started, there would not have been many (if at all) people in the computer game industry that was a computer game designer (as these were the first people to actually make computer games).

So given that, most original computer games would have been made by programmers because there were no designers (or very few designers) out there and the games themselves were small.

In the absence of "Designers" then it would be people that were familiar with the medium (programmers should be familiar with computers :D ) will be the ones that can make the biggest contribution to originality.

Infact, back in the old DOS days, many of the Artists were programmers to, they created unique and interesting characters, so does this mean that we should replace artists with programmers?

This is where your argument fails. Just because a game was unique, doesn't mean that it was necessarily a "pure" programmer that came up with that idea. That programmer must have had some design skills or they would not have been able to design it. And, when you look at the situation in the past, there weren't meant designers because the industry was still young. This meant that someone else had to be the "designer" and the ones most familiar with what could be done in the medium (computers) were the programmers.

Looking back to my Bricklayer/Architect analogy: If a brick layer had the design knowledge to design and build his own house, should he therefore be allowed to build and design the local shopping mall?

He might, but to do so he is using a completely different skill set to that of a builder. If he (or she) has those architectural skills (and being a builder does not mean you can't have the architectural skills) then there is no problem.

As a designer, I welcome the opinions of programmers, artists, musicians, etc. But these people may not have the design skills needed to evaluate an idea as being good or not. They might know if an idea is a "Cool" idea, but is that idea good for gameplay?

Quote:

Original post by erissian Carpenter != Architect

This is exactly the analogy that sprung to my mind instantly.

Both individuals are tackling the same problem, but from different ends. In many ways, the architect works from the outside-in while the carpenter works from the inside-out. Its the classic top-down vs. bottom-up scenario.

The fact of the matter is that neither individual can complete their job without the other (unless they take on both roles.) Without the architect, the carpenter has no direction, only tools and raw materials. If he's experienced, he may be able to put something together that is a functional building, but its likely that it won't have any style, flow or character. Without the carpenter, the architect has no idea how to actually assemble the building. He might be able to put something together that looks like a building, probably even a nice building, but its likely to fall apart in a stiff wind.

The best designs are organic, even in construction (which is a far less dynamic process than software) it would not be all that uncommon for a carpenter (or other contractor) to work with the Architect on the design or for either individual to suggest minor changes (ie non-structural) during the building process. Software is even more fluid.


So, can a coder influence gameplay by providing a basis for new mechanisms? Certainly. But without a designer to realize the fun, new possiblities that are opened up its worthless. Just because it's possible doesn't make it so, and even if it's so, doesn't make it fun. Likewise, a designer's ideas are worthless without an implimentation that holds up to his ideal. Just because it's fun, doesn't make it so, and even if it's so, doesn't make it possible.

Quote:

Original post by ID Merlin Quote: Original post by Kylotan Almost all my favourite designers are or were programmers: Richard Garriot, Sid Meier, Peter Molyneux, Will Wright, etc. I'd guess they were programmers/designers, having that rare balance of brain function that combines both the left and right hemispheres.

I don't think it's rare at all. I'll name some more: Julian Gollup, Raph Koster, Chris Crawford, Chris Taylor, Brian Reynolds.

I just think there are a lot of fluffy art types who seem to view anything remotely technical or mathematical as anathema to their free-flowing creative mind. If I may be controversial for a second, I think that designers who can't program often try and suggest that programmers are poor designers to cover up for their failure to grasp technical skills.

Quote:

Original post by Edtharan But how many programmers are not game designers and how many game designers are not programmers? This is a small minority.

A small minority of designers, perhaps. Yet possibly it's a majority of the designers that actually make good games, again and again, rather than of those who continually churn out unworkable ideas that don't suit the medium or which are not practical to implement.

It's true that a lot of the designers I respect began their careers as programmers. However I find it interesting that my favourite console game designer, Shigeru Miyamoto, started as an artist.

I think that with a programming frame of mind, it is easier to break down a game concept into a series of rules that (hopefully) seemlessly fit together to make a cohesive game. The danger if you are too immersed in the mathematical world of programming is you will end up with a technically perfect yet dry and uninteresting game design (for example, in my opinion Quake suffered from this).

If you approach game design from the artistic frame of mind, then it is easier to visualise the game, live it, breathe it and see exactly what it should feel like. The big danger is that your vision is totally infeasible from a technical perspective, which could lead to the situation of an unworkable game design.

From my observations both approaches can work, although you have to be wary of the downsides. Getting some balance by looking at a design through both perspectives (either by yourself or with a colleage with the complimentary skill) is best all round, in my opinion.