20 replies to this topic

[Casey Hardman]

What do you think would help a game designer on GameDev.net earn the respect of his team members as the team leader? For example, tips on making a good Help Wanted post for your long-thought-up project that has become a part of your heart, and what to do if you get the members you need from your Help Wanted topic?
Also, sharing your experiences would be helpful.

Edit: I've edited in some of the helpful replies below.

Game Leaders:

A game leader shouldn't:

Suggestions below provided by user "Wai", slightly edited by me

.Be ego centric (can't admit his/her faults)
.Fail to consider suggestions (Be close minded)
.Be unable to see the strengths in others
.Have an immoral or unethical view and try to justify it
.Be selfish
.Be impatient
.Be demanding
.Be manipulative
.Be incompetent and try to hide it (i.e. asking everyone to come up with ideas without generating any him/herself)
.Be unwilling to learn
.Take others' credit

A game leader should:

Some suggestions below provided by user "JBAdams", slightly edited by me, and some by me

.Know how many people his/her project needs and know where to station them
.Respect the ideas of his/her team members, especially those who are more talented than him/her in the field they're discussing
.Be easy and comfortable to talk to
.Make sure everything is organized (the team website, if any, and the GDD) before even beginning to recruit a team
.Have a well-rounded game idea with no obvious flaws or imbalances in the gameplay

Game Designers:
A game designer should:

Following suggestions provided by user "JBAdams", with changed wording and slight editing by me

.Have understanding of mathematics. A couple areas of interest would be probability and trigonometry. Sometimes, a basic knowledge of physics will also come in handy. You should be able to define formulae for things such as weapon damage, chances to hit, etc. and perform basic balancing prior to the additional tweaking that follows actual play-testing.
.Have basic knowledge of psychology. In other words, knowing how players will react to parts of the game and being able to design gameplay to evoke specific moods. Generally, games should be fun, and though inconveniences and consequences aren't totally wrong, extremely frustrating and unfair consequences will reduce the appeal of the game.
.Have studied the flaws of existing games, and be able to avoid them; read the "Bad Game Designer, No Twinkie!!!" series from the Designer's Notebook column.
.Have a working knowledge of business; you should be able to estimate development timetables and costs, and should have an idea of how your designs can be monetized.<BR itxtNodeId="1244">.Have an idea of what is technically feasible, and should be able to clearly and efficiently communicate with those who have greater technical skill in situations where they require guidance. Good communication skills are essential for a designer, as you must be able to get your ideas across to your team.<BR itxtNodeId="1240">

Edited by GHMP, 17 February 2011 - 10:49 PM.

[Tom Sloper]

What do you think would help a game designer on GameDev.net earn the respect of his team members as the team leader?

Several successful released games that credit him as having been the designer AND several successful released games that credit him as having been the team leader / producer.

[Casey Hardman]

Well, you can't really get that in your checklist until you earn the respect of a team well enough to make a successful game. But it is a good suggestion, and I'm sure it would help a great deal in adding a known professional touch to your "Things I've Done" section.

[Wai]

Respect

Speaking personally, I would respect you even if you have not completed any game or even if you are new to game design.
So experience is irrelevant. To me, respect is the default. It is there even if you post nothing. But when you start posting and
discussing, I could lose my respect to you depending on how you reply.

You would lose my respect by doing these:

o Fail to admit faults (Being ego centric)
o Fail to consider suggestions (Being closed minded)
o Fail to follow an argument and dismisses it as unimportant
o Being unable to see the strengths in others
o Have an immoral or unethical view and try to justify it
o Being selfish
o Being impatient
o Being demanding
o Being manipulatively
o Being incompetent and tries to hide it (i.e. asking everyone to come up with ideas but don't generate any yourself)
o Unwilling to learn
o Takes others' credits

If I see your post with a lot of experience and I decide to join your team, I could be joining for a number of reason. For example,
I may join because you have a record of success, which leads me to believe that joining your team is a good investment of my
time. If I join only because of that, repect may not be present (i.e. I'm just doing it for the return, you are not a person to me, but
a mean for me to earn some benefit).

If I join your team because I respect you, it means that:

o I believe that your goal is worthwhile, and you are a good person
o .. that I want to help you achieve your goal
o .. that I want to work with you even if your project changes
o .. that I want to know you even if you have no project

I don't know whether this answers your question. Perhaps you would decide that what you need is not a team that respect you,
but a team that is efficient, competent, resourceful, etc... But if respect is really what you want, the above analysis shows that
if you want to attract team members that respect you, your post would need to be candid, open, thoughtful, and concise.

Candid: This shows that you are fair and not trying to take advantage of your team members
Open: This shows that you are someone who others can work with
Thoughtful: This shows that you are capable of considering and making decisions
Concise: This shows that you can sort through distractions to make correct decisions

Respect alone would not get you a team. On top of that you need competence. The above only shows what it takes for the
team to respect you. The situation is like this: It doesn't matter how competent you are. The bottomline is that I would work
with you only if there is mutual respect.


* * *

To be fair though, different people look for different qualities in a leader. Respect is just one aspect. It is important in some
group dynamics, but not in others. For instance, you could always blackmail every member of your team to make them work
for you, beat them up until they submit, or pay them a lot of money. Having respect is just one situation. Different quality attracts
different team members, and being respectable isn't a quality that one can easily fake.

[Trapper Zoid]

In order to be a good team leader, you need... well, leadership skills. Be able to communicate, delegate, organise, make decisions, take responsibility etc. etc.

What the team leader doesn't have to be is the most skilled in technical areas, as long as they ask intelligent questions to the team members who are.

And also what Wai wrote. Basically if you do anything of those things on the "lose respect" list it shows you are lacking in those vital leadership skills, and that raises some serious red flags.

[jbadams]

[...]

Excellent post, I would agree with all of those.

I have some tips of my own to add:

• Presentation is important; your post does not have to be some beautiful work of art, but readers should be able to tell that you've put in effort and that you care both about what you've written and what you've written about.
  • Your Help Wanted post should be free of spelling and grammatical errors. You should run it through a spell-checker as well as proof-reading before submitting.
  • Your post should, as much as possible, be free of obvious flaws such as broken links, unclosed tags or incorrect formatting. Use the preview function and look carefully over your post before submitting. Check any links to make sure they work as expected.
  • Your post should be detailed and include all the relevant information, but without rambling on endlessly. If you're posting here at GameDev.Net you'll need to follow the Help Wanted template, and you should have good, well-thought-out answers for every section. If you're posting elsewhere you should be sure to still present all the appropriate information up-front, and in some neat, structured fashion; you may still want to use our template as a guideline in this case.
    • Some good things to include in a detailed post include concept art, mock-ups, or work-in-progress art for your project. You might also include video, or when you're far-enough along should include some work-in-progress screen-shots.
    • Use thumbnails for large images as appropriate, and don't include too many -- if you've got more to show and your post is becoming too large you might consider linking to an off-site gallery and/or saving some of your additional content to post when "bumping" your topic at a later stage.
    • If you're willing to share your design document -- you already know that I'm of the opinion you should, but it's your choice -- don't paste the thing into a topic and have a giant wall of text. You should instead link to the full document off-site, or attach it for download. If you wish to include a few small snippets you could consider doing so using spoiler tags (in the "other styles" drop-down of the full post editor), which look like this:
      Spoiler

      This is an example of a spoiler. Even with many lines of text it will collapse down to a single line.
  • Your post should not make excuses for errors, or for content you have not created yet. Rather than mentioning that you're not sure if something is spelled correctly you should find out before posting. Don't mention that you'll have some screen-shots in a few days, but instead wait a few days and include them.
  • If you don't have a team-name or project name that's fine -- plenty of people don't -- but these sections of our template are marked as optional, and it looks sloppy to include the headings if you're not going to provide the information.
• You should be ready before you post. Make sure you have your design document, and if you're planning on learning a technical skill make sure you've learned enough to be useful to the team before recruiting. Consider producing some example work, even if it's just maps or mods for an existing game, or mock-ups of your ideas.
• Don't look for a huge team right away. Start off small, and add extra people only as you need them; far too many teams recruit a whole load of people and then don't really have proper jobs for them to do, and a large team means you'll have to spend more time managing the team than actually working on the project. Only bring on more people when your current team can't handle the project without them.
• Look for the right people. You won't necessarily find experts in every field, but you don't have to recruit everyone who wants to join. If someone seems unsuitable or doesn't offer any real value to the project then don't add them to the team.

I have some more to say, but once again I have to run for now -- hope some of that helps!

[Konidias]

Along with what has already been said... a big one for me is... HAVE TALENT.

Seriously, there's nothing worse than an untalented leader/designer. As a game designer/leader, you need to be a jack of all trades. You don't have to be amazing in one particular field, but you do need to have a grasp on a little bit of everything.

You need to be at least good (don't necessarily need to be great) at:

- leadership
- communication
- designing
- writing
- art
- music/sound
- programming

The way I see it, the guy leading the project and designing the game better damn well have a background in everything, because he needs to know a bit about everything in order to fully understand game development. Without having knowledge in an area, you can't possibly know the limitations, or the work involved, etc...

Also having a good natured personality is pretty big. You can have all the above qualities and lack a good personality and nobody will want to work with/for you.

You need to bring something to the table other than just being the idea guy. If that means helping do some rough artwork for the artists to later improve, fine. If that means doing some sound effects, fine. If that means writing up dialogue for characters, fine. But do *something*. Not just "I have a grate ideea 4 a game! Make it 4 me!"

[DarklyDreaming]

Show me you are a leader - show the way by doing. This is really often missed - a prototype, even a rough one, would give your project a much better chance of finding real talent just because it shows you are committed to the project enough to get your hands down and dirty. A well written GDD could do the same. Or perhaps some artwork? Music? See there are a hundred ways to show you got talent and the will to use it. The question boils down to how can you show it? What skills do you have and which must you enlist help to cover?

But regardless, a leader should communicate efficiently, promptly and clearly with all the respect your team members deserve. It's very important the leader has a clear minded way of communicating what the next stepping stone is in the project and making sure the team completes their jobs on time.

[a_naked_guy_in_mcdonalds]

Wow, really good stuff here.

Under the heading of the communication, be sure to emphasize documentation. The design lead generally produces the most documentation of anyone on the team. He has to convey his vision in writing to the rest of the team. Not only should he grammatically write well, bit he should be very, very, very (did I say very?) good at explanation.

If he is also the team lead, he should be Hell and Jesus at organization, tracking, and asset management. He should also be able to control feature-creep.

In that role he is not only in charge of getting the game done, but how it gets done.

[Casey Hardman]

Wow, a forum post that has good replies only (at least so far hehehe)? How rare!
Of course, I'm asking this because I'm a 'game designer' myself.
Though I've never published a book, I am a fantasy writer myself, so I know a little bit about explaining things well, mainly because I have experience trying to explain things in the least amount of words required (so people stay on track).
The GDD for my project is, so far, 23 pages and growing, but it's not even halfway done with quests and story.
For making windows, rather than saying "Put a box on the left side and a larger box under said box, oh and two on the right side", I made some really crappy Paint documents. That way, you can at least get an idea of where the 'boxes' are supposed to be. Do you think this is a good idea, or is it telling the artists how to do there job in the wrong way?
Konidias said:

But do *something*.
Not just "I have a grate ideea 4 a game! Make it 4 me!"

I think this kind of view of game designers is common around GameDev.net. At least, that's what I noticed.
Are all game designers really like this?
It seems like writing up the GDD is almost considered to be no work whatsoever...like people just disregard it and say "You've done nothing so far" even if you have a detailed, well-written GDD.
That just seems to be what everyone gets at when they talk about game designers - the GDD means nothing and they're useless members unless they code well, regardless of the GDD's state.
As usual, JBAdams gave me a really long, well-written and helpful reply, and so did Wai. The rest of the replies were great, too, as they added in some things the others didn't have without re-writing everything and making a huge post without much point.
Thanks to everyone! I'm on my least favorable computer right now, so I don't want to go on very long. Maybe I'll edit the post and quote some of the posts.
And...maybe, just maybe, the post could get STICKIED (I can barely contain myself with the sheer anticipation...!!!)
In the meantime I'll leave you with the question I asked in this reply a few blocks of text ago and the following one.
I've heard that a boss telling his team something in the way of "I got this all down - here's how you should code it, I wrote it down but you guys should just finish it up" is really annoying. He/she (the one I heard this from on one of my other posts...I'll find his/her nickname) said it throws away their talent and confines them to something an inexperienced person suggested.
So do you think it's annoying when your game designer tells you how to draw something or how to code something?
I didn't think it'd be wrong to give a simple suggestion, but what do you think?

[Wai]

Re:

Design isn't just about having ideas, but making decisions.

If the designer tells you what you need to do, then there are two situations:
1. It is necessary.
2. It is unnecessary.

If it is necessary and you understand that it is necessary, then you would not feel annoyed. You would just think that it is normal procedure.
If it is necessary but you don't understand that it is necessary, then if you get annoyed it is your fault.

If it is unnecessary and you thought it is necessary, then you would feel that the designer is doing a good job.
So the only legitimate situation to be annoyed is when it is unnecessary and you know that it is unnecessary.

Within this situation, if the designer also know that it is unnecessary, then the designer should be able to stop himself anytime. So the refined description of the situation is:

The designer tells you to do something because he thinks that it is necessary, but you know that the reality is that it is not necessary.

In this situation, you are annoyed because you know that the designer who is telling you what to do can't even tell what is necessary and what is unnecessary.
In other words, you have just realized that your commanding designer is a worse decision maker than you and tries to make decisions for you.

My Conclusion:

It is not wrong to give suggestions. But if it is unnecessary and annoying, the designer should be able to just stop.
If it is necessary, the designer should be able to explain clearly.
If the designer can't justify his choices, then he isn't a designer, but a client--and the GDD is not a GDD but a wishlist.

[aersixb9]

I find that different people take the topic/command when the topic is within their realm of crafting expertise.

[Kekko]

Excellent post with excellent answers. Nice!

...Pure logic beauty about decision making...

I'd like to expand on this from a programmer's perspective.

If the coding has any implications on the game design then of course you can provide suggestions or decisions, it's your job. This falls in the "necessary and you need to be able to explain why" category. If it doesn't have any design implications then you can still come with suggestions but be very aware that they probably know better than you, so be very humble and/or very sure. Unless you're better at programming than them in which case you're probably the lead programmer anyway so go ahead and decide.

Personally, my ideal situation would be that programmers are able to spot important design implications in low-level code and bring in the designers when necessary. This way designers can focus on the high-level stuff. One example was when I was coding various item modifiers for an rpg (+4 strength, -5% dex, etc). While doing this I realized that the order in which these modifiers are applied matters.

 (5+1)*1.2 = 7.2
 (5*1.2)+1 = 7

It's a small issue, but it has effects on gameplay and the designer should have his say on how to handle it. He was brought in, we came to an agreement and everything was fine. Yay.

As an aside, a designer needs some math skills. Games throw around a lot of numbers. Depending on what game we're talking about you will calculate stuff like damage per second, income per minute, experience per level or maximum speed given all possible modifiers. If you can't do it yourself, you need to at least be able to understand the answers you get if you ask someone.

Show me you are a leader - show the way by doing. This is really often missed - a prototype, even a rough one, would give your project a much better chance of finding real talent just because it shows you are committed to the project enough to get your hands down and dirty.

A good thing to do if you want free-as-in-beer members is to do all the stuff that nobody else wants to do. It's your job after all. One example might be testing where you track down when and where this or that crash occurs, or converting various files to the right formats. If people can focus on what they like to do, they're more likely to work on your dream, rather than one of their own.


Speaking of which, as a designer it's probably good if you know how to read and use command line tools and scripts as it's usually a lot quicker for a programmer to whip up one of those, rather than full a rich GUI program.

I think this kind of view of game designers is common around GameDev.net. At least, that's what I noticed.
Are all game designers really like this?
It seems like writing up the GDD is almost considered to be no work whatsoever...like people just disregard it and say "You've done nothing so far" even if you have a detailed, well-written GDD.
That just seems to be what everyone gets at when they talk about game designers - the GDD means nothing and they're useless members unless they code well, regardless of the GDD's state.

Not everyone of course. I'm guessing they pop up more often because the good ones find help quickly and are already hard at work. Although I must say well-written and detailed GDDs are kinda rare. Often huge parts of it are fluff texts and race/unit/item descriptions that doesn't contain that much info on gameplay. Maybe with lots and lots of stats that seems to be just made up without any testing or solid mathematical reasoning on game balance. Don't get me wrong, the descriptions are important too, but fairly useless if a coder sits down to code the game. I have made several of these for the fun of it, usually in an afternoon or two. That's not much work.

Still, if you're willing to show your GDD and let people criticize it then it's just a matter of time before it's both detailed, well-written *and* really useful.

[jbadams]

We've got plenty of tips on being a good team-leader now, but not much on being a game-designer.

A few thoughts in that area:

• A game designer should have a working understanding of mathematics - a couple of areas of interest should include probability and trigonometry. Depending on the types of game you're creating a basic knowledge of physics will also come in handy. You should be able to define formulae for things such as weapon damage, chances to hit, etc. and perform basic balancing prior to the additional tweaking that follows actual play-testing.
• A game designer should have a basic knowledge of psychology; you should know how players will react to different stimulus, and be able to design game-play to evoke specific moods.
• A game designer should have studied the flaws of existing games, and be able to avoid them; read the "Bad Game Designer, No Twinkie!!!" series from the Designer's Notebook column.
• A game designer should have a work knowledge of business; you should be able to estimate development timetables and costs, and should have an idea of how your designs can be monetized.

A designer should have an idea of what is technically feasible, and should be able to clearly and efficiently communicate with those who have greater technical skill in situations where they require guidance.

Good communication skills are essential for a designer, as you must be able to get your ideas across to your team.

Some further reading I would recommend includes:

• Why Design Documents Matter (Designer's Notebook)
• The Bill of Player's Rights (Designer's Notebook)
• The Tao of Game Design (Designer's Notebook)
• The Declaration of Game Designer Independence (Lost Garden)
• The Chemistry of Game Design (Lost Garden)
• What are game mechanics? (Lost Garden)
• Tom Sloper's Game Design FAQs (Sloperama)

[Trapper Zoid]

But do *something*.
Not just "I have a grate ideea 4 a game! Make it 4 me!"

I think this kind of view of game designers is common around GameDev.net. At least, that's what I noticed.
Are all game designers really like this?

Only the amusingly bad ones.

For recruiting for the sorts of projects that are suited for GDNet in today's day and age, I'd expect the designer/leader to have a playable prototype. It doesn't have to be pretty and it doesn't have to be complete, but IMO there is no good reason for someone not to have something playable to sell their idea to prospective team members. There are a ton of cheap or free tools out there these days (GameMaker, Unity etc.) that let you whip up something quickly with little to no programming experience. If a designer can't throw together a prototype then that suggests that either a) they don't really know what their game is about; b] the game is way beyond their scope and/or c) they're too lazy to put in the work.

Edit: This doesn't count projects where the explicit purpose is learning, i.e. "I'm a newb and want to learn how to make games, are there any other newbs who want to join in?".

Off-topic: How do you stop the system turning b with a bracket into a smiley? Silly automated smiley system...

[Tom Sloper]

Off-topic: How do you stop the system turning b with a bracket into a smiley? Silly automated smiley system...

Maybe by turning off the HTML? Click to configure post options.

[Casey Hardman]

Something I wanted to ask that I think is related to the topic was: how do most projects combine all of their coding, graphics, music, sound effects, and so on into a...well, a game?
Do they use UDK or some similar program?
Also, is it legitimate to use very simple Paint sprites in some situations? Would they 'work' with a 3D game? I ask this because I had drawn up the 'cursors' for my game, since it's an FPS and the gun accuracy affects the cursors, and I was just wondering if they'd be useable.
Oh, and how do you make an installation 'wizard' for your game? Is that something the game designer could do? If so, that would be something helpful for a game designer to add in to his/her "things I'll be doing for the project" section...or at least that's what I figured.

Planning on making another edit soon to acknowledge all of the great answers - by the way, thanks for all of the great answers!

[Tom Sloper]

Something I wanted to ask that I think is related to the topic was: how do most projects combine all of their coding, graphics, music, sound effects, and so on into a...well, a game?
Do they use UDK or some similar program?
Also, is it legitimate to use very simple Paint sprites in some situations? Would they 'work' with a 3D game? I ask this because I had drawn up the 'cursors' for my game, since it's an FPS and the gun accuracy affects the cursors, and I was just wondering if they'd be useable.
Oh, and how do you make an installation 'wizard' for your game? Is that something the game designer could do? If so, that would be something helpful for a game designer to add in to his/her "things I'll be doing for the project" section...or at least that's what I figured.

You've gone off-topic, ghmp. Those questions are way outside the realm of Game Design. You should ask those questions in For Beginners (after you read http://archive.gamedev.net/reference/start_here/)
THIS forum is only for Game Design questions.

[Casey Hardman]

Alright, I just figured someone might know while they were already on top of it

[Tom Sloper]

Alright, I just figured someone might know while they were already on top of it

We know. But this is not the place.