Hey all! Now I hope the thread title didn't come off too offensively, but it genuinely illstrates the point of this thread. I wonder about the relationship between game programmer and game designer. I consider myself to be both a competent designer and programmer, however, on the game design forum, I often see ideas that I consider to be way out of touch with what is actually plausible/worthwhile implementing into a real game that isn't planned for 1,000 years into the future when we program games by thinking them up! Now this isnt to critique those few posts that I think match these criteria, there are plenty of amazingly good posts as well or I wouldn't be here! It does however, raise an interesting question. What are your thoughts on the designer/programmer relationship? I personally like to sit on the fence in the middle, some designers, especially those with little experience, expect programmers to be able to perform miracles. I do see the other side of the story though as the programmer who refuses to consider a new radical idea may be the programmer that falls behind with technology. So what would you consider to make a healthy balance in this relationship. Would you place any importance on one or other side? How do you decide what is plausible and what is a waste of time, and what qualifies as something worth implementing in a game to you? Some ideas that I hear time and time again sound really poor to me. Now I don't know if this is down to experience and knowing what is good and what isn't, or perhaps my perception is wrong, and I'm unable to see the potential in some ideas? Anyway, I hope I've not come across too negative, but just thought this might make for interesting conversation! Also... happy Christmas everyone! Cheers Steve

I’ll tell you how things work were I am. They’re the programmers, designers and the producer. The designer writes a design doc that specifies what the game should have in it. The programmer gives an estimate to how long it will take and how risky it is to implement. The producer is the one to sit down with the time table and make the cuts; we have one year, the AI programmer has 500 days worth of work from the current design document = chop, chop, chop.

How can the programmers estimate how long it will take? If you can’t use experience as a guide you might need to prototype it. Actually prototyping is always a good start; who knows is this cool new idea is any fun at all?

What qualifies a feature? You always have some constrains that you try to keep within. Constraints can be of many forms; time/manpower/cost, ESRB rating, genre, fun/gameplay, target hardware and so on. Once you know what you’re higher goals/constraints are you can derive from those to make decisions on a specific feature.

It's true I consider myself a designer, not a programmer. Not by any definition of the word. But this is why I'm going to college: to learn how to program. In the meantime, since none of my programmer friends can do anything TOO complicated, I decided to keep things relatively simple though refreshingly challenging. Nothing anyone will get stressed over, but at least it'll make the game worthy of being played. That's all that really matters you know. It's not how well you can create a 100+ hour long open ended MMOFPSRPG in a month with no experience at all. Put that design aside. You can't do it. The idea of this biz is not to stress out but to entertain. I mean look at Bejeweled. As long as you know how to play around in Photoshop and you can / have a friend who can program, you're in decent shape to make a fun game, as long as you put your heart into it.

True, dedication and passion for your work, no matter how big or small it is, is extremely important. But on a more topic related note...

I think the best way to do such large projects is if the Designer meets the programmer halfway. What i mean by this is that the designer explains HOW his wonderful life-ending idea's work, what key's they'll use, what possible responses and outcomes will there be? How do the econimics work? What classes/health/abilities does the player get and what can the player do? etc. He doesn't have to program, but he should at least have a limited understanding of code to structure it properly. All to often you see documents that list off really great idea's and content, but don't give any idea whatsoever as to how it's actually going to work ingame, or what the variable limitations are. This usually really puts off programmers because they'd be going in blind and basically doing all the work, including portions of design.

The programmer should also meet the Designer halfway. Rather than simply dismissing idea's from a designer as flights of fancy, the Programmer should take the idea's from the designer and offers possible solutions or ways of implementing it that he can come up with. If he's not able to do it, then its either time to start redesigning, or looking for extra help. More often then not though programmers are reluctant (and i can understand why), to get involved in projects that aren't very well organized or show any realistic goals that will actually go anywhere.

i'd like to point out something i've seen a lot here:

if your design includes the phrase "this game will barely run in current hardware" then you seriously need to reconsider how you believe games are made.

A game isn't good because it consumes hardware (i can do that in 2 lines!).

edit: a sad fact

if you go "this game is going to be like no other"
you're very possibly wrong, and if you were right you would be turning off most of your customers anyway.
Thats right. 100% originality turns most people off =/ because people need something to relate to, else it is too much effort to learn to play your game.
So, anchor the game on some things that people can relate to (doesn't even have to be other computer games!)

[Edited by - Madster on December 27, 2004 7:35:30 PM]

A designer's gotta be able to work with the programmers. That's obvious; without that, games won't get made. That said...

It is not the responsibility of the designer to know what is and is not possible. It is not the responsibility of the designer to know how a system could be implemented, or to provide suggestions as such. Those are the responsibilities of the programming team. What the designer must be able to do is to provide the programming team with all the details they ask for, and they must accept it when the programming team tells them something isn't possible.

Ideally, designers would overreach, every time, because it would push the programmers to try out those new ideas they've got about how to do something (instead of always going with the tried-and-true, and thus never advancing the state of game technology). But when the designer has the first meeting with his programming team and goes through the design doc with them, he needs to take anything that they say along the lines of "That can't be done" at face value and adjust his design accordingly. If it's going to take the coding team a couple of weeks of research to find out whether or not certain things are possible, the producer will just have to deal with that. But the project cannot begin until both (a) the designer is happy with his design and (b) the coding team are happy that it's technically feasable.