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?

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

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

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

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

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

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!

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"
==============================

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.

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?