[MUD-Dev] R&D

[Brian Bilek]

amanda at alfar.com wrote:

> There are barriers to entry into any industry, particularly a
> small niche like gaming (note that I'm talking about the developer
> community, not the end user market here :-)).  In a small niche,
> it takes a lot of pulling yourself up by your bootstraps and
> paying your dues in order to demonstrate your proficiency with the
> practical craft of working in that niche as well as the theory.

> I don't think this is anything special about gaming.  I started
> doing networking development in the mid 80s and multiplatform
> development in the early 90s, and recognize a lot of the same
> effects: a small pool of truly field-proven developers, a lot of
> work trying to figure out which successes were intentional and
> which were dumb luck, and a lot of impatience with business types
> who "just don't get it."  15 years later, the landscape is
> completely different.  I think the same will be true of gaming.

I am not sure if this was intended as a counterpoint, or perhaps an
explanation - however it sounds like we are thinking along the same
lines.  While barriers to entry vary greatly from market to market,
I agree they are especially high in an immature, niche market.

So, I agree that from a development standpoint, experience is key,
however I disagree that project management, product management, and
business management necessarily follow.  Code development and game
design are skills learned and earned through experience, but so is
project management of complex software development, as an example.
Often, the skills which are learned in this type of management are
product-independent, and even industry-independent, to some degree.

A brief example of what I mean: Working as a management consultant
some time ago (process mapping, process re-engineering, and software
project management) I applied the same management skills across a
variety of industries and products, including developing a program
office to manage an implementation of SAP for a global chemical
company, and managing the Y2K projects for a large insurance firm.
Of course adaptation was necessary, but part of the skills I brought
to the table were being able to ferret out and streamline company
(and product)-specific processes, and applying general project
management principles to improve the performance of software
development teams.

There are entire organizations devoted to improving the way we deal
with processes and projects, which are of great benefit to software
development organizations, regardless of industry or product.
Carnegie Mellon's Software Engineering Institute (sei.cmu.edu) and
the Project Management Institute (pmi.org) are two excellent
examples.  Isn't the industry a bit myopic if it develops similar
processes while ignoring an entire body of knowledge that has been
gathered for this very purpose?

Earlier on this list, one of our more well known producers presented
an example of the process he goes through when designing a game.  I
instantly recognized a great many parallels to 'standard' software
project management theory.  I have a number of books that could have
been used as guides to developing that design process, adapted of
course to the nature of the project (as it would be for any
project).

An enterprising person might earn credentials from PMI, for
instance, and become instantly valuable to a great many software
developers, across a great many industries, including niche markets
and industries where products are breaking new ground.  One of the
great sources of software development processes and techniques comes
from an organization in a "niche" industry...unique, even.  NASA's
Software Engineering Laboratory.

> Right now, there's more work than skill, and a lot of people who
> have interest at the level of "I want to make games."  There's a
> large gap between wanting to make games and understanding how to
> be part of an effective product team; how to manage large-scale
> development and asset management; and technical skills like
> network architecture, performance issues, high availability,
> testing, and so on.  A modern game is not a simple programming
> task, and so there's a reason that it's hard as an outsider to get
> anything but an entry level position, despite experience in other
> niches.

I think we're making a similar point.  With respect to the actual
coding of games, or the design of games, I would agree with the
above.  In the same breath, you are talking about skills which are
certainly not unique to the management of a gaming project.

My question is - what makes the gaming industry different?  If other
niche industries draw on talent and knowledge considered standard in
software development, marketing, and/or business management, why not
computer game companies?  What is it about making a game that
suddenly turns someone with project management skills into a
'game-company compliant' project manager?

Is it an assumption that since a coder or a designer is more
valuable after working on a few games, that someone working more on
the business end would be as well?

> Luckily, game development is starting to mature.  Taking a single
> example, Game Developer magazine is no longer about tweaky little
> details such as how to do forward differencing in x86
> assembler--it's about asset management, project workflow, and post
> hoc analysis of what things went right and wrong with game
> releases.  It's more and more trying to get industry lore down on
> paper (or electrons) instead of locked into peoples' heads.  This
> is a very, very good thing.  Now, I'm sure there are people who
> think GD mag has gone downhill as a result--there's certainly
> still a place for math and coding tweaks.  But that's no longer
> the central challenge of game development.

A lot of the standard processes that almost all software projects or
software development houses inevitably go through are considered
cumbersome, more work than the coding itself, when they are
implemented from the get-go by a company.  The irony is that whether
or not they are documented and actively managed, the development
-will- go through these steps.  If not documented and managed, there
is exponentially more 'waste' development than there would be
overhead from those processes if they had been defined initially,
and the project has a much greater chance of being completed on time
and on budget.

I would enjoy exploring if there are parallels between the effort
that Game Developer magazine is undertaking and the management
techniques developed in some of the knowledge houses like PMI, SEI,
and SEL.

-Brian


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev