• Advertisement

Archived

This topic is now archived and is closed to further replies.

managing a game design team

This topic is 6050 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

So say you have a handful of people who want to make a game. Who gets to make the design decisions? Why? When should design desicions be negotiable and when should they be final and not up for discussion? How do you prevent differences of design philosophy from fracturing your team? What design decisions should be made before a team is recruited?

Share this post


Link to post
Share on other sites
Advertisement
Really depends on how well communication is between team members. In an office environment I can see everyone contributing being a good thing but I'm convinced there should always be one unquestionable 'Lead' Designer.
In an online environment where people communicate through chat and emails a leader is needed to keep things straight and make sure people don't go off making something based on their vision which conflicts with yours. But again, good communication solves these problems. And don't get me wrong, team member input can be extremely valuable somtimes so they shouldn't be ignored or not encouraged to speak up.

I really don't have any GOOD experience but I started a project thinking I was the leader and now months later a lot has changed, maybe for the worse. Varying opinions and lack of daily communication resulted in a bunch of people making pieces of slightly different puzzles. They still fit together but just have to be forced a bit..should be interesting to see how it turns out.

Live and learn though, eh? I hope my next project will be more efficient with every team member knowing exactly how I plan to do things, right from the start.



Edited by - mumboi on July 16, 2001 12:29:36 AM

Share this post


Link to post
Share on other sites
I think you just have to have someone clearly and unambiguously in charge. If you then have too many people underneath the leader, it makes sense to divide those people up by their area of expertise and appoint a leader for each section. Sometimes you just have to pick a decision and go with it, rather than forever discussing what will be best, as the best unimplemented design means nothing, whereas the 2nd best design in an implemented form means everything. These decisions, once taken, should only be considered for negotiation once new evidence has come to light. Otherwise, people will just keep insisting on their old views and no-one gets anywhere. And recruiting people to the team should be subject to them agreeing to this 'chain-of-command'. Ideally, you get all your design done before you recruit anyone, so everyone knows exactly what they are here to do and can't really argue, but that's an ideal situation that you're rarely going to find

Edited by - Kylotan on July 17, 2001 9:14:32 AM

Share this post


Link to post
Share on other sites
I would also suggest in term of selecting a lead designer that the following personal qualities get discussed:

a lead should be detail oriented,

a lead should be POSITIVE, knowing what you CAN do and not shooting down everything that CAN'T be done. That person should be your lead engineer.

a lead should be someone who does not take bullshit from the people they must drive; the lead is usually the project manager (boo hiss 3ViL!!) in most small groups, so they have to be able to take the abuse as well as dish out the deadlines, and not take it personally.

a lead must know how to hold their own in a conversation such that the publishers don't break it off in the team's collective anus.

a lead must at least TRY to know when NOT to be any of the above.

a lead must know they are fallible, and not abuse their power or cause it to foreshorten the Vision to the Goal.

------------
-WarMage
...Always remember that you should work WITH people, not FOR them, whenever possible. This is just good workplace mechanics.

Edited by - WarMage on July 17, 2001 1:41:36 PM

Share this post


Link to post
Share on other sites
Some personal experience.

In a team of 8 (1 gd, 1 writer, 2 artists, 4 coders) everybody wants to be the game designer and to give bright ideas, which, of course, have nothing to do with the brilliant things the others from the team have come up with. And there comes the debate, then not-so-calm argument, then a fight.

We''re arguing over basic design concepts for 6 months now. I cannot imagine what it''s gonna be when we come to details.

If I was paying those guys (which are my friends, really), I would be empowered to command them in certain ways. But I''m not, so what I''m supposed to do? I cannot afford not to listen to a opinion, cuz that way I insult the member of the team.

Maybe I''m doing something wrong, or we just cannot work as a team, I dunno, but this is it.

Boby Dimitrov
boby@shararagames.com
Sharara Games Team

Share this post


Link to post
Share on other sites
Everyone has good ideas, and that is the problem! My good ideas will create a game that is not the game you envisioned. You need a visionary! The game designer has to continually work to keep their vision intact. And guess what? That isn''t very democratic - one person is trying to "give birth" to a vision in their head.

Ideally, it would be great to let each "friend" have a turn at being the game designer for a project. But that never seems to be easily accomplished - too much work and too much time for everyone to get their turn.

Read "Game Architecture and Design" if you haven''t...

Dash Zero
Credits: Fast Attack - Software Sorcery - Published by Sierra 1996

Share this post


Link to post
Share on other sites
Bobby, I think it''s probably best to focus on two things:

