fish big, pond small?
Mungo V0.1
‘traditional' design education for designers? Was it pulled?
I thought we were beginning to get somewhere. I think one of the
problems with discussing this is that we get design as a process mixed
up with Object Oriented design. OOD is fine as a formal way of
thinking about certain types of problems, but let's think about the
actual design of a game.
We start with an initial idea, the spark of inspiration; we evolve
this into a concept, create documents meet publishers and present the
ideas. We have to seek criticism and peer review, work with the client
and the rest of the team and evolve the concept into a proper game
description. We have to ensure the ‘styling' is correct by working
with the art and sound teams. We have to develop the story and the
levels. This has to be done within the constraints of technology,
working hand in glove with the code team. All of this to budget and
schedule.
Essentially design is the process of starting from nothing and ending
up with a finished object.
This is a rough summary of aspects of the design process and OOD is
not the answer. It may help you in specific areas but it's not the
answer to all the problems presented above.
I'm not suggesting that those with a design background will be experts
in these areas but students of any product or industrial design course
will have faced all of these issues in their projects many times
during their course. They will have received tuition and faced
criticism (one thing that amazes coders is the concept of ‘the crit',
you'd have to stand in front of up to 30 of your peers and justify
your project, while receiving helpful and not so helpful criticism.
That teaches you how to be self-critical, how to deal with criticism
and how to give it – useful for everyone, but especially some coders I
know).
I know most people think all designers do is copy the last game they
played, but we have a lot more to do besides that. How many projects
never get off the ground because the designer doesn't understand how
to present their work? How many suffer torturous developments because
the designer doesn't communicate his vision to the team or doesn't
remain true to his original goals. How do you deal with wannabe
designer producers? What methods do you use to conceptualise the
design and deal with the creative process? How do you keep focused on
gameplay problems while working to tight deadlines?
How do you ensure all the disparate elements of your game work
together? How do you work within a team?
Of course you'll learn how to deal with these problems but having to
face these problems for the first time at work is plain wrong.
Development is a hand to mouth existence and it can't afford to train
someone from scratch.
There is much more to game design than coming up with cool features.
We think we're a cutting edge industry but from my perspective, as
head of a design team, we are about 50 years behind any other design
discipline in terms of understanding, formalizing and teaching the
necessary skills. We do not have reinvent the wheel to understand our
own design process when we can take so much from the other design
areas. IMO to dismiss the work of so many skilled people is quite
incredible and we do our industry a disservice.
Brandon Van Every
> What happened to the thread where we were discussing the benefits of a
> 'traditional' design education for designers? Was it pulled?
Nobody is in charge of this newsgroup, it's unmoderated. Things can't be
"pulled" except by cancellation of the original poster... or deliberate
hackery, I suppose.
> Essentially design is the process of starting from nothing and ending
> up with a finished object.
What you call "design" I call "Project Management."
> I'm not suggesting that those with a design background will be experts
> in these areas but students of any product or industrial design course
> will have faced all of these issues in their projects many times
> during their course.
Project Management comes in many guises, not just the industrial design
guise.
> I know most people think all designers do is copy the last game they
> played, but we have a lot more to do besides that. How many projects
> never get off the ground because the designer doesn't understand how
> to present their work? How many suffer torturous developments because
> the designer doesn't communicate his vision to the team or doesn't
> remain true to his original goals.
Books on managerial communication are hardly unique to industrial design.
The way I see it, you've learned / experienced some good managerial
techniques through the lens of industrial design. Where you err, is in
thinking this is the only lens anybody should be using. Don't make the
mistake of thinking everyone has to manage the way you do, and everyone has
to have the same background that you do.
> How do you deal with wannabe
> designer producers? What methods do you use to conceptualise the
> design and deal with the creative process? How do you keep focused on
> gameplay problems while working to tight deadlines?
> How do you ensure all the disparate elements of your game work
> together?
Again, I think much of this has to be learned on the job.
Conceptualizations can be taught, I agree. But applying them in the
commercial world takes experience and personal discipline.
> How do you work within a team?
School taught me the exact opposite of working within a team. It taught me
that my programming partner is either much better than me (so I'm a
liability), much worse than me (so she's a liability), or comparably skilled
but not in the same areas (you SQL goddess, but me know how to code). They
were all disasters. Basically I learned, if you want it done right, you
gotta do it yourself.
> Of course you'll learn how to deal with these problems but having to
> face these problems for the first time at work is plain wrong.
It's not "plain wrong," the universe doesn't have some moral valuation of
the business process, and we even have anecdotes from the postmortems of
successful products despite all the flubbing. An engineer doesn't think
about Right and Wrong. An engineer thinks about dominant liability. Is an
underskilled employee your greatest risk? How do you manage that risk?
Typical answer: give the newbie something to do that isn't on the critical
path. Ramp up their responsibility gradually. Of course this assumes the
*manager* knows what he's doing... if you don't have that, you have
problems, and indeed in the games industry there are often problems of that
sort.
> Development is a hand to mouth existence and it can't afford to train
> someone from scratch.
I get tired of all the cost shifting arguments, both in business and
society. Things cost somebody something sometime. You say you don't want
to pay for it. Yet, if you were more flexible in what you viewed as
applicable skill, you could probably make cost-effective hiring decisions
that would work out just fine. Because you're inflexible about what you
want out of the hire, you make things more expensive. You say, "I bemoan
the costs, but I reserve the right to make the process more expensive for
everybody but myself."
In the old days, programmers fresh out of school would go join a big company
like IBM or HP or DEC. They'd get their 2 years of experience in, the big
company would invest in their training. The programmer would then typically
and thanklessly jump ship. But... their logic was the IBM people often
jumped to HP, the HP to DEC, and DEC to IBM, so strategically it all works
out. Perhaps the startup environment of the 90s killed that kind of horse
trading, maybe people all went away from the Big Corps. Except Microsoft,
which offered lotsa money.
> There is much more to game design than coming up with cool features.
> We think we're a cutting edge industry but from my perspective, as
> head of a design team, we are about 50 years behind any other design
> discipline in terms of understanding, formalizing and teaching the
> necessary skills.
Cups have been around since humans started throwing pots. Film has been
around for about 100 years. Primitive video games appeared on mainframes in
the late 60s, a little more than 30 years ago. PONG debuted in 1975, a mere
28 years ago. The proper antecedants of modern AAA titles have only been
around since the early 80s, a little over 20 years ago in the 8-bit Atari
800 / Commodore 64 era. Massively Multiplayer Online Gaming only became
possible in the past 8 years as the Internet became mainstream. It is not a
mystery why we're behind other arts in terms of coda and industrial
maturity. Games *aren't* cups. Cups were fully worked out a long time ago.
With the possible exception of mass production, I bet you can't point to a
single thing in industrial design over the past 100 years that's as radical
as what computer games have gone through in the past 10.
> We do not have reinvent the wheel to understand our
> own design process when we can take so much from the other design
> areas. IMO to dismiss the work of so many skilled people is quite
> incredible and we do our industry a disservice.
Maybe you should study history. Try
http://www.theinspiracy.com/ArGDHSG.htm. You're decrying our need for
industrial design today. Well, games and film have been sparring for a lot
longer than that. I think there's a lot worth taking away from film, but
there are also wrong lessons / disasters you can take away as well. Many of
us remember various Full Motion Video debacles, and it was borne of an era
where Hollywood types thought they could say "Step aside kids, we'll show
you how to do proper entertainment." Films are *not* games. Industrial
designs are *not* games. You have to be *very* **very** intelligent to
extract the correct lessons from other disciplines, quite a visionary to see
what should become coda in game design, and what should be passed up as the
artifacts of a different medium.
--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Nathan Mates
Mungo V0.1 <mungo...@yahoo.co.uk> wrote:
>What happened to the thread where we were discussing the benefits of a
>'traditional' design education for designers? Was it pulled?
Welcome to usenet. All posts that you read are stored on a usenet
server near you, and it expires old posts in order to make room for
more. This is not a conspiracy. This is not selective censorship-- it
applies to all posts based on date. This is how things work. Also,
some threads migrate between newsgroups, so if you're not reading
all of comp.games.development.*, maybe you should be.
If you want to read old posts, the best bet is to go instead to a
server that keeps things longer, such as
http://www.google.com/grphp?hl=en&tab=wg&ie=UTF-8&oe=UTF-8&q=
. Remember, though, that most people won't be able to see the articles
you're responding to (as they've expired to their servers).
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Peter Cowderoy
> I bet you can't point to a
> single thing in industrial design over the past 100 years that's as radical
> as what computer games have gone through in the past 10.
>
The integration of electronics into military craft?
The past ten years of gaming haven't been *that* big a deal. We went
mass-market 3D and upped our budgets a few orders of magnitude. There've
been some evolutions in control schemes, but not to half the extent one
might hope for. Aside from possibly mouselook in FPSes there've been no
real leaps there at all. There's been little truly new gameplay.
Mungo V0.1
What you call "design" I call "Project Management."
They certainly share elements, but I am not a project manager - I have
nothing to do with that aspect of development and don't believe I'm
qualified to.
For my definition to work, would you class the finished 'entity' as
the design spec?
Even if that is the end of the process I don't think any systems
approach can be used as a complete method. But a reasonably complete
method can be derived from traditional design practices. I'm not
saying that it will give you instructions on how to create great
gameplay (that is never going to happen). I'm saying that it gives you
a structure in which to work. At the moment I don't see enough
instruction in the industry detailing good a design process but I do
see many attempts to formalize it. I don't see any fundamental
differences in the industrial/product approach so it is (IMO) the best
place to start looking. Like I say, no need to reinvent the wheel.
"The way I see it, you've learned / experienced some good managerial
techniques through the lens of industrial design. Where you err, is
in
thinking this is the only lens anybody should be using."
I agree that is impossible and I can't advocate this approach for all.
It certainly has an art bias, but less so towards the industrial side.
But I am evangelical about for two reasons. Firstly design is design,
regardless of the discipline, and there is a proven way of doing it. I
not discounting that there are better approaches, I just haven't seen
them.
Secondly, I haven't heard this suggested as an approach on these
threads about becomming a designer, nor anywhere else in the industry.
Game design has come from the programming side of the industry and not
from more traditional design areas (like perhaps web design?).
"Again, I think much of this has to be learned on the job.
Conceptualizations can be taught, I agree. But applying them in the
commercial world takes experience and personal discipline."
I'd go further and say all of has to be learnt on the job. The point
of a design education is to better prepare you, so you learn faster.
One of the difficulties developers face is the length of projects.
Personally, I'm only ever going to have time to develop a handful of
titles - so few opportunities to make mistakes, learn and get it
right. An applied education gives you many opportunities to get it
wrong and learn from those mistakes.
"Basically I learned, if you want it done right, you gotta do it
yourself."
That's a coder's outlook! But for me, working to a design schedule of
a couple of months I have to delegate design tasks, someone else has
to create features/levels/UI etc that fits with the design goals. And
its then when I see the problems of having people with limited
exposure to design techniques.
Making designers work well together is a useful skill, probably learnt
(usually the hard way), and not taught though.
"Typical answer: give the newbie something to do that isn't on the
critical path. Ramp up their responsibility gradually."
Of course, and rely on them to be ambitious enough to research their
job. Remember, my outlook is that a design background is extremely
desirable, so I want my newbies to start with that – they'll
understand the job quicker. I don't see the difference between a coder
wanting to employ someone who has written code and an artist wanting
someone who has used 3DS Max. I know the industry thinks that it is
enough for a designer to have just played games but I think that's
wrong.
Everyone can't do it my way, but design is design and there are books
and journals. I believe game designers should start seeing themselves
as part of the wider design community and use the available resources.
"Because you're inflexible about what you want out of the hire, you
make things more expensive"
I wish! This is my main gripe – this avenue isn't suggested to anyone
wanting to get into game design, so no one does it.
"I get tired of all the cost shifting arguments, both in business and
society.."
This must be a gray position. Presumably there is some minimum level
of competence you or any company would accept before hiring a coder.
And I'm saying that designers should understand the basics of design.
In our industry they are usually hired as testers because they are
into games. Then the more competent ones or the more obviously
creative ones are promoted to the design team. It's the standard model
and many good designers have found there way into the industry in this
way. It just doesn't seem the best way to do it. Design is a way of
working, not just a collection of good ideas. Why not hire on the
basis that they understand that process?
"I bet you can't point to a single thing in industrial design over the
past 100 years that's as radical as what computer games have gone
through in the past 10"
Designing in cups is different to designing cars which is different to
designing buildings. The design processes for all these completely
different objects is basically similar, and that process is equally
applicable to computer games.
http://www.tcdc.com/dphils/dphil1.htm#definition
here is a reasonable description of design in general. I see many
useful starting points there for game design. More specific solutions
can be found in more specific design books.
"Films are *not* games."
Couldn't agree more, but many would you believe that movies are the
way forward for games. There is much that I can see that would be
useful but aren't games more like sports than movies (perhaps a
dubious point)?
Industrial designs are *not* games."
Why not? Their function is different, but many industrial designs have
different functions. Didn't Miyamoto have a massive say in the design
of the N64 handset, and isn't that obvious when you play Mario64? Many
arcade machines cross the boundaries you've set.
I had game design projects at College. As I've listed previously,
games share many of the same requirements of other industrial designs.
Game design maybe a discipline of itself, but it is encompassed in the
larger design family.
Brandon Van Every
>At the moment I don't see enough
> instruction in the industry detailing good a design process but I do
> see many attempts to formalize it.
What does happen, is people who think they have a successful process give a
talk about it at GDC, and/or publish an article on Gamasutra. Then it's in
the marketplace of ideas. Those of us who are proactive about monitoring
the marketplace of ideas, benefit. Those who are reactive, do not.
> Secondly, I haven't heard this suggested as an approach on these
> threads about becomming a designer, nor anywhere else in the industry.
> Game design has come from the programming side of the industry and not
> from more traditional design areas (like perhaps web design?).
Yes, and you're going to find you are up against *profound* prejudices about
telling Programmer Communists what to do game design-wise. I am both a game
designer and a highly skilled programmer, so I understand both sides of the
coin. I don't appreciate some artist trying to tell me that they're the
only ones who know about organizational structure. In fact I have to laugh,
because my work is what makes their work possible. On the other hand when I
put my "film inspired" game designer hat on, it's very frustrating to deal
with the obtuseness of programmers. They think they know how to design
games, and really for the most part they know how to program games, not
design them. Programmer "game designs" are invariably techno-centric. Even
I am guilty, I'm still trying to do a 1.6 million hex planet instead of a
more reasonable 10K hex planet.
Basically, everyone gets frustrated with people who do things differently
than they do. Pronouncing that everyone's going to have to do things your
way in industry is *not* the answer. Your options are (1) go your own way
and be successful at it. Then others will pay attention to what you're
doing differently. Those kinds of people tend to give the GDC talks. (2)
Bend. Live with the world as it is, adjust your priorities.
> I'd go further and say all of has to be learnt on the job. The point
> of a design education is to better prepare you, so you learn faster.
> One of the difficulties developers face is the length of projects.
> Personally, I'm only ever going to have time to develop a handful of
> titles - so few opportunities to make mistakes, learn and get it
> right. An applied education gives you many opportunities to get it
> wrong and learn from those mistakes.
I would say the more obvious answer is shorter projects. The AAA segment of
the industry is in a death spiral about the scope of its projects. It needs
to find a way to do lighter weight stuff. Why train people more to do
grotesquely overburdened tasks? We should be cutting down the tasks.
> That's a coder's outlook! But for me, working to a design schedule of
> a couple of months I have to delegate design tasks, someone else has
> to create features/levels/UI etc that fits with the design goals. And
> its then when I see the problems of having people with limited
> exposure to design techniques.
> Making designers work well together is a useful skill, probably learnt
> (usually the hard way), and not taught though.
Well, maybe learning through the school of hard knocks is what actually
works.
> I don't see the difference between a coder
> wanting to employ someone who has written code and an artist wanting
> someone who has used 3DS Max. I know the industry thinks that it is
> enough for a designer to have just played games but I think that's
> wrong.
The difference is it's physically possible to code a small project - of any
kind, not necessarily a game - and show it off. Ditto using 3DS Max, it's
emminently doable to show your portfolio. In contrast, a game designer
wannabe without the ability to code, has no facility for actually creating a
computer game. Maybe he could design levels for an existing game, but
that's level design not game design. The point is, we don't have any kind
of tangible way to transmit game designs. That's why people are cut slack
about it. When the industry finally has a tangible, portable way to
transmit game designs, yes you won't get a game design job without
demonstrating your ability to do exactly that.
> "I get tired of all the cost shifting arguments, both in business and
> society.."
>
> This must be a gray position. Presumably there is some minimum level
> of competence you or any company would accept before hiring a coder.
Yep. You have to have demonstrable value for my business. But I think
productivity is mostly about doing. 10% inspiration, 90% perspiration. The
cerebral side of me wishes it *weren't* so, but that's the productivity
equation that I find actually happens in the real world.
> And I'm saying that designers should understand the basics of design.
> In our industry they are usually hired as testers because they are
> into games. Then the more competent ones or the more obviously
> creative ones are promoted to the design team. It's the standard model
> and many good designers have found there way into the industry in this
> way. It just doesn't seem the best way to do it. Design is a way of
> working, not just a collection of good ideas. Why not hire on the
> basis that they understand that process?
I don't see why working your way up "through the ranks" lacks merit. It's
not how *I'd* want to deal with a company, I don't care for "gradual
advancement within a club" corporate cultures. But if you've had hands-on
experience with all aspects of the process, what's wrong with internal
promotion?
> "I bet you can't point to a single thing in industrial design over the
> past 100 years that's as radical as what computer games have gone
> through in the past 10"
>
> Designing in cups is different to designing cars which is different to
> designing buildings. The design processes for all these completely
> different objects is basically similar, and that process is equally
> applicable to computer games.
You didn't answer the contention. You ducked it.
> "Films are *not* games."
>
> Couldn't agree more, but many would you believe that movies are the
> way forward for games.
Films aren't "forward" of games in any straight linear sense. Games don't
evolve to become film.
> There is much that I can see that would be
> useful but aren't games more like sports than movies (perhaps a
> dubious point)?
Judges have argued that point on censorship grounds. One cracker judge
says: a game isn't protected free speech because games are akin to sports,
and the activities of a sport cannot constitute protected speech. Sports
also don't generally have obvious audiovisual art assets, so I'm sure this
cracker's opinion will be thrown out eventually. Meanwhile he's tyrannizing
local video game operators somewhere.
> Industrial designs are *not* games."
>
> Why not?
If you go out for a long pass, I'll throw some heavy silver cups at you.
> Their function is different, but many industrial designs have
> different functions. Didn't Miyamoto have a massive say in the design
> of the N64 handset,
That's a game controller, not a game.
> and isn't that obvious when you play Mario64?
No it is not. Me consumer. Me pick things up and use them. Me had
primitive joystick when me 8. Me happy then.
> Many arcade machines cross the boundaries you've set.
Most don't. Most are screens with knobs attached. Ergo, the game is not,
in general, the physical device used to play it. The (arcade) game is how
you interact with your hand-eye coordination.
Brandon Van Every
> On Tue, 29 Apr 2003, Brandon Van Every wrote:
>
>> I bet you can't point to a
>> single thing in industrial design over the past 100 years that's as
>> radical as what computer games have gone through in the past 10.
>
> The integration of electronics into military craft?
Is that industrial design, or engineering? I'm thinking that rocket science
is about how rockets work, not how they're made pleasing to the user in any
art sense.
Gerry Quinn
>What happened to the thread where we were discussing the benefits of a
>
>I thought we were beginning to get somewhere. I think one of the
>problems with discussing this is that we get design as a process mixed
>up with Object Oriented design. OOD is fine as a formal way of
>thinking about certain types of problems, but let's think about the
>actual design of a game.
Here's what you posted originally:
>>However the reference to design being identical to drafting, and your
>>absurd reductionism in only discussing cups, as if that was the be all
>>and end all of the whole world of design, ignoring architecture,
>>industrial design, product design etc, leads to me another conclusion.
OOD is as relevant to game design as architecture. No more, no less -
OOD IS a kind of architecture. I mentioned OOD only once, and it was in
response to the quoted paragraph. That's not so much "us getting things
mixed up" but you running from a thought that threatens your thesis!
>Essentially design is the process of starting from nothing and ending
>up with a finished object.
Well, that involves a lot more than design...
>There is much more to game design than coming up with cool features.
>We think we're a cutting edge industry but from my perspective, as
>head of a design team, we are about 50 years behind any other design
>discipline in terms of understanding, formalizing and teaching the
>necessary skills. We do not have reinvent the wheel to understand our
>own design process when we can take so much from the other design
>areas. IMO to dismiss the work of so many skilled people is quite
>incredible and we do our industry a disservice.
The point I want to make is that you can't bring in architecture as a
discipline of special knowledge, but then dismiss OOD. 'Design' is a
word that has a lot of different meanings, and what you are doing is
special pleading for a particular academic discipline of industrial
design. I absolutely agree that game designers must know something of
such things; it is one of the MANY disciplines they must know something
about. A game designer is a polymath, and therefore a dilettante ;-)
A course in industrial design might benefit a game designer, but
perhaps no more than a course in programming or art. (I must admit I
have still to see the direct benefits of chemical engineering...)
Gerry Quinn
--
http://bindweed.com
Screensavers, Games, Puzzles
New! Try our innovative Screensaver Manager
Download evaluation versions free - no time limits
Mungo V0.1
prejudices about telling Programmer Communists what to do game
design-wise."
"Pronouncing that everyone's going to have to do things your
way in industry is *not* the answer."
"You didn't answer the contention. You ducked it."
My answer to all these points you've raised is this:
The concept of ‘design' has been around for 80 years or so. During
that time designers have established methods for structuring the
design process.
Because of its context and initial developers, computer game design
has a completely different heritage and has had nothing to do with the
other design disciplines. It would benefit it (IMO), as a discipline,
to see how more ‘mature' design areas manage their processes.
The reason I ducked your question goes to the very heart of my
argument – design is design and at a certain level distinctions
between design disciplines are irrelevant and it should make no
difference if it's a house, a cup, or a game (as I hope my link above
illustrates).
Interior designers design graphics, industrial designers design
interiors and architects design furniture – because the processes and
methods are so similar. Of course the details are not similar (a
product designer couldn't design a house) and there definitely
limitations in my argument. Traditional designers deal in more of
visual medium, rather than the ‘experience' medium game designers deal
in. But again it's the process that concerns me - as a way of
structuring your design time it remains valid.
At its heart all design must focus on the user and deal with
technology (see the link on my previous post) and most importantly its
about solving design problems (obviously) – issues I face every day. I
perceive that my background has benefited me and it may benefit other
game designers – hence my rant.
As an aside, I've come across many trained designers in development
but they are all artists, so I'm probably wrong anyway.
"> Industrial designs are *not* games."
>
Ø Why not?"
Your initial statement (and its quite a statement!) threw me and I
don't have an answer (hence my answer). I need to think about this
more – the correct answer would be worthy of a GDC lecture.
"That's a game controller, not a game."
Hmmm – but the distinction (between game and industrial design) is not
as cut and dried as you suggest. My examples suggest crossovers and we
need a better definition of industrial and game design. If Miyamoto
needed to influence the design of the controller to make Mario64 the
2nd best game ever than he is an industrial designer in my book (as
well as a game designer). If its good enough for him...
"Most don't. Most are screens with knobs attached. Ergo, the game is
not, in general, the physical device used to play it. The (arcade)
game is how you interact with your hand-eye coordination."
But then is ‘Shuffle Puck' or ‘Table Football' industrial design? Many
industrial designers would believe so, I wonder where 'game designers'
stand on this issue? These objects deal in hand to eye coordination
but in a different medium. Is the medium enough of a distinction? The
layout of a magazine is drawn from the graphic design discipline, as
is the layout of a web page, even if it is coded and displayed via
light, not ink.
Anyway Brandon, I see you're retiring from this forum so many thanks
for taking the time to discuss this with me and pushing me to think
about it more clearly. Happy coding/designing.
Mungo V0.1
a thought that threatens your thesis!"
Apologies Gerry, I didn't mean to suggest that you got us mixed up.
When I discuss my ‘thesis' with coders I know, they always bring up
OOD – indeed it happened just before I posted (hence my remark).
"OOD is as relevant to game design as architecture. No more, no less
-
OOD IS a kind of architecture"
I'm afraid OOD is much less relevant to my job than design training.
My job involves talking to clients (producers, heads of external dev
etc), establishing goals, presenting ideas, creating and working to
briefs, conceptualizing and identifying game themes, designing UIs (a
difficult task involving ergonomics, semiotics etc - 1st year design
stuff), liaising with art, audio and code team members etc.
Brandon thought this was Project Manager work, but not where I am. A
game designer should be able to do all of this and OOD will not help
(how do you model presenting ideas?) – but a design education will
cover almost of these areas (except the specific tech stuff).
If in a design course allowed you to design a game (hard of soft, not
unreasonable project suggestion, I did it.) how could OOD be more
relevant than that to a game designer?
A product design course summary (degree level):
Level 1 explores conceptual development and the design process,
developing your knowledge and skills through a range of foundation
modules.
Level 2 includes collaborative projects with external industries and
students from other courses, with optional projects in related areas.
Level 3 promotes your individual development in relation to your
personal concerns, directions and interests. The course concludes with
a major exhibition that generally features a final model or prototype
demonstrating design research, analysis and specification to a high
level.
that deals with all the 'hard stuff' I see designers struggle with.
"what you are doing is special pleading for a particular academic
discipline of industrial design."
Nope – I trying to point out that it is absolutely relevant, yet
mostly ignored in game design area. I don't understand what is wrong
with saying a designer should have some knowledge of a design process
before they start work *designing* (OOD isn't a design process).
"I absolutely agree that game designers must know something of
such things; it is one of the MANY disciplines they must know
something
about."
I agree – but a design background is important because that's what a
game designer does –it's more than just coming up with game features,
its all of the above.
"A course in industrial design might benefit a game designer, but
perhaps no more than a course in programming or art"
Sure, these are useful, but that's the advice I always hear given – I
wanted to give some other tips.
Brandon Van Every
> A game designer is a polymath, and therefore a dilettante ;-)
Absolutely true of my knowledge of history and science. I realized quite
awhile ago that *historical research* in the name of realism is a black hole
with little commercial value. I've overkilled my historical knowledge for
the sake of the 4X TBS genre, and my knowledge is spartan compared to what a
historian or scientist would think is appropriate.
> A course in industrial design might benefit a game designer, but
> perhaps no more than a course in programming or art. (I must admit I
> have still to see the direct benefits of chemical engineering...)
You missed the Smell-O-Rama boat then. Remember that product?
Brandon Van Every
>
> Because of its context and initial developers, computer game design
> has a completely different heritage and has had nothing to do with the
> other design disciplines. It would benefit it (IMO), as a discipline,
> to see how more 'mature' design areas manage their processes.
Well, I look to film. And film is chaos.
> The reason I ducked your question goes to the very heart of my
> argument - design is design and at a certain level distinctions
> between design disciplines are irrelevant and it should make no
> difference if it's a house, a cup, or a game (as I hope my link above
> illustrates).
Then how do you feel industrial design informs *film?*
> "> Industrial designs are *not* games."
>>
> Ø Why not?"
Industrial designs do not have rules for a player to follow. They don't
have victory conditions for a player to desire and fulfil. They don't have
components rearranged to express a player's power. They cannot play a game
against a human. Some notions of architecture aside, they are not temporal.
They do not develop character or tell stories. They do not present puzzles
or conundrums.
> Your initial statement (and its quite a statement!) threw me and I
> don't have an answer (hence my answer). I need to think about this
> more - the correct answer would be worthy of a GDC lecture.
If by "initial statement" you mean "industrial designs are *not* games," it
is a trivial statement and not worthy of a GDC lecture. We've had the "how
do we define a game?" debate around here plenty of times. You might search
the archives for everyone's various psychobabble slants on it. In offering
up industrial design as a target, you've offered a turkey shoot.
Film has more of the items on the above list. But it lacks several, the
most important and fundamental one being interactivity.
You would do best to realize that industrial design primarily informs UI
design. An important component of games, to be sure, but hardly the only
one.
> "That's a game controller, not a game."
>
> Hmmm - but the distinction (between game and industrial design) is not
> as cut and dried as you suggest.
A tennis racket is not a game of tennis. A tennis racket is necessary to
*play* tennis. A well designed one may *improve* a game of tennis.
"Flying spaceship" game controllers (I can't think of a better term for the
current crop) are an improvement over the older "rectangle of buttons"
because the hands do fatigue and can benefit from something more substantive
to hold onto. But they don't improve over fundamentally different types of
controllers, for instance flight joysticks, large trackballs, or PONG style
potentiometers. Meanwhile, on a standup arcade machine, the joystick and
button-mash interface is a long since solved problem for a huge class of
games.
> My examples suggest crossovers and we
> need a better definition of industrial and game design. If Miyamoto
> needed to influence the design of the controller to make Mario64 the
> 2nd best game ever than he is an industrial designer in my book (as
> well as a game designer). If its good enough for him...
Who says the success of Mario64 required a different game controller?
Frankly I think such an argument is looney. Miyamoto designed a successful
game, earning him fame as a game designer. AND he designed a better
controller. Orthogonal issues.
I'm wondering if you're too deeply into this "industrial design is game
design" paradigm for your own good. I certainly don't make these mistakes
about film.
> "Most don't. Most are screens with knobs attached. Ergo, the game is
> not, in general, the physical device used to play it. The (arcade)
> game is how you interact with your hand-eye coordination."
>
> But then is 'Shuffle Puck' or 'Table Football' industrial design?
An industrial designer can create a ball, a puck, a playfield, a goalpost, a
sports shoe, etc. A game designer creates the rules of the sport, why it is
rewarding to play. Form follows function. The game designer specifies the
function, within a system of game rules.
> Many
> industrial designers would believe so, I wonder where 'game designers'
> stand on this issue?
On the side of rules and abstraction. Shufflepuck has been implemented in a
number media. Air hockey tables, blipping diode games, PC games, PDA games.
Ditto popular sports.
Brandon Van Every
> -
> OOD IS a kind of architecture"
>
> I'm afraid OOD is much less relevant to my job than design training.
> My job involves talking to clients (producers, heads of external dev
> etc), establishing goals, presenting ideas, creating and working to
> briefs, conceptualizing and identifying game themes, designing UIs (a
> difficult task involving ergonomics, semiotics etc - 1st year design
> stuff), liaising with art, audio and code team members etc.
To draw finer grained distinctions, OOD is a kind of Engineering.
Engineering and Industrial Design are not the same thing. Engineers usually
worry about the guts. Industrial Design usually worries about the
appearance, the psychology, and the interaction.
Incidentally, Mungo, how do you feel about Engineers vs. Industrial
Designers? I'd expect a historical squabble between the two disciplines.
You're going to see that kind of squabble replicated in the games industry
on all kinds of levels. The games industry was created by programmers, who
for most intents and purposes are Engineers. Game Design sits squarely at
the middle of this battlefield, and that's what my comments about
intractable Programmer Communists allude to.
Brandon Van Every
>
> Nope - I trying to point out that it is absolutely relevant, yet
> mostly ignored in game design area. I don't understand what is wrong
> with saying a designer should have some knowledge of a design process
> before they start work *designing* (OOD isn't a design process).
Bullshit! Have you never heard of Rapid Prototyping vs. Waterfall Model vs.
Extreme Programming and all the other various programming design paradigms?
Don't try to tell Engineers they don't design. They design; they don't
design the things *you* design as an Industrial Designer.
Maybe one of the reasons a lot of game designers, perhaps mistakenly, ride
with the paradigms of OOD and other kinds of Software Engineering is they
are, actually, extant practices that successfully inform production.
They're just better at dealing with technological production than creative
production.
Mungo V0.1
don't
> have victory conditions for a player to desire and fulfil. They don't have
> components rearranged to express a player's power. They cannot play a game
> against a human. Some notions of architecture aside, they are not temporal.
> They do not develop character or tell stories. They do not present puzzles
> or conundrums."
All these ideas can comfortably fit inside an industrial design brief
as a set of problems to solve.
"Who says the success of Mario64 required a different game controller"
play it dude
"I'm wondering if you're too deeply into this "industrial design is
game
> design" paradigm for your own good. I certainly don't make these mistakes
> about film."
This debate has polarized our positions. I've agreed that a game
designer needs to know about many different areas.
"Form follows function."
I think that you using the most famous design statement ever proves my
point of the importance established design practices on games design.
Gerry Quinn
>The reason I ducked your question goes to the very heart of my
>argument – design is design and at a certain level distinctions
>between design disciplines are irrelevant and it should make no
>difference if it's a house, a cup, or a game (as I hope my link above
>illustrates).
But "game design" is more than design. It includes art, and something
nebulous called "gameplay" which is probably a type of art. Currently
it also often involves software engineering research (as distinct from
well-understood plug-in solutions).
Plaster ducks on a wall may be the epitome of design, but they are no
good as art. "Design" is just one tool that must be directed by the
"game designer".
Gerry Quinn
>"Industrial designs do not have rules for a player to follow. They
>don't
>> have victory conditions for a player to desire and fulfil. They don't have
>> components rearranged to express a player's power. They cannot play a game
>> against a human. Some notions of architecture aside, they are not temporal.
>> They do not develop character or tell stories. They do not present puzzles
>> or conundrums."
>
>All these ideas can comfortably fit inside an industrial design brief
>as a set of problems to solve.
Not so. Art is not a subset of industrial design. The latter is a tool
of the former.
Another person might argue "All these could fit inside a programming
brief as a set of problems to solve." And it would be wrong in exactly
the same way.
Mungo V0.1
http://www.miyamotoshrine.com/theman/bio/
"When Shigeru entered the Kanazawa Munici College of Industrial Arts
and Crafts in 1970, he studied industrial design"
no doubt completely irrelevant to his career.
Mungo V0.1
> Incidentally, Mungo, how do you feel about Engineers vs. Industrial
> Designers? I'd expect a historical squabble between the two disciplines.
You're correct.
> You're going to see that kind of squabble replicated in the games industry
> on all kinds of levels.
It is very similar - and fairly cultural too. Product/industrial
design isn't considered important in the UK (which is very engineer
orientated), but on the continent you have these great companies -
Braun, Allessi etc
The games industry was created by programmers, who
> for most intents and purposes are Engineers.
which is why I guess there is a degree of resentment when I suggets
there are non-programmers who have a massive amount to offer.
Game Design sits squarely at
> the middle of this battlefield, and that's what my comments about
> intractable Programmer Communists allude to.
It does sit in the middle, and I'm fightning my corner!
Brandon Van Every
> "Industrial designs do not have rules for a player to follow. They
> don't
>> have victory conditions for a player to desire and fulfil. They
>> don't have components rearranged to express a player's power. They
>> cannot play a game against a human. Some notions of architecture
>> aside, they are not temporal. They do not develop character or tell
>> stories. They do not present puzzles or conundrums."
>
> All these ideas can comfortably fit inside an industrial design brief
> as a set of problems to solve.
Fine, but are they routinely solved by industrial designers? No they are
not. I could make all sorts of bureaucratic documents saying "We need to
solve problem X Y Z! We're gonna need a game designer to do it!" but it's
just boilerplate.
> "Who says the success of Mario64 required a different game controller"
>
> play it dude
I have. I really don't see your point.
> "Form follows function."
>
> I think that you using the most famous design statement ever proves my
> point of the importance established design practices on games design.
No, because industrial designers haven't famously said how you determine
function. They only know how to translate function into form.
Brandon Van Every
I studied Sociocultural Anthropology. Assuming I become famous for Ocean
Mars or some title like it some day, are people going to pin all of my
aspirations as a game designer on my early study of sociocultural
anthropology? I don't think they'd be wrong to say that I was and still am
broadly interested in the liberal arts, but getting so specific would be a
bit of a stretch.
What did Shigeru do just before entering the games industry? That would be
more relevant. In my case I did 3D graphics. Currrently, the theme of
monumental simulation of zillions of entities is overwhelmingly obvious in
my work (which you can't see, ha ha ha :-). People would rightly say that I
design games like a 3D programmer. But that may fade over time. I'm not in
love with 3D graphics anymore, I'm just skilled at it. I dislike 3D
graphics to the extent that it interferes with rapid artistic output.
Brandon Van Every
> BrandonL
>
> The games industry was created by programmers, who
>> for most intents and purposes are Engineers.
>
> which is why I guess there is a degree of resentment when I suggets
> there are non-programmers who have a massive amount to offer.
You went much farther than that. You said you weren't going to hire anyone
for a Game Designer position that didn't have an industrial design
background.
> Game Design sits squarely at
>> the middle of this battlefield, and that's what my comments about
>> intractable Programmer Communists allude to.
>
> It does sit in the middle, and I'm fightning my corner!
You are better off avoiding the fight. It's an unwinnable fight, like being
put in a mud ring with a pig and a boxing kangaroo. Better practice is to
either (1) don't make rules about who gets to be the Game Designer, because
that's how the industry actually is right now, or (2) make your rules, make
sure you're the CEO, make sure you have the finances to tell people what to
do. Then succeed at your model and give GDC lectures about it. You won't
win the war, you'll probably never win the war, but you'll gain more
converts to your cause. Nobody will ever listen to you on any argument of
abstract merit or supposition. I quickly got that reality check trying to
hash out the "Game Designers are like Screenwriters, let's empower them as
such" argument with several IGDA folk. A lot of Game Designers think
they're Programmers, and regardless, a lot of Programmers feel threatened by
such a discussion. Historically, Programmers have been in control of game
development and they aren't going to give up their power without a
bloodbath.
Mungo V0.1
> for a Game Designer position that didn't have an industrial design
> background.
That's not exactly what I said.
Mungo said
"… there is one question that I've asked almost every single one of
them – do you find your lack of design training a hindrance to your
day to day work. I don't know of many games designers that actually
have any formal training in design – it's unbelievable."
And
"I would rather have a trained designer (in any field) who didn't play
games, to an untrained games enthusiast."
Fairly wanky perhaps, but not a downright refusal, nor anything about
industrial design. It also referred to those wanting to become a game
designer. Of course experience is valid, but not always.
You're almost right when you say that I want everyone to work my way,
except its not ‘my way', it's an completely established,
international, inter-discipline method, developed over decades.
Everything you see around you has been designed by a trained designer,
it's pretty well proven itself.
Design methods have been developed to help designers solve problems
e.g.
• the identification of a set of needs,
• the initial conceptualization of a way to meet those needs,
• the further development of that initial concept,
• the prototyping of its preliminary form,
• the implementation of various quality control procedures,
from (http://www.tcdc.com/dphils/dphil1.htm#definition), edited.
This is what those who design games do.
These are links to a couple of seminars organized by Design Management
Institute
http://www.designmgt.org/dmi/html/education/seminars/cgdb_s.htm
http://www.designmgt.org/dmi/html/education/seminars/mic.htm
Even these corporate style courses are relevant to those who design
games. Notice how no particular design area is mentioned? You could
almost expect those seminars at GDC.
So I believe if newbies learn about ‘design' they will be better at
designing a game than if they hadn't learnt about it. I don't really
care how they learn about it, but the more they know the better.
I agree that product/industrial design will not solve all of the
problems thrown up by game design. I agree that other areas of
knowledge are required. I agree that some people just ‘have it'.
But haveing a better understanding of design in general will allow
more of us to make better games.
A lot of Game Designers think
> they're Programmers, and regardless, a lot of Programmers feel threatened by
> such a discussion.
What they call themselves is of no significance to me – designers,
programmers, artists, whatever – if they design a game they are, by
definition, a designer and design principles apply. It's not a bloody
club, where you have to show your business card to get in.
If programmers learn this anyway great - but then this is advice for
those who aren't coders.
We all do this during developement anyway, surely I'm not suggesting
heresy? Its just opening up more resources for us.
Mungo V0.1
> Not so. Art is not a subset of industrial design. The latter is a tool
> of the former.
Industrial design is not a tool of art. In fact I don't even know what that means.
> Another person might argue "All these could fit inside a programming
> brief as a set of problems to solve." And it would be wrong in exactly
> the same way.
No they wouldn't, they'd be wrong in a much greater way.
Mungo V0.1
> > "Who says the success of Mario64 required a different game controller"
> >
> > play it dude
>
> I have. I really don't see your point.
Mario64 and the N64 controller are perfectly designed for one another.
>
> > "Form follows function."
> >
> > I think that you using the most famous design statement ever proves my
> > point of the importance established design practices on games design.
>
> No, because industrial designers haven't famously said how you determine
> function. They only know how to translate function into form.
'Function' is determined by the design process! If a door is designed
to function opening outwards, its form should reflect that.
Brandon Van Every
> "Brandon Van Every"
>> You went much farther than that. You said you weren't going to hire
>> anyone for a Game Designer position that didn't have an industrial
>> design background.
>
> That's not exactly what I said.
>
> games, to an untrained games enthusiast."
Ok, I'm guilty of some translation. But what you did say, is you don't
believe in current standard industry practice. You've implied that games
enthusiasm is pretty worthless, even though that's how we've gotten *ALL* of
our game designers, including our best ones. You talked about how you
evaluated your hires, so given your stated preference, I made the mental
leap that unless the candidate has a design background, you're not going to
hire them. You might leave wiggle room in theory for someone amazing, but
in practice, you won't. There are plenty of formally trained designers out
there for you to prefer over the untrained games enthusiasts.
Which, come to think of it, brings up an interesting issue. What do you
think of the appropriateness of formally trained designers who are *not*
games enthusiasts? This is similar to the question of, what about
screenwriters who don't play games? Or even Maya artists, or traditional 2D
artists, or audio guys.
> You're almost right when you say that I want everyone to work my way,
> except its not 'my way', it's an completely established,
> international, inter-discipline method, developed over decades.
That doesn't happen to be extant practice in game development. We of course
have generated our own notables over 30 years without this approach. So, my
challenge to you is, "Why is that?" It undermines some of your religion
about best practices.
> Everything you see around you has been designed by a trained designer,
> it's pretty well proven itself.
I know you didn't mean that literally. My own artwork is hanging on my
wall, for instance. Nor various objects d'art from my travels. Nor the
cabinets in my apartment, probably. My ancient Polish landlord was a
skilled carpenter, but I don't know that he learned any formal industrial
design practice when he learned his craft in the early 20th century. He may
have, but he may have just been apprenticed at some woodshop. And, finally
and most importantly, there's my own game code. Which is in the other
desktop window over there as I type this.
> http://www.designmgt.org/dmi/html/education/seminars/cgdb_s.htm
> http://www.designmgt.org/dmi/html/education/seminars/mic.htm
>
> Even these corporate style courses are relevant to those who design
> games. Notice how no particular design area is mentioned? You could
> almost expect those seminars at GDC.
Looking at those, my immediate question is how much domain-specific meat is
in them. At the far end of the spectrum, that design brief isn't going to
produce a screenplay, or even a treatment for one. Games don't know what
their "meat" is supposed to be exactly, and I do think we need help from
other industries about formalizing our Game Design Documents. But I know
that generic docs that could be used in any industry aren't what we want.
> A lot of Game Designers think
>> they're Programmers, and regardless, a lot of Programmers feel
>> threatened by such a discussion.
>
> What they call themselves is of no significance to me - designers,
> programmers, artists, whatever - if they design a game they are, by
> definition, a designer and design principles apply. It's not a bloody
> club, where you have to show your business card to get in.
Whose design principles? To the extent that I call myself anything other
than a Games Designer, I call myself a Screenwriter. A Screenwriter is a
kind of Writer, not a kind of Designer. Writers have their own history and
coda of best practices, developed over *thousands* of years, not your mere
100 or so. Of course film itself is just as much a new kid on the block as
formal design, so I can't claim complete braggadocio. :-) But maybe you'll
see my point if you look at the history of music, which is older than
writing. A Game Designer is not, by definition, a designer. He is an
artist of some stripe, what is the stripe?
You could try to make Salvador Dali do things in terms of design. Would we
have his paintings in museums? Do we remember Aristotle for his design
practices, or for his logic and insight about Tragedies?
Brandon Van Every
>>> "Who says the success of Mario64 required a different game
>>> controller"
>>>
>>> play it dude
>>
>> I have. I really don't see your point.
>
> Mario64 and the N64 controller are perfectly designed for one another.
...because?
>>
>>> "Form follows function."
>>>
>>> I think that you using the most famous design statement ever proves
>>> my point of the importance established design practices on games
>>> design.
>>
>> No, because industrial designers haven't famously said how you
>> determine function. They only know how to translate function into
>> form.
>
> 'Function' is determined by the design process! If a door is designed
> to function opening outwards, its form should reflect that.
Who decided doors must open outwards? I'll tell you who: the fire marshall.
Um, except in residences they open inwards. Who decided that? Probably the
police and the lawyers, to determine the threshold. Doors that slide
sideways skirt the issue. Who decided that? A landscape architect, as
they're invariably glass. You need someone deciding why doors open inwards,
outwards, or sideways. In games, that's the Game Designer. He's going to
decide it according to the rules of his game.
Nathan Mates
Mungo V0.1 <mungo...@yahoo.co.uk> wrote:
>'Function' is determined by the design process! If a door is designed
>to function opening outwards, its form should reflect that.
That "rule" is violated repeatedly all over the place, I'm afraid.
At home, the door from my apartment to the outside world looks pretty
much like the doors within the apartment, except with a small
peephole. However, the door to the outside opens out, but the inner
doors open inward.
Within a more commercial building, one paradigm is that the door
"knob" shows whether it is to be pushed or pulled-- a flat vertical
rectangle is for pushing, but a flat rectangle with a vertical handle
in it is for pulling. That worked well-- it gave a pretty good idea
where to push/pull. But, due to (I believe) handicapped regulations,
the horizontal bar is common. That's *LOUSY* design-- you don't know
which side the hinges are on, so you can push on the other. However,
if we can't get a consistency of design in the real world, where there
are laws and people ready to sue, how much harder will it be to get
consistency in games, especially ones that aren't supposed to look
like WesternCivilization2003.
You seem to be coming at games from an industrial design sense,
saying "everything should be industrial designed." I can see there's
room for improvement, but I really think you ought to stick to serious
real-world issues. When all you have is a hammer, everything looks
like a nail...
Mungo V0.1
> Mungo V0.1 wrote:
> >>> "Who says the success of Mario64 required a different game
> >>> controller"
> >>>
> >>> play it dude
> >>
> >> I have. I really don't see your point.
> >
> > Mario64 and the N64 controller are perfectly designed for one another.
>
> ...because?
>
> >>
> >>> "Form follows function."
> >>>
> >>> I think that you using the most famous design statement ever proves
> >>> my point of the importance established design practices on games
> >>> design.
> >>
> >> No, because industrial designers haven't famously said how you
> >> determine function. They only know how to translate function into
> >> form.
> >
> > 'Function' is determined by the design process! If a door is designed
> > to function opening outwards, its form should reflect that.
>
> Who decided doors must open outwards? I'll tell you who: the fire marshall.
> Um, except in residences they open inwards. Who decided that? Probably the
> police and the lawyers, to determine the threshold. Doors that slide
> sideways skirt the issue. Who decided that? A landscape architect, as
> they're invariably glass. You need someone deciding why doors open inwards,
> outwards, or sideways. In games, that's the Game Designer. He's going to
> decide it according to the rules of his game.
Exactly - he is the designer and he decides the 'function'. Look, you
brought up the phrase and then showed that you don't understand the
point of design methodology (it is to determine funciton). If I wanted
you to design a computer mouse its a pretty good idea if you design it
to meet it the functions you, as the deisgner, decide it requires. If
it has to fit in the palm of your hand don't make it square and cover
it in razor blades.
The phrase was the clarion call for modernism - do you not notice the
lack of decoration and meaningless detail on modern (last 80ish
years)design - architeture, furnuiture etc? Why do you think that is?
I don't even think that 'Form follows Function' is very applicable to
game design. How about:
Feature follows Experience.
remember where you heard it first.
Mungo V0.1
> In article <1d686c9d.03050...@posting.google.com>,
> Mungo V0.1 <mungo...@yahoo.co.uk> wrote:
> >'Function' is determined by the design process! If a door is designed
> >to function opening outwards, its form should reflect that.
>
> That "rule" is violated repeatedly all over the place, I'm afraid.
> At home, the door from my apartment to the outside world looks pretty
> much like the doors within the apartment, except with a small
> peephole. However, the door to the outside opens out, but the inner
> doors open inward.
Its not a rule, its not a fact, its not a truism. Its a principle.
>
> if we can't get a consistency of design in the real world, where there
> are laws and people ready to sue, how much harder will it be to get
> consistency in games, especially ones that aren't supposed to look
> like WesternCivilization2003.
Consistency isn't the point of design. The 'point' of design is to
create an entity.
>
> You seem to be coming at games from an industrial design sense,
> saying "everything should be industrial designed."
That's a pretty glib representation of my posts. I started, and keep
trying, to talk about the big wide world of creative design. I discuss
what you call 'industrial design' because its what I'm used too and I
can see parallels in methodology. I've agreed several times that it
doesn't provide all the answers.
I can see there's
> room for improvement, but I really think you ought to stick to serious
> real-world issues. When all you have is a hammer, everything looks
> like a nail...
The hammer is design methodology. The nails are design problems. I'm
saying everyone should have a hammer. The counter argument appears to
be we should all scrabble around using sticks and rocks because we
don't believe in hammers.
Mungo V0.1
> But "game design" is more than design. It includes art, and something
> nebulous called "gameplay" which is probably a type of art.
That is not a big enough distinciton. Product design, architecture,
furniture design all 'include art'.
> Plaster ducks on a wall may be the epitome of design,
do you think this? I give you the whole world of applied arts to pick
an example - the Guggenheim museum, the furniture of Marcel Breuer,
Lambretta scooters etc, and you pick plaster ducks. ho hum.
> but they are no
> good as art.
they are no good as design
"Design" is just one tool that must be directed by the
> "game designer".
yes, thats exactly what I'm saying.
Gerry Quinn
>> of the former.
>
>Industrial design is not a tool of art. In fact I don't even know what that
> means.
It is such a tool (for a work of idustrial art, which is what a
computer game is). Just like a recipe for pigments or a set of
guidelines for colour composition is a tool used by a painting artist.
>> Another person might argue "All these could fit inside a programming
>> brief as a set of problems to solve." And it would be wrong in exactly
>> the same way.
>
>No they wouldn't, they'd be wrong in a much greater way.
Same mistake - mistaking the tool for the objective. Industrial design
is your hammer, and you think art is a nail.
Mungo V0.1
design brief - because things are what they are, regardless of the
terms we use.
Gerry:
> idustrial art, which is what a computer game is
Industrial Art? How do you define that?
> Just like a recipe for pigments or a set of
> guidelines for colour composition is a tool used by a painting artist.
No, these are not analogous to the design process.
A recipe for pigments is a way of deriving a certain colour.
I must admit I've never heard of guidelines for colour composition
used by a painting artist, but that would just be a piece of
information.
I'm not suggesting that there is a recipe or a checklist to create a
great game. I am suggesting that there are ways of working that
minimize the chances that the designer makes bad design decisions. I'm
suggesting that other disciplines have established these and we can
take from them.
If you want to come up with your own way of doing it that's up to you,
good luck.
Judging by the amount of games that fail, I'd suggest creating a game
is quite hard, so not having to worry about inventing a process while
developing the actual product, could be of benefit.
> >> Another person might argue "All these could fit inside a programming
> >> brief as a set of problems to solve." And it would be wrong in exactly
> >> the same way.
> >
> >No they wouldn't, they'd be wrong in a much greater way.
>
> Same mistake - mistaking the tool for the objective. Industrial design
> is your hammer, and you think art is a nail.
>
I think that design is the action of creating a physical object that
fulfils a set of needs and entails interaction with a user. My
definition.
I see the design process as the hammer etc (see other reply to the
same remark). My very first post stated that I thought people who
wanted to start designing games should have a design education of some
sort. The debate has centred on industrial design but I'm getting
bored of stating that I don't think this is the only, or a complete,
solution.
Gerry Quinn
>>
>> But "game design" is more than design. It includes art, and something
>> nebulous called "gameplay" which is probably a type of art.
>
>That is not a big enough distinciton. Product design, architecture,
>furniture design all 'include art'.
Those comparisons are invalid (because they refer to only part of a
design process), except maybe architecture. And architecture is not at
all a subset of industrial design.
>> Plaster ducks on a wall may be the epitome of design,
>
>do you think this? I give you the whole world of applied arts to pick
>an example - the Guggenheim museum, the furniture of Marcel Breuer,
>Lambretta scooters etc, and you pick plaster ducks. ho hum.
>> but they are no
>> good as art.
>
>they are no good as design
They are the perfect example of design! They are appealing to the user,
they use their materials well, and they make a strong statement about
the user's sense of style and aesthethics.
>"Design" is just one tool that must be directed by the
>> "game designer".
>
>yes, thats exactly what I'm saying.
Well then I'm not disagreeing - but surely it follows that an industrial
design background is not in any sense necessary or even strongly
indicated for a prospective game designer?
Gerry Quinn
>design brief - because things are what they are, regardless of the
>terms we use.
>
>Gerry:
>> idustrial art, which is what a computer game is
>
>Industrial Art? How do you define that?
A work of industrial art is a unit of creative work produced (normally
for profit) using industrial tools and technologies. Films and computer
games are examples.
A studio of Renaissance artists working under a master might have been
an early precursor.
>> Just like a recipe for pigments or a set of
>> guidelines for colour composition is a tool used by a painting artist.
>
>No, these are not analogous to the design process.
>A recipe for pigments is a way of deriving a certain colour.
>I must admit I've never heard of guidelines for colour composition
>used by a painting artist, but that would just be a piece of
>information.
There's more to pigment than colour. But colour composition is a better
example. Do you think artists don't have a lot of 'guidelines', spoken
or unspoken, relating to the effects of complementary colours in
proximity, etc. Shape composition is the same - I'm sure you've come
across much prattling (albeit largely inane) about the Golden Ratio?
>I'm not suggesting that there is a recipe or a checklist to create a
>great game. I am suggesting that there are ways of working that
>minimize the chances that the designer makes bad design decisions. I'm
>suggesting that other disciplines have established these and we can
>take from them.
I think you'lll have to give specific examples before I have to think of
that as anything but air.
>If you want to come up with your own way of doing it that's up to you,
>good luck.
>Judging by the amount of games that fail, I'd suggest creating a game
>is quite hard, so not having to worry about inventing a process while
>developing the actual product, could be of benefit.
What exactly do you mean when a game fails? Three common issues might
be:
1. It didn't recoup production costs
2. It didn't live up to the hype
3. People bought it, but lost interest after a few hours play
The first is a combination of management and marketing, the fickle taste
of the public, extraneous technical factors such as piracy or the
popularity of a given platform, etc. Nothing much to pin it on design,
per se.
The second is typically a combination of marketing errors, and / or
unrealistic expectations of what current technology can deliver.
Actually, I don't think this is a good definition of a failed game - it
sold, it is played, what if it doesn't also wash your car while you are
playing?
The third is an extreme case of overhyping, perhaps due to the artistic
vision of its creator being untrammeled by practical considerations.
Bad design might very likely be part of the problem here, as distinct
from the other two. But "bad design" in this context might well be
"ambitions, innovative design".
>> >> Another person might argue "All these could fit inside a programming
>> >> brief as a set of problems to solve." And it would be wrong in exactly
>> >> the same way.
>> >No they wouldn't, they'd be wrong in a much greater way.
>>
>> Same mistake - mistaking the tool for the objective. Industrial design
>> is your hammer, and you think art is a nail.
>>
>I think that design is the action of creating a physical object that
>fulfils a set of needs and entails interaction with a user. My
>definition.
When did design subsume technological advance, materials
science, manufacture and marketing?
>I see the design process as the hammer etc (see other reply to the
>same remark). My very first post stated that I thought people who
>wanted to start designing games should have a design education of some
>sort. The debate has centred on industrial design but I'm getting
>bored of stating that I don't think this is the only, or a complete,
>solution.
By design, you seemed to mean industrial design.