This has been bugging me for a while now, and I'd really like to see the state of things out there. Now I know this kind of thing varies between workplace to workplace, so I'll make it more of a consensus rather than a full-on question: In your workplace as a game programmer, how much freedom (Or leniency if you will) do you get in the matter of altering or disputing the game design in the event that you may find it impractical to implement (Eg. Unsuitable for the target hardware, algorithm implementation too complex/time consuming, etc) or in the extreme case you just plain don't like the idea? Cheers PS: I bet this was already answered by Tom Sloper somewhere :P, but like I said this is more of a survey type thing rather than a straight on question. (Although if someone wants to point out the relevant chapter in Sloperama I would appreciate it.).

It's not your job to like or dislike and idea and act upon it. Obviously any good workplace will happily listen to any feedback you have; when design deems it reasonable they will act. But you are not there to design the game so if design wants something you just flat out don't agree with after hearing that feedback, tough cookies, it's your job to implement it anyway. That's why your title is Programmer and not Designer.

Obviously if it's impractical to implement then it's your duty to suggest alternatives that get you most of the way there at a much cheaper cost. Certainly some things are impossible on a target platform (for instance i was asked to do real-time fluid dynamics on a PS2 game because some designer head "it was cheap now"). At that point you say: "nope, that's impossible. But if you really want realistic looking water effects here are some combinations of shaders and particle systems that will work if we remove some other features from this part of the level".

Personally, in my workplace design is really open to feedback and suggestions. They will always listen and if your idea is good then it'll be incorporated. But certainly design always has the final say over design.

-me

In a commercial enviornment, expect to forgo alot of creative freedoms in favor of (questionble) job security and a weekly or biweekly paycheck. If you are looking to develop a game from the ground up, including design, thats what the independent game scene is for.

Programmers are not game designers and with that said, producers/designers always have the final say. With THAT said, at my work our games wouldn't be half as good if the programmers didn't invest a lot of time going back and forth with the design team to make features as streamlined and fun as possible.

The longer you've worked with the designers in question, and the more they respect you, the more influence you'll have over their designs, and the way the game evolves. I've worked with my current designers for a couple years now, so when they have a new idea they always come to me first to bounce ideas back and forth.

I've completely designed several aspects of the features I worked on in my current game (i.e. you'd approach the lead designers and say "I think it would be better if you had to do this", or "I think this is missing, and adding it would make it that much better".

Unless your designer has a huge ego, they'll most likely listen to your input. The best designers will take the time to tell you what they do and do not like and why. After all, you're implementing the feature. You know how it works better than anyone else, and designers don't always have time to test every subtle nuance of something.


After saying all that, the one thing that throws me from your question is the words "freedom" and "leniency". I think those represent something different than what I describe above. The collaboration over the design of something is always agreed upon by myself and the designers before I go off and build it, so in that sense, once we lock down what we're building, the freedom is gone. Both parties agreed on "Feature X does Y". That is what you need to deliver. I just don't think the word leniency applies here. Either they're lenient or not, but in order for people to be lenient you'd have to do something wrong. Don't do something wrong.

Is that at a game company Hodgman?

Ok, so there were two things that were nicely cleared up for me,

One, making games is a team effort, and therefore the programmers should play their role in the implementation and keep in close contact with the designers to solve any issues that may arise as soon as possible. When Tom mentioned "collaborative problem-solving spirit" that really opened my eyes to this view.

Another thing was the step by step process involved. In Hodgman's case the workers are cogs in a streamlined machine, and they must work sequantially on each part in the construction line. Due to my lack of exposure to programming in the business world (And over exposure to the independent scene :P ) I failed to grasp the idea that in a business environment things will likely have been planned and re-planned many times, and things have to be set in stone before a finger touches the keyboard (Ok maybe this is the case on extremely organized indie projects too, but to a lesser extent.). I'm also guessing larger companies would hire consultants to work alongside the designers to help them avoid any implementation issues, so when comes crunch time, the programmers already have their pre-digested work layed out for them.

Cheers

EDIT: Heh, I wonder if this is similar to the issue between civil engineers and architects?

[Edited by - BlindSide on July 10, 2008 1:26:02 PM]