• Advertisement
Sign in to follow this  

Programmer Design Freedom in your workplace

This topic is 3480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.).

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by BlindSide
I bet this was already answered by Tom Sloper somewhere

Nope. (^_^)
If you're having a problem getting a feature to work, you should bring it up at the earliest possible regular team meeting. The appropriate team members need to put their heads together and figure out how to solve the problem.
If you're thinking this is a "creative freedom" issue, you do not have the proper collaborative problem-solving spirit to work in games.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Where I work, they are serious about spec's, and well-defined roles (at least in the game-dev areas; the engine-dev areas are frightfully devoid of spec's!).

In one of the studios, software isn't even allowed to look at a spec unless it has been double-checked, peer-reviewed, proof-read, submitted to administration and uploaded to the project management software.

May God have mercy if a software engineer thinks a spec should be changed...

[Edited by - Hodgman on July 10, 2008 5:58:10 AM]

Share this post


Link to post
Share on other sites
Gaming, yeah. Not PC or console though... think arcade....

The last PC/console company that I worked for was much better - as a coder there I was even invited to have input into the design of features that I would be implementing.

[Edited by - Hodgman on July 10, 2008 6:18:46 AM]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
This is tricky in some ways. Not everywhere has a pool of good designers with a dependable design review process that will correctly weed out poor designs.

If you've got a problem with a design from an actual design point of view then, where I am currently, we'd simply get up and discuss it with the designer in responsible. Not in a "this is rubbish I think it should be like XYZ" way, nevermind how it may sometimes be very tempting, but identify why something is a problem and what you think might work better in that case.

Eventually you might just have to implement a complete bag-of-shit for a design, I have, several times. I've done that all to the best standard that I could too, but that's my job. I might have personal reservations about a feature but I am actually paid to implement what they designed and project management has approved so it has to be done and always to as high a standard as you can.

If there are other problems with a design, anything from it lacking in... well much of a design at all such as an incomplete spec (I've received a picture drawn in MSPaint as a spec'... I am not joking, this has happened several times.), or the feature is simply technically impossible then we're usually told to email the designer and their lead whilst cc'ing our own lead so that people can see how it's going to impact on the schedule to get things fixed/altered and upto standard before work starts!

Not sure that actually clarified anything... ah well :)

Andy

Share this post


Link to post
Share on other sites
I get quite alot of say on design, and it works very well. Our designers will have a plan, but half the time when your writing something you find better ways of doing things, or making things behave and it becomes a team thing. I've been forced to impliment features I thought were completely stupid, but on the flip side I've veto'd my share of things the designers thought would be "soooo cool" but which really were quite bad and not worth even trying.

But it also comes down to a personality thing. I work with quite a few programmers who will blindly impliment exactly what the designers write no matter what, then there are those like myself who will take the designers plans as a guide and write something thats good. My moto is "give them what they want, not what they asked for". Our designers aren't precious about their idea's, they'll come talk to the coders and artists and love playing work in progress builds and giving feedback. I'd hate to work for a company where design was law - I have too many of my own oppinions for that kind of enviroment!

Share this post


Link to post
Share on other sites
Your experiences are going to vary greatly per company. Some companies have fairly rigid policies (and rigid designers and producers), but many don't in the games industry. As a Designer I always have open ears to what everyone on the team has to say, because I'm concerned with making the best game we can within the time and money constraints that we have. Some designers feel their word is mandate though, and I have a strong desire to punch everyone of them in the face.

Share this post


Link to post
Share on other sites
Quote:
Original post by BlindSide
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.
Just for the record: This construction-line development process that we're using is bad. Bad and wrong. Badong.
We used to do things iteratively, but then upper management decided that iterations are just waste/error and should be eliminated, so now we're just demoralised cogs...

Share this post


Link to post
Share on other sites
Quote:
Original post by BlindSide
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.


I'd be careful generalizing here. In my case (which I describe above), I work for one of the largest and well known game companies in the world, and my team (at least this year) has been afforded the freedom to go back and iterate on everything until we were happy enough. Things are different from company to company, from studio to studio, even from team to team. Hell, even year to year can be vastly different depending on who you're working with. Rigid schedules don't work most of the time. Ideas that seem good often turn out to be stinkers, and if you don't allow yourself to have breathing room to iterate and investigate during production your game will suck (or just seem much too shallow due to cutting features). Having a loose schedule doesn't necessarily mean you can't have very well defined job roles. Sometimes programmers could care less about having any input into the design of something (I'm not refering to the design or architecture of the code itself). This would simply have one side (designers) driving all the work for the programmers (more like an assembly line, but not necessarily in the same way as in the next paragraph).

Personally I feel that assembly line type models are way too process-heavy and stifle creativity. It's like a 600 pound gorilla. Once the gears start going, it's hard to course correct.

I've worked on teams at both end of the spectrum (all for the same company). I actually really feel that managers who lean away from an assembly line model have to spend less time micro managing schedules to make sure no one is left hanging for too long, and they can instead work on more important areas of their job.

Share this post


Link to post
Share on other sites
This sounds common from the other replies, but I'll chime in too.

The most productive teams I've been on are those where the designers have a good fun design up front. They have discussed the game with many people, including the programmers and artists. They have gathered all the input they can to help build a fun game. All the programmers and artists should have some buy-in at this point. Everybody should contribute to the design, commenting about what they think is good, what they think is bad, what they think is difficult and what is easy, and so on. You may not agree that a feature is good, but you should have been able to discuss your thoughts freely during pre-production.

Programmers and artists are generally given a lot of latitude on the actual implementation. We're told to make an object behave in a general way. The job of artists, animators, programmers, sound engineers, and everybody else is to take those fun ideas and implement them in a fun way that fits the game. Often there isn't much variation available -- for example, code for blending animations doesn't require a ton of creativity. Other times there is a great deal of free reign, such as implementing portions of the AI, or the mechanics of how objects interact with each other.

As was mentioned, when anybody sees something that looks like it will add fun to the project they should immediately bring it up for discussion. The exact chain of command varies by team size, but generally it is easy to fire off an email to the development director and to the designers asking them "Have you considered this idea? I think it would be great." Include with the suggestion an estimate of the amount of work/cost involved, and the risks as you see them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement