Higher barrier to entry? was RE: [MUD-Dev] NEWS: Blizzard Ent ertainment announces World of Warcraft
bwh at wksoftware.com
Wed Sep 19 22:38:21 New Zealand Standard Time 2001
At 12:26 PM 9/19/01 +0100, Dan Harman wrote:
> I'm interested to know how you are generating the gfx resources?
With an artist, of course =) The two people are:
Brian Hook (me) - designer, programmer, biz guy
Rosie Cosgrove - artist from hell (Rosie was the Art Director on
The key to making games quickly is to vaoid trying to tackle too
many axes of innovation. That's a Carmack-ism I picked up from my
id days. Carmack had a theory that if you want to develop software
on-time and quickly that you can innovate in ONLY ONE of the three
axes: tech, design or art. Innovating in all three directions will
cause any project to bloat, go over budget, and probably have a
serious amount of team strife because of the sheer amount of
confusion that arises when doing _everything_ new. My own personal
experiences tend to bear this out.
So for Rosie and me, we're doing stuff we know how to do. With some
minor exceptions, all the code I'm writing right now I've written
before over the past decade -- I'm not tackling radically new
technology. So it's a matter of implementation -- and when it comes
to just having to implement something, it simplifies into a matter
of focus and discipline. And in the case of the art, it's the same
thing -- Rosie knows 3DSMax and Photoshop amazingly well, and she
can model, UV and texture an object at an alarming pace. And now
that we're no longer burdened by team management and company
politics we can concentrate fully on development, and we're just
cruising right along.
Our game is 50% complete and we've been writing it for 6 weeks now,
working 10-6 M-F. No, it's not DOOM 3 or Worlds of Warcraft, but
it's being done in 10% of the time with 5-10% of the manpower.
> gamasutra with particular interest in small teams, the overall
> trend seems to be that whilst you can get by with a couple of
> coders, you can't shave the art team too much.
Part of project pre-production is understanding the limitations of
your art staff. If you decide up front that you MUST have a certain
amount of hand-crafted content no matter what, you're in for a world
of pain. But if you realize that you can choose environs,
scenarios, tools or methodologies to significantly reduce the
required hand generated content, you'll be fine.
For example, our arcade game has four different settings, and none
involve terrain rendering because that's a whole section of tech and
art we just don't have time to pursue. We only have one artist to
make ALL art assets, so we have to leverage her time effectively.
We do this by designing the game to minimize the amount of necessary
art assets. Same with programmer time -- I don't have time to write
a terrain renderer, so no zipping over the surface of a 1 km long
asteroid. Project triage is something very, very few producers and
managers really understand.
Architecting the design around manageable tools and technology is
very important, unfortunately too many people get caught up with
"design is law!" and forget the pragmatic aspects of game
development. My motto has always been "It's better to ship a good
game now than a great game never".
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev