[MUD-Dev] Re: COH and others

[Alex Chacha]

Daniel Harman wrote:

>> Enter City OF Heros, they solved the level problem with the
>> sidekick concept which I think is one of the biggest additions to
>> the world of MOGs to come in a long time.  Now you can have
>> people group with friends of any level and still have some fun.
>> It is not a perfect system, but it is a very good one.

> It's certainly a nice idea on the face of it, but at what cost?
> Metaphorically speaking, I've got a feeling it kills the
> aspiration to level up and kill the dragon. You don't have to, you
> just tag along with a buddy who's already earnt his stripes. Short
> term gratification at the expense of longetivity?

The drive there is to get new powers, when you get sidekicked you
become 1-3 levels lower than your mentor (depends on level gap).
The issue is that you do not gain any new powers, just scale your
current ones.  The incentive is still there to keep leveling and
getting new powers and enhancing the current ones (on odd levels you
get to add enhancement slots to your existing powers thus slightly
augmenting them). Some higher level powers are very useful in high
level encounters, and while the sidekick can contribute, they will
never be as productive as the higher level heros.  Again, not a
perfect system, but works well. In EQ, my friends were level 50 when
I first signed up, I had to spend almost a year by myself learning
how to play and leveling, while I chatted with them.  IRC would have
been just as effective in that case, it would have been nice to tag
along once in a while and see more that the usual a_rat_0, a_bat_0
and a_wolf_0 for months on end.  I suspect more games may adopt this
type of a system to allow newbie to "avoid" the high barrier of
entry and play with friends that got them into the game.

> The correct approach is to streamline the game so that grouping
> and interacting with other people is easier. Encourage groups, but
> facilitate it better and give them bite sized activities. That's
> what CoH seems to do very successfully.

That is exactly the point.  I agree that games need to have
extremely easy ways to form groups. There needs to be an obvious
advantage to grouping.  However, the ability to solo must
exist. There are days when you don't want to group with anyone and
simply want to explore the world and maybe do a mission or two in
peace. That should be accommodated, but soloing (albeit possible)
should never allow experience gain to match that of a group.  CoH
does have a good system where you can simply find people in the zone
and invite them.  One better would be to allow you to search a level
range across all the zones.  The other major feature that is still
missing is "groups looking for heroes", when turned on with a
description by the group leader it will allow people to find groups
that may be interested in doing what they also want to do (some
people want to run around and kill villains, some want to do
missions, some want to explore, some want to stand around and dance;
you can never predict that).

> 'Ship it when its done' is a great ideal, but very few have the
> money to play that game. There are also plenty of people for whom
> it would never be done and they'd never ship! Whilst most aren't
> in game development for the money, there is a bottom line
> somewhere. People want to get paid.

This touches on the issue of vaporware, which is a real problem.
The ideal (ship-when-ready) is great and it should be the goal, but
with some development organizations, this will not work.  People are
either goal driven and/or doing it because they love it. Goal driven
people need to have a drop date, rest need to have a deadline that
is semi-flexible.  It is very demoralizing to design something and
then 3 months before shiptime sit around and cut features out so
that it ships on time (I haven't had that happen to me yet, but I
have few friends who are a bit disenchanted with the whole software
development process, I am sure I'll get there eventually :). It is
obvious in that case that the time estimate was wrong, but also that
the end product will be far from what was intended to ship in the
first place.  It is very tough to get it right and people who know
how to manage this are in very high demand.

One way to do that is to splinter a development effort without
committing marketing resources to it.  After design, development
should be monitored closely and estimated based on the complete goal
of the design (the 70/30 rule works well here). Once the project is
70% done, you can expect at least as much time to get the next 20%
done.  So then based on that estimate, you can ramp up on marketing,
sales, infrastructure, etc.  If it takes too long to get the 70%
done, then it is cheaper to deep-6 it at that point rather than sink
any more money into it.  I always believed that it is better to
realize a failure and move on, rather than deceive yourself and
spiral into oblivion.  This is just one method, but software
development is anything but a process based entity.  Programming is
an artform, and asking an artist to work within a fixed deadline is
never easy ( "Mr. Van Gogh, you need to deliver a painting like
"Irises" to us every 3 month please and if you are late, just don't
fill in the background and maybe use less paint with smaller
strokes?"...I am sure that would fly :) The real tough part is
balancing the needs of the marketing/sales/finance with the needs of
development/qa; but that's no small matter.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev