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.
What makes a good game-designer-team-leader hybrid?
I find that different people take the topic/command when the topic is within their realm of crafting expertise.
Excellent post with excellent answers. Nice!
[color="#1C2837"]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.
[color="#1C2837"]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.
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.
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.
[quote name='DarklyDreaming']
[color="#1C2837"]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.
[color="#1C2837"]
[color="#1C2837"]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.
[color="#1C2837"]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.
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 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:
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)
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?
[/quote]
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?".
[size="1"]Off-topic: How do you stop the system turning b with a bracket into a smiley? Silly automated smiley system...
[size="1"]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.
Author
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!
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!
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.
Alright, I just figured someone might know while they were already on top of it
We know. But this is not the place.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