1) The Goal.
Like MKV said, the most elegant answer left unimplemented is no better than the crappiest system actually coded. Tell your boys if they think something is going to be super sweet, they need to be able to articulate how it fits in with The Goal. They need to sell YOU (or the lead, or whatever) on why This Is L33t. Obviously you don''t want to discourage their creative thinking even if it strays outside of their specific sphere of influence or expertise, but you can''t spend your entire life arguing about using Red missiles instead of Green missles because the fluorescing rate of red phosphors is slower and therefore you get "free" streaking missle trails. Nothing ever finished done unless you start!

2) Make Decisions and Document Them.
Put something down on paper when you get the general idea right. As you said, you are still arseing about dealing with generalities, when in fact I think you''ll find you BEGAN talking about generalities, and things went along smoothly until the details started creeping into the discussion. Make the decision to Stop Talking and Start Coding. Get as tight a framework in your DD as you can, then publish it to your guys. You''re going to find (if you haven''t already) that once they start working, the details become richer because you''re Making Progress, which makes everyone feel good, like They Count, and gives you a little more leverage to pin down your DD more and more.

This is stuff I''ve learned after 2 years of being 3rd Party support and interfacing with hundreds of other programmers and hearing about what they like and dislike about their environments. Most technical people cannot handle ambiguity. That''s fine, just tell them you''ll resolve their ambiguity, but they''ll have to get over it if the resolution changes halfway through the job. These are everyday hazards and it is part of life, but again, you can sit there thinking all day about the best way to write a particle engine, but if you don''t have a deadline you''re never going to start one.

-----------------------
-WarMage
...cos If ya kill the people then they''ll all be dead, and there won''t be any murderrrs!

Share this post


Link to post
Share on other sites
hey sunandshadow! Here are my opinions:

- First, as DashZero pointed out, read "Game Architecture and Design" that book is like my bible. I love it.

- Second, check out my four part article series "You Got Game!". There are some areas (especially the third part) that will help you out for team management and such - click here for the article.

- Finally, just some general advice. First is that all team members will have to learn to respect the game designer. It''s his or her baby they''re creating, and as such he/she dictates what features go out and stay in (barring majority vote). So long as the designer came up with the entire game and document, s/he should be the one behind it. If not, then team members should only be allowed to add input on areas they originally designed.

oh and make sure you have a design document... please! It''ll save yuo so much trouble because instead of arguing over whether this feature is correct or not, you can just chekc the doc and the argument will be instantly settled one way or another.

Best of luck!!

==============================
"Need more eeenput..."
- #5, "Short Circuit"
==============================

Share this post


Link to post
Share on other sites
Two words: Democratic Dictatorship .

By this I mean a sort of benevolent "seat of all power" figure - the game designer/project lead, as appropriate. I''ll stick with Project Lead.

The lead establishes the hierarchy of command - who is over what sections. In most amateur/indie gamedev groups that I hear of, there are usually less than 10 members - almost certainly fewer than 20. A detailed, multi-level structure may therefore not be necessary. The lead needs to make every member feel valued and heard; one way to do this is to have regular meetings during which the objective for the next period is discussed, and progress is reviewed. Everybody may be free to criticique everybody else''s work (hopefully there''ll be no "spite criticisms"). Opinions are collated and transformed into directives/further objectives by the project lead, whom everyone must agree takes the final decision.

You may optionally choose to allow team members vote for the lead, after a sufficient "getting-to-know-you" period.

This really boils down to management, and techies have historically been poor managers (and vice versa). This is changing, as both sides are realizing the communication divide and managers are taking technology courses while techs go get MBAs (which open up other, more lucrative job options).

Both of my parents have long been in various authority positions where there is much defined bureaucracy (the university system). I''ve benefitted from discussing events and strategies with them, and have come to realize that management is a critical skill, most of which is ego massaging and the rest of which is resource allocation.

Oops! Gotta run. I''ll check back later.

Share this post


Link to post
Share on other sites
Ok, here''s how it is - I want to be the lead game designer, but I don''t know enough about the programming half of making the game to feel capable of overseeing that. Also, I want to include my team''s ideas in the game design - it''s only fair, and my projects always turn out better when I have more people''s input than just mine. I think the process of idea exchange and cross-polination is half the fun of doing game design. Do you think it would work if I told my team that everyone was free to come up with wild ideas for a month, but at the end of the month I would make a final decision about all suggestions and we would implement them as I chose?

Share this post


Link to post
Share on other sites
booya! you go, s&s!

That sounds likea bonzer idea! After the month is up and all napkins have been tallied, spend some time as the group on each topic. Not only does that solidify your cross-pollination and team integrity, but it also allows everyone the satisfaction of knowing that Everything Was Discussed. After that it is just like you would read in a better PostMortem, where the team basically gets together on Friday, has lunch together talking about work, and letting it trickle into an open forum. This should be your Official Time for Feature Creep, and later, becomes your office-wide playtesting time, mmmmmm....

--------------------
-WarMage
...chinese fooooooood, may I take your order?

and theeeen?


and theeeen?


and theeeen?

--------

Share this post


Link to post
Share on other sites
Our project leader doesn''t know much about programming either. (non game project) But he does know what our customers want/need and consistantly has good ideas how to bring them to light. I think, for a lead designer, knowning a bit about programming is better than knowing a lot or nothing at all. That way you understand the need for logical steps, but can still let your imagination run free. It''s just a matter of counting your coders to give you some feedback.

If there''s already a leader, the best way to take the position for yourself is to make the decisions that they can''t / won''t make themselves. If you''re right more often than not the developers will prefer to come to you.

As far as discussing decisions, the only things that really say when they''re not up for discussion is when time or money becomes an issue. If there''s money involved, the person whose name is on the cheque pretty much always gets final say unless there''s more time to try to pursuade them to your side.

Share this post


Link to post
Share on other sites
quote:
Original post by sunandshadow
Ok, here''s how it is - I want to be the lead game designer, but I don''t know enough about the programming half of making the game to feel capable of overseeing that. Also, I want to include my team''s ideas in the game design - it''s only fair, and my projects always turn out better when I have more people''s input than just mine. I think the process of idea exchange and cross-polination is half the fun of doing game design. Do you think it would work if I told my team that everyone was free to come up with wild ideas for a month, but at the end of the month I would make a final decision about all suggestions and we would implement them as I chose?


You dont need to be a programmer to be a designer. Thats why you have a lead programmer. You dont need to define a free-for-all period followed by a total lockdown either. You just need to establish early on what the various positions entail. Actually write down in a doc what the Lead Designer, Lead Programmer, Junior Designers are responsible for, and who reports to who. Make sure that you place the role of the Lead Designer as the person in charge of the vision of the game, the person that has the authority to put a new feature into the game.

In a perfect world this would be enough. In reality though, you also need a lot of diplomacy skills. The "idea locakdown" concept isnt so great, because not all of your design issues are going to be resolved in a month (things always crop up that you didnt think of), and you will want everyones opinion. It can also breed negativity in the long run. You need diplomacy because you want an open environment where people feel free to voice their opinions, but dont feel negatively towards you when you decide not to incorporate their idea. Lets face it, if you come up with an idea, you love the idea. When someone else tells you that its not such a good idea, its far easier to call them an idiot than admit that maybe your idea aint so crash hot after all As Lead Designer you need to be able to make people still feel fantastic about their idea and themselves, but not put the idea into the game "Its cool...it just doesnt fit this genre" or "I love that idea! Lets sit down next week and work out a new concept based around that! Oh, no its much too good to put into our current game...".

So, to wrap up, define the positions clearly, and be careful how you approach letting people down. We are all incredibly creative, talented, cool (did I mention egotistical? ;P) people. We need to be treated with diplomacy on occassion. (man that makes me sound like a freakin egomaniacal idiot).





Drew "remnant" Chambers
Game Designer
Relic Entertainment

Share this post


Link to post
Share on other sites
Has anyone considered Valve''s Cabal Design process? I was really surprised at the success they achieved from it, in the form of Half-Life. I read about it in Game Developer, but I''m not sure if it''s on Gama Sutra.

Basically, they said there was no lead designer. No dictator, etc, etc. Instead, they seemed to accept ideas from everyone (even the secretary, I think ) and worked in groups to figure out how to meld all of the ideas together. IIRC, they worked in groups on successively more detailed problems, even breaking up into smaller groups then getting back together again.

This may work when one person doesn''t have an overriding need to go anywhere, design-wise. Then, because everyone has ideas and everyone wants to participate, what''s created is more of a synthesis.

--------------------
Just waiting for the mothership...

Share this post


Link to post
Share on other sites
From what I remember of that article, Valve turned to the cabal system out of, well, desperation is probably too strong a word but something like that. After completing the first game that was HL, they realized that it was no fun to play, so they had to revamp the game in a hurry and it seems like the cabal was their answer to this problem. I think having input from all areas of the game dev. team is vitally important, but I also think you still need a captain to steer the ship. As with many things, what makes this particular person work as a leader probably has more to do with their personality and the personalities of the team members than it does with them following some arcane organizational system.

Just my 2 cents...

R.

Share this post


Link to post
Share on other sites

  • Advertisement