[MUD-Dev] Dilemmas in a (game) designer's life ?

[John Buehler]

Brandon J. Van Every writes:
> Shane Gough:

>> It seems that every idea I want to experiment with winds up in my
>> MUD design - which doesn't really help a release schedule.

> I think part of the problem here is when we don't work through the
> psychology of enjoyment and reward.  We could probably get a
> feeling of reward from many points in the production pipeline.  Of
> course, there are some parts of the pipeline that aren't
> rewarding, they're just going to be gruntwork.  But still, we have
> a potential flexibility for where we're going to get our sense of
> satisfaction?  Now, do most people ever think about that?  Do they
> sit down and say "What about QA can I find rewarding?"  No.  So
> they do the most obvious rewarding thing: brainstorming.  This
> loads up the front of the pipe, creates additional things that
> "have to" be done.  It's a disaster for scheduling.

> Instead of being like a bunch of undisciplined children always
> running from flower to flower as they brainstorm, we should be
> like a bunch of undisciplined children always running from flower
> to flower across the whole production pipeline.  Now, this may be
> easier said than done, a waterfall model doesn't disappear simply
> because you want it to.  But it bears thinking: *where* in your
> process can you get satisfaction from?  Why does it always have to
> be "let's do this!"

> Dealing with the boring bits of course is simply going to take
> discipline.  But if you're not ducking the issues by loading
> yourself up with more brainstorming, it's possible that more stuff
> will get done in a pleasant way and you'll have less overall need
> for gird-your-loins discipline.

The important thing here is that we keep our eyes on the prize:
happy use of our product by a customer.  Deriving primary
satisfaction from any other step along the way will mean that you
may very well pause and never go beyond that step.

I built a flight simulator a number of years ago.  It was very
primitive at first, but it got out the door.  I did it because I
enjoyed building it and learning how to build it.  But then other
people got their hands on it and they enjoyed using it too.  That
inspired me to incrementally add to it.

My advice to anyone at the hobbyist level is the same that an
experienced author gives to novice authors: get through to the end.
Build yourself a simple MUD.  Keep your eyes on the prize of getting
it into people's hands and have them be happy to use it.  Then you
can incrementally grow your beast and get feedback all along the
way.

Others may be driven purely by the desire to get money for their
work.  That's another way to go, but it's not my way.  Those who
don't build their software for money often find that they delight
their customers, but that their customers don't pay them enough for
the incremental additions that I mentioned.  I am a poor businessman
because my primary derivation of satisfaction isn't the acquisition
of money.  And that goes both ways.  If you love money, but not your
customers, things can get ugly after you have a customer base.  Can
you say 'exploit'?

JB

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