Comments on: Respecting Design "They keep rallying against conventions and theory, expressing their “individuality” or “creativity” or some other fluffy concept as a defense. It’s because “bad” designers, “lazy” designers who are not willing to put in the work, find it easier to have things fluffy. This fog and lack of clarity is the shield they use to hide behind and we need to rally behind the hard theory and science to gain respect as a profession." This quote made my day. I have felt this way for a long time but never had the skill to put it down in words so clearly and elegantly. Thank you a lot for this, Claire. “They keep rallying against conventions and theory, expressing their “individuality” or “creativity” or some other fluffy concept as a defense. It’s because “bad” designers, “lazy” designers who are not willing to put in the work, find it easier to have things fluffy. This fog and lack of clarity is the shield they use to hide behind and we need to rally behind the hard theory and science to gain respect as a profession.”

This quote made my day. I have felt this way for a long time but never had the skill to put it down in words so clearly and elegantly. Thank you a lot for this, Claire.

]]>
By: LM/2011/06/11/respecting-design/#comment-6254 LM Thu, 23 Jun 2011 19:07:36 +0000 To me a real game designer should be akin to a film director and have the same amount of responsibility and experience that position usually entails. A designer who isn't running a game like a director is more like a staff writer or something similar and gets a similar amount of respect from programmers and Artists as a staff writer gets from the actors, cinematographers, lighters, editors, etc. A director doesn't need to beg for respect, he earns it by working hard to get into a director position or by taking the risks and doing the hard work it takes to make a good independent movie. The parallels are not PERFECT but they are obvious where they fit. People who want to come into the industry as designers and get respect immediately make me chuckle and the companies that allow them do so make me cringe. To me a real game designer should be akin to a film director and have the same amount of responsibility and experience that position usually entails.

A designer who isn’t running a game like a director is more like a staff writer or something similar and gets a similar amount of respect from programmers and Artists as a staff writer gets from the actors, cinematographers, lighters, editors, etc.

A director doesn’t need to beg for respect, he earns it by working hard to get into a director position or by taking the risks and doing the hard work it takes to make a good independent movie.

The parallels are not PERFECT but they are obvious where they fit. People who want to come into the industry as designers and get respect immediately make me chuckle and the companies that allow them do so make me cringe.

]]>
By: Grant Shonkwiler/2011/06/11/respecting-design/#comment-5646 Grant Shonkwiler Tue, 14 Jun 2011 21:22:41 +0000 As someone who is going from theoretical game design to practical game design for the first time in his life, this is really interesting. I've long championed the academic study of game design as being an important step to advancing the understanding of games - and to advancing their position within society. As much as I hate to make cross-media comparisons like this, Film wasn't taken seriously until we had film *critics*, people who could academically examine film rather than just reviewing its capacity for entertainment. Thing is, as you note here, there are designers who don't understand this. We have three designers here in our student studio (myself proudly included this semester) and only two of us put any real stake in design textbooks. The other has a tendency to decry "flowery artsy nonsense" in favour of "you just know whats right" thinking. I'm still getting the hang of balancing taking charge of the design without being a tyrant, but there are a few things I've found (which might warrant a blog post in themselves): - I think designers need to have an understanding of both art and code, and can't be those people who fell into the crack between them. You need to be able to converse with both disciplines on their level in order to both respect their opinions and have input into their work. - The other reason you need to understand both disciplines: nobody likes words. Not artists, not programmers, and especially not producers, publishers, financiers or (in my case) tutors. Designers need to be able to diagram, prototype, sketch and even act out their ideas. Personally, I do all my work in slideshow/presentation software right now, because it makes it easier for people to page through it at their leisure. - An academic background in design is what makes the difference in design arguments. Being able to explain that your position is backed by a study, or psychological evidence, or even just being able to cite an important industry peer, is a lot better than saying "because X game did it first" or, worse, "because I'm the designer". - The designer is not the person who designs the game. The designer isn't even the captain, steering the ship. It's more like everyone has a hand on the wheel, and he's in the middle trying to get everyone to turn in the same direction. In this way, the designer and producer are quite similar roles at times, and really need to work together. Again, there's a lot of inspiration here, so this might just turn into an article of my own soon! As someone who is going from theoretical game design to practical game design for the first time in his life, this is really interesting.

I’ve long championed the academic study of game design as being an important step to advancing the understanding of games – and to advancing their position within society. As much as I hate to make cross-media comparisons like this, Film wasn’t taken seriously until we had film *critics*, people who could academically examine film rather than just reviewing its capacity for entertainment.

Thing is, as you note here, there are designers who don’t understand this. We have three designers here in our student studio (myself proudly included this semester) and only two of us put any real stake in design textbooks. The other has a tendency to decry “flowery artsy nonsense” in favour of “you just know whats right” thinking.

I’m still getting the hang of balancing taking charge of the design without being a tyrant, but there are a few things I’ve found (which might warrant a blog post in themselves):

- I think designers need to have an understanding of both art and code, and can’t be those people who fell into the crack between them. You need to be able to converse with both disciplines on their level in order to both respect their opinions and have input into their work.

- The other reason you need to understand both disciplines: nobody likes words. Not artists, not programmers, and especially not producers, publishers, financiers or (in my case) tutors. Designers need to be able to diagram, prototype, sketch and even act out their ideas. Personally, I do all my work in slideshow/presentation software right now, because it makes it easier for people to page through it at their leisure.

- An academic background in design is what makes the difference in design arguments. Being able to explain that your position is backed by a study, or psychological evidence, or even just being able to cite an important industry peer, is a lot better than saying “because X game did it first” or, worse, “because I’m the designer”.

- The designer is not the person who designs the game. The designer isn’t even the captain, steering the ship. It’s more like everyone has a hand on the wheel, and he’s in the middle trying to get everyone to turn in the same direction. In this way, the designer and producer are quite similar roles at times, and really need to work together.

Again, there’s a lot of inspiration here, so this might just turn into an article of my own soon!

]]>
By: Claire Blackshaw/2011/06/11/respecting-design/#comment-5587 Claire Blackshaw Mon, 13 Jun 2011 08:36:00 +0000 I have already stated that I welcome comment and critique, but not to the extent of presumption that most people take it too. I was specifically referring to the fact no-one, who isn't a programmer, will ever tell a programmer how to code. I'm love code reviews, and I'm one of the few people I know who enjoys pair programming. Also I made formal design review part of sprint process drawing from the idea of code reviews. <blockquote>Design is, by nature, more obvious and understandable to the observer than programming.</blockquote> I take slight issue with this. In many ways the simpler design problems are more approachable as natural language is our primary tool, as opposed to logic or math. Though many design problems and concepts are counter-intuitive and require a grounding of study and understanding to dissect. Now I'm not suggesting for a second we obfuscate our profession with buzzwords or similar curtains of academia, exactly the opposite. Though we do need to communicate to people the more intellectual and skilled nature of our profession. I have already stated that I welcome comment and critique, but not to the extent of presumption that most people take it too.

I was specifically referring to the fact no-one, who isn’t a programmer, will ever tell a programmer how to code. I’m love code reviews, and I’m one of the few people I know who enjoys pair programming. Also I made formal design review part of sprint process drawing from the idea of code reviews.

Design is, by nature, more obvious and understandable to the observer than programming.

I take slight issue with this. In many ways the simpler design problems are more approachable as natural language is our primary tool, as opposed to logic or math. Though many design problems and concepts are counter-intuitive and require a grounding of study and understanding to dissect.

Now I’m not suggesting for a second we obfuscate our profession with buzzwords or similar curtains of academia, exactly the opposite. Though we do need to communicate to people the more intellectual and skilled nature of our profession.

]]>
By: Ben/2011/06/11/respecting-design/#comment-5561 Ben Sun, 12 Jun 2011 10:38:28 +0000 A really good article Claire, found myself nodding in agreement to a lot of what you've written (and also comments already here). @Rob: "because I respect that coming up with fun ideas isn’t that easy." In my eyes, a designer's job isn't to sit there trying to come up with fun ideas: it's to listen to all the ideas that are around, pick the ones that will work with the game you're making, some of which will be the designer's own, and then turn those ideas into tangible tasks. Then monitor how those tasks are coming along and offer up solutions for how to improve what's there. Games are an iterative development, a cycle of implementation and improvement. Once something is in software, as Claire says, most people can see what's bad and offer an opinion up on it. A good designer should understand the underlying system and be able to then offer up the fastest way to improve it. A really good article Claire, found myself nodding in agreement to a lot of what you’ve written (and also comments already here).

@Rob: “because I respect that coming up with fun ideas isn’t that easy.”
In my eyes, a designer’s job isn’t to sit there trying to come up with fun ideas: it’s to listen to all the ideas that are around, pick the ones that will work with the game you’re making, some of which will be the designer’s own, and then turn those ideas into tangible tasks. Then monitor how those tasks are coming along and offer up solutions for how to improve what’s there.

Games are an iterative development, a cycle of implementation and improvement. Once something is in software, as Claire says, most people can see what’s bad and offer an opinion up on it. A good designer should understand the underlying system and be able to then offer up the fastest way to improve it.

]]>
By: Cidolfas/2011/06/11/respecting-design/#comment-5555 Cidolfas Sun, 12 Jun 2011 06:58:32 +0000 Fantastic article, a topic that is both so important to the development of our industry, and so badly understood by many professionals. As a programmer who has worn many hats for many years, I can say that there are very few designers I've ever worked with that I respect. The symptoms for each designer may be different, but the underlying theme for those I do not respect is that I believe they didn't respect their profession themselves. They treated design as something that happens while they try to find fun and excitement. Few of them bother trying to formalize their knowledge, vocabulary, processes, patterns, etc. Even the most cowboy and hacker type of programmer will read books, articles and papers on programming topics regularly, but most designers don't even bother finding out where and how to educate on the profession of design. Many are unable... even worse, unwilling to analyze and dissect other game designs with any more depth than any blogger reviews a game. The result are flaky and chaotically changing designs, trial and error development (exactly as you described) where the trial is imposed on the rest of the team and the errors do not have any sort of consequence. You may have come across such types. :) Fantastic article, a topic that is both so important to the development of our industry, and so badly understood by many professionals.

As a programmer who has worn many hats for many years, I can say that there are very few designers I’ve ever worked with that I respect. The symptoms for each designer may be different, but the underlying theme for those I do not respect is that I believe they didn’t respect their profession themselves. They treated design as something that happens while they try to find fun and excitement. Few of them bother trying to formalize their knowledge, vocabulary, processes, patterns, etc. Even the most cowboy and hacker type of programmer will read books, articles and papers on programming topics regularly, but most designers don’t even bother finding out where and how to educate on the profession of design. Many are unable… even worse, unwilling to analyze and dissect other game designs with any more depth than any blogger reviews a game. The result are flaky and chaotically changing designs, trial and error development (exactly as you described) where the trial is imposed on the rest of the team and the errors do not have any sort of consequence.

You may have come across such types. :)

]]>
By: Peter Christensen/2011/06/11/respecting-design/#comment-5543 Peter Christensen Sat, 11 Jun 2011 18:41:35 +0000 Funny you should say that - I'm building a FPS/Soccer game with Torque 3D, almost as easy as your example. My only problem is that I'm the design/programming/sound/gui/music/texture/model guy.... Funny you should say that – I’m building a FPS/Soccer game with Torque 3D, almost as easy as your example. My only problem is that I’m the design/programming/sound/gui/music/texture/model guy….

]]>
By: Mike Jungbluth/2011/06/11/respecting-design/#comment-5541 Mike Jungbluth Sat, 11 Jun 2011 17:56:26 +0000 Thanks for the correction, edit made, always appreciated :) Yes, the joy of having all your serious mechanics problems already solved for you. The equivalent of colouring in outlines, or programming a FPS on Source. Thanks for the correction, edit made, always appreciated :)

Yes, the joy of having all your serious mechanics problems already solved for you. The equivalent of colouring in outlines, or programming a FPS on Source.

]]>
By: Richard Ranft/2011/06/11/respecting-design/#comment-5539 Richard Ranft Sat, 11 Jun 2011 17:39:55 +0000 Is the problem that mastery is so hard to be acknowledged, or is it that mastery is so hard to define? How can you objectively measure whether someone is a good game designer? Is the problem that mastery is so hard to be acknowledged, or is it that mastery is so hard to define?

How can you objectively measure whether someone is a good game designer?

]]>
By: Claire Blackshaw/2011/06/11/respecting-design/#comment-5537 Claire Blackshaw Sat, 11 Jun 2011 16:49:09 +0000 (So to state my position; I'm a coder, currently my incarnation I'm a graphics coder but I did spend two years as a 'generalist' which is where I'm coming from in this reply) When it comes to the question of 'do you respect designers?' my answer is 'yes, I do' simply because I respect that coming up with fun ideas isn't that easy. However, at the same time, I will question design choices in certain situations, although my take has always been 'the designer has the final word' and even if the questioning doesn't make me chance my mind as to it being a "bad" idea I'll still do it that way. There are only three times I'll question a design choice; - Pre-implementation when something isn't clear. I'll generally read the design a few times and run the idea in my head. This has resulted in my thinking 'this doesn't feel/seem right' at which point I'll head back to the designer to gain more claification/question things until I understand the 'why' of something. The reason behind this is because if I'm not clear and 'do it wrong' it's my arse, if I understand it fully and it doesn't work then... well, it isn't.... - Post-implementation/play testing. This tends to be a case of something being implemented as it was designed but, for whatever reason, it doesn't work. At this point I feel it is my job to feedback to design, to question things, to help rethink the problem to produce the best outcome. I don't claim to be an expert and will defer to the designer in the end. - The third time is linked to the second and I think is part of the 'divide' between code and design; upon deciding something "isn't right" the design will ultimately change, at which point having already put X hours into coding it one way I want to make damned sure that the next Y hours won't be wasted because of some over small missed point. I say I think this is a divide because sometimes a design change might only take 30mins to decide but could take a day or more to code up and get working; as a coder you don't want to feel like you are 'wasting' your time on every whim of a designer which happens. So, I think there is respect there (or at least should be) but at the same time coders will feedback and push to make sure everyone is sure before sinking X hours of work into something which could (and in my experiance will) change. (In fact my experiance quickly became such that I started coding defensively so that quick design changes didn't impact me quite as much as they could have done.) End of the day that 'respect' needs to flow in all directions, for the skills involved and for the amount of time it takes for changes to happen and the impact on the people involved. (So to state my position; I’m a coder, currently my incarnation I’m a graphics coder but I did spend two years as a ‘generalist’ which is where I’m coming from in this reply)

When it comes to the question of ‘do you respect designers?’ my answer is ‘yes, I do’ simply because I respect that coming up with fun ideas isn’t that easy.

However, at the same time, I will question design choices in certain situations, although my take has always been ‘the designer has the final word’ and even if the questioning doesn’t make me chance my mind as to it being a “bad” idea I’ll still do it that way.

There are only three times I’ll question a design choice;
- Pre-implementation when something isn’t clear. I’ll generally read the design a few times and run the idea in my head. This has resulted in my thinking ‘this doesn’t feel/seem right’ at which point I’ll head back to the designer to gain more claification/question things until I understand the ‘why’ of something. The reason behind this is because if I’m not clear and ‘do it wrong’ it’s my arse, if I understand it fully and it doesn’t work then… well, it isn’t….

- Post-implementation/play testing. This tends to be a case of something being implemented as it was designed but, for whatever reason, it doesn’t work. At this point I feel it is my job to feedback to design, to question things, to help rethink the problem to produce the best outcome. I don’t claim to be an expert and will defer to the designer in the end.

- The third time is linked to the second and I think is part of the ‘divide’ between code and design; upon deciding something “isn’t right” the design will ultimately change, at which point having already put X hours into coding it one way I want to make damned sure that the next Y hours won’t be wasted because of some over small missed point.

I say I think this is a divide because sometimes a design change might only take 30mins to decide but could take a day or more to code up and get working; as a coder you don’t want to feel like you are ‘wasting’ your time on every whim of a designer which happens.

So, I think there is respect there (or at least should be) but at the same time coders will feedback and push to make sure everyone is sure before sinking X hours of work into something which could (and in my experiance will) change.
(In fact my experiance quickly became such that I started coding defensively so that quick design changes didn’t impact me quite as much as they could have done.)

End of the day that ‘respect’ needs to flow in all directions, for the skills involved and for the amount of time it takes for changes to happen and the impact on the people involved.

]]>
By: Claire Blackshaw/2011/06/11/respecting-design/#comment-5533 Claire Blackshaw Sat, 11 Jun 2011 16:31:08 +0000 I haven't had the chance to work with someone whose job title was Game Designer yet, I've given myself that title sometimes, but really I'm a gameplay programmer, with a hobby in game design. From the perspective of an outsider that is now entering the industry, with all the gameplay decisions that I've seen since my days playing Spectrum, I would certainly respect someone whose job title was Game Designer. I've followed some game designers closely and a lot of what they say is true. One question that remains is really, how to differentiate a bad designer from a good designer? If the game ends up feeling like a 1995 PSOne wash off, well then its bad design. I haven’t had the chance to work with someone whose job title was Game Designer yet, I’ve given myself that title sometimes, but really I’m a gameplay programmer, with a hobby in game design.

From the perspective of an outsider that is now entering the industry, with all the gameplay decisions that I’ve seen since my days playing Spectrum, I would certainly respect someone whose job title was Game Designer.
I’ve followed some game designers closely and a lot of what they say is true. One question that remains is really, how to differentiate a bad designer from a good designer?

If the game ends up feeling like a 1995 PSOne wash off, well then its bad design.

]]>
By: Mike Birkhead/2011/06/11/respecting-design/#comment-5530 Mike Birkhead Sat, 11 Jun 2011 14:53:05 +0000 [...] Originally written for #AltDevBlogADay [...] [...] Originally written for #AltDevBlogADay [...]

]]>