I've recently got a degree in Software Engineering and got a job in the industry. One thing I noticed during my job search and during my current work, is the little value companies place on my documentation skills. All they really care about is my coding.

During my degree, the lecturers put great pressue on us to produce detailed documentation, as there is evidence that shows that weak documentation invariably leads to badly produced systems which are full of errors with functionality that doesn't meet the requirements.

It seems maybe the industry has yet to catch up with the idea that documentation is highly important. The research is out there, but it is, perhaps, being ignored.

I'm guessing a lot of companies may also look down on Game Design documentation skills, and they just want to see coding skills.

Exactly what i've been saying in other threads

[quote name='Brobot9k' timestamp='1335230635' post='4934295']
I've recently got a degree in Software Engineering and got a job in the industry. One thing I noticed during my job search and during my current work, is the little value companies place on my documentation skills. All they really care about is my coding.

During my degree, the lecturers put great pressue on us to produce detailed documentation, as there is evidence that shows that weak documentation invariably leads to badly produced systems which are full of errors with functionality that doesn't meet the requirements.

It seems maybe the industry has yet to catch up with the idea that documentation is highly important. The research is out there, but it is, perhaps, being ignored.

I'm guessing a lot of companies may also look down on Game Design documentation skills, and they just want to see coding skills.

Exactly what i've been saying in other threads
[/quote]

Actually, this is a bit different. E.g. While I see the value in good documentation, I still won't hire a guy who can only do documentation but nothing else.

Well, from what i know, Level Designer and Game Designer are 2 different roles, especially for triple-A titles. Mods, maps and prototypes are the best stuff to show LD's capability. As for "pure" designer like GD, I do believe that shipped projects you previously worked on can prove your value.
Sometimes people tend to promote their own employees instead of hiring a game designer from the outside. Things might be a lot different for MMO and casual games.

Correct me if I am wrong.

[quote name='Brobot9k' timestamp='1335230635' post='4934295']
...

Exactly what i've been saying in other threads
[/quote]
Either you're misunderstanding what has been said here, or if that is what you have been intending to say in other topics you have been doing a poor job of communicating that meaning.

In any case, we've already had a recent lengthy discussion covering some of your rather unconventional views on the role of a game designer, so rather than risk this discussion being dragged off topic and closed, that particular line of discussion is to be discontinued -- you may consider this an official instruction from a moderator.

Further on-topic replies to this discussion -- that is; what should a designer have to show when wanting to start or join a team -- are however still welcome and encouraged.

Another thing you might consider as an aspiring designer is starting a blog, containing updates about:

• Projects you're working on. Post updates about your Game Maker prototypes, the board games you're making, etc.
  
• Ideas you have for new games, or for changes to existing games.
  
• Ideas you have for different game mechanics -- not necessarily within an actual game, but simply as building blocks that could be used in combination with others to make a game.
  
• Your thoughts on game design theory, and/or logic (perhaps even scientific) methods of approaching design.
  
• Analysis of existing games, looking at what has been done well, what could be improved, what shouldn't be done, etc.
  
  This would help to show a number of things including your writing and communications skills, your dedication (by sticking to regular or semi-regular posting) and some of your ideas, and if built up over time may provide a worthwhile link to show prospective team-members.
  
  Hope that's helpful!
  
  

  
  Well, from what i know [...]
  

  
  Yes, your thoughts are largely true of the commercial games industry. Indie teams are generally smaller, and will often involve a handful of people or less taking on multiple roles.

While I see the value in good documentation, I still won't hire a guy who can only do documentation but nothing else.

I think this is the standard way of thinking in the industry in my opinion.

In an ideal world, we would have people who have a sole responsibility and can focus on just that, but in the reality of meeting deadlines, and all that jazz, a company needs employees who have more than 1 string to their bow and can multi-task.

It's no longer good enough for a programmer to only do coding, they must also be good at specifying and documenting, and increasingly they must have people skills to deal with clients. I'm guessing that the same goes for the designers; you need to be able to code.

I think a pure designer would be a luxury that only big companies could afford; and in that sense, you'd have to be pretty good at it.

Might not be entirely related, but a girl I know works in HCI (Human Computer Interaction) and she specifies user interfaces and how a user will navigate the system; she does a bit of coding in her job, even though it is really pure design she is doing. I'm not sure if Game Design involves specifying the way a game looks and the way the user interacts with it, but if it does, then I'd assume that understanding the code would definately allow a higher degree of understanding of how the system would and should work.

While I see the value in good documentation, I still won't hire a guy who can only do documentation but nothing else.

This is a fair point, and really why I'm looking at ways to prove ability beyond writing documentation. This thread has already given me some ideas, so it is turning out well.

Well, from what i know, Level Designer and Game Designer are 2 different roles, especially for triple-A titles. Mods, maps and prototypes are the best stuff to show LD's capability. As for "pure" designer like GD, I do believe that shipped projects you previously worked on can prove your value.
Sometimes people tend to promote their own employees instead of hiring a game designer from the outside. Things might be a lot different for MMO and casual games.

Correct me if I am wrong.

In a Triple-A title I would definitely agree that a level designer is usually different from the game designer, but I think from an indie standpoint (or a smaller team) the most likely person to be level designing is going to be the Game Designer. The artist is going to be busy developing assets, and the programmer busy with coding. Even if not, depending on the editor you can introduce new gameplay through level design (Grifball in Halo is an example of this), and development of a well structured level should demonstrate an ability to consider balanced gameplay mechanics throughout design.

that particular line of discussion is to be discontinued

Appreciated.

Another thing you might consider as an aspiring designer is starting a blog, containing updates about:

• Projects you're working on. Post updates about your Game Maker prototypes, the board games you're making, etc.
  
• Ideas you have for new games, or for changes to existing games.
  
• Ideas you have for different game mechanics -- not necessarily within an actual game, but simply as building blocks that could be used in combination with others to make a game.
  
• Your thoughts on game design theory, and/or logic (perhaps even scientific) methods of approaching design.
  
• Analysis of existing games, looking at what has been done well, what could be improved, what shouldn't be done, etc.
  
  This would help to show a number of things including your writing and communications skills, your dedication (by sticking to regular or semi-regular posting) and some of your ideas, and if built up over time may provide a worthwhile link to show prospective team-members.
  
  Hope that's helpful!
  
  

I had thought vaguely about starting a blog, and it is possibly something I will do in the future. The topics you've listed could make for interesting writing I think. At least I'm not (or not entirely) one of those that wants to keep their 'super-secret-ultra-amazing-genre-changing-awesome-mechanic' to themselves.

Might not be entirely related, but a girl I know works in HCI (Human Computer Interaction) and she specifies user interfaces and how a user will navigate the system; she does a bit of coding in her job, even though it is really pure design she is doing. I'm not sure if Game Design involves specifying the way a game looks and the way the user interacts with it, but if it does, then I'd assume that understanding the code would definately allow a higher degree of understanding of how the system would and should work.

Typically speaking, design documents and high-concepts would include UI design and concepts on player interaction.

For a designer, I see programming knowledge as a double-edged sword.

It can help you understand how your game would work, how it can be made, how the UI will interact with other pieces of the program. This in turn, helps you convey your ideas to the programming team. This is all positive from a logistical point of view.

From a creative point of view, this can be a hinderance more than anything else. Because you know what works for you, and how you would implement it, you instictually are confined to that line of thought. I outlined this with my little gun scenario in a previous post in this thread.

Game design should be about what is fun, and making it work. Not what works, and making it fun. Or that's what I think anyway.

From a creative point of view, this can be a hinderance more than anything else. Because you know what works for you, and how you would implement it, you instictually are confined to that line of thought. I outlined this with my little gun scenario in a previous post in this thread.

I agree with that.

What you are talking of is called Latent Knowledge and most programmers will already take this into account. This again comes back to my point that it is not enough for a programmer to be just a programmer, they are also expected to have an education in design documentation, including the factoring in of latent knowledge.

The ability to "think outside the box" is not really a skill that has much weight to it. Most people are capable of it to some degree.

Having a design document drawn up which has impossible tasks in it would require the programmer to be going back to the designer to have those changes made. However, if that designer has no programming knowledge, what is to say he will not simply come up with another idea which is equally impossible to do? As you can see, a potential infinite loop is starting to occur here, which would not be a good situation when deadlines have to be met. Ideally, the designer should have some knowledge of what can and can't be done in order to produce a design which can be turned into a game with very little "back and forth" going on between the development and design team.

Having a design document drawn up which has impossible tasks in it would require the programmer to be going back to the designer to have those changes made. However, if that designer has no programming knowledge, what is to say he will not simply come up with another idea which is equally impossible to do? As you can see, a potential infinite loop is starting to occur here, which would not be a good situation when deadlines have to be met. Ideally, the designer should have some knowledge of what can and can't be done in order to produce a design which can be turned into a game with very little "back and forth" going on between the development and design team.

If you have two designers of equal skill, one with programming knowledge, and one without, then I agree that the one with programming knowledge is probably going to be better. Just so long as they don't start along the lines of "I don't know how to do it, so it can't be done."

A designer that comes up with completely unrealistic designs is obviously something that would want to be avoided too. But it depends on if it is truly unrealistic, or simply original. Head capture a few years ago would have been unthinkable for AAA studios. Now there's full body motion capture for indie teams through kinect. It's just a question of scale.

A designer that comes up with completely unrealistic designs is obviously something that would want to be avoided too. But it depends on if it is truly unrealistic, or simply original. Head capture a few years ago would have been unthinkable for AAA studios.

Yeah I agree, new ideas need to push boundaries, but I would still fail to see how a programmer is not capable of pushing boundaries also, especially if he is already taught not to take his latent knowledge into account.

On the question of pushing boundaries with say, head capture technology; are you making the assumption that it was a bright spark with little programming knowledge who came up with the idea? Or was it a highly technical person who came up with it? I know who I would put my bet on.

This still does not solve the issue of where a Game Designer fits in with a team. Like I said before, I fail to see how a pure Game Designer is capable of coming up with new ideas that a programmer/designer is not capable of. It seems like a straw man argument to say that a Game Designer can push boundaries and a programmer/designer cannot; it is an assumption based on opinion.

I agree with your overall idea that a pure Game Designer is useful and has a unique perspective, but in the real world of competetive businesses and deadlines, I fail to see how a pure Game Designer can really benefit a team in realistic terms.