Advertisement

design team management theory 101

Started by October 06, 2001 05:41 PM
26 comments, last by sunandshadow 23 years, 2 months ago
One of the parts about managing a game design team that you have to do first is recruitment. Even if you happen to have a pre-existing team to work with you still have to get these people to commit mentally to your design and get enthusiastic about it. So 'selling' your game design to your team members seems to be a very important skill. Does anyone want to share any tips in this area? I seem to have had success recruiting artists, so I'll say what has worked for me: - When describing the game to artists, mention the parts that will make it fun to play. - Don't ask for one artist, ask for lots of artists. Artists are usually social people who want to be part of a team, not the only non-programmer. Artists don't want to do all the artwork for a game, they are well aware of how much work each drawing will take. - Let the artists design their own characters and monsters and whatever else they're drawing. If they see themselves as just technicians whose job is to turn your crappy sketches into presentable graphics, they will not be happy. But don't give them a completely open field - suggest some elements and guidelines. The goal is to get them to feel that they are being given an "opportunity to show off". - Positive reinforcement. Whatever you get from an artist, find something positive and detailed to say about it. Tell them that you are grateful to have them as an artist on yor team. Does anyone have similar things to say about how to recruit musicians or programmers? Edited by - sunandshadow on October 6, 2001 6:45:01 PM

I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

if I was going to join someone else''s project as a programmer here''s what I would look for:

a clear explanation of what I am supposed to make. When programs are reworked they become less efficient and harder to debug. We need it all laid out, and I don''t mean we want to know how many levels and what they are named. Specific data isn''t valuable, information about the type of data is. Anything you don''t tell the programmer will take several times longer and he will be the one who decides it for you. So basically a detailed technical document. If you can''t write it you probably don''t know what you want anyway, that means you''re not a good designer and so their''s no reason to join your team.
Advertisement
Hear, hear! The other (technical, as opposed to creative) side of design...
rrr. If I could write the technical design doc I would be enough of a programmer to know what programmers want.

I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

Well, by technical we mean specifications that apply to the general solution (as much as possible) rather than specific scenarios such as "levels" or "dramatic storypoints." The programmer would love a uniform way of providing you with the infrastructure/platform you need to display all your diverse and creative content. But if he/she has to code for each emphatic revelation and psuedo-finale as if it were the game, not only will he/she hate you but your game will be bloated and inefficient.
ok, so what''s a "specification that applies to the general solution"?

I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

Advertisement
I think he means like instead of saying "characters will react differently towards the player depending on previous actions" You go a bit more specific and say how there may be 3 attitudes the NPCs will have: Anger, Neutral, and Friendly. Different conversation strings or actions will have one of these properties and if enough are done the NPC will switch over to a new "personality".
Well, that''s what I think he means and it''s probably a bad example =p I''m not very technical either..
Er..the above was me.

Edited by - Mumboi on October 7, 2001 7:45:05 PM
mumboi, that''s a very decent interpretation.

Too often a "game designer" will say "previous events will influence an NPCs choices in terms of trusting/allying themselves with the player," with an image in his/her mind of a dramatic pinnacle where the player turns to an NPC and experiences betrayal or so. All well and good; now how do I, as a programmer, implement that?

Suddenly we''re trying to represent emotions and ethereal quantities discreetly, and the person with the best conception of how these quantities influence gameplay gave no thought to that aspect, which means that I have to interpret what was meant. Big mistake. End result? Game sucks, or at least is underwhelming. OTOH, if the designer says "Every transaction between characters in the game, be they NPCs or avatars, carries an emotional impact in terms of trust, anger and enthusiasm. NPCs make decisions based on the current compound emotional relationship between the parties as a discriminant." Very verbose and complex statement, but technically complete and unambiguous. Result? Great game.
I see. I can do that.

I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

This topic is closed to new replies.

Advertisement