[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD
cat at bga.com
Sat Apr 25 14:03:48 New Zealand Standard Time 1998
Hmmm. Some of the comments about making a local Java app ring true. A
browser might re-transfer all of the graphics every time you play,
whereas downloading the app makes sure you have a local copy for good after
the first download.
Still, I presume the goal of things like choosing a platform independent
language is, ultimately, the same goal I have: "Get more people to play
my game". Or is it? Maybe, without realizing it, the authors are
actually pursuing the goal of "Minimize the number of people that can
gripe at me that it's impossible for them to play." This is motivated by
the displeasure of hearing that remark from Macintosh, Amiga, and
Xwindows users (among others), or perhaps from BEING such a user and
being annoyed at missing out on other games you would have liked to play.
I contend that doing a Java version of Crossfire like this succeeds at
the goal of "minimize the compatibility complaints you have to hear", but
fails at the "maximize the players" goal.
Consider my alternative tool, Microsoft Visual C++ - which I did, in
fact, choose. Had I even considered the alternative of doing a non-web
based Java app, as Crossfire did, rather than a Windows-only .exe file,
I'd be looking at a simple tradeoff. The majority of my potential
Windows users, the ones who do not happen to already have the Java
runtime environment installed, would have to go through extra download
time, and extra setup time. Some of them would still try the game
anyway, others would decide it's too much hassle to bother with. So I
lose that number of potential users. In exchange, I gain some percentage
of the users of other platforms that Java runs on - most (but not all) of
the non-Windows-based computers out there. It's a simple question of
numbers. Is the number gained larger than the number lost, or smaller?
Well, there was a time in my career as a computer game developer when the
market was fragmented between the Apple II+, Commodore 64, Atari 800,
Nintendo Enterainment System, and Sega Master System - with noticable
slices of the pie also going to the Macintosh, Atari ST, Amiga, and even
that IBM PC thing (though few people bought games for their PC in those
days). It made good economic sense to get games to run on as many of
those platforms as possible, and in fact I made my living for several
years as one of the biggest experts on converting Apple II games to run
on the Commodore 64. (A skill that, in today's market, has a value so
nearly approximating zero as to be undetectable even with high powered
electron microscopes.) In that market, cross platform tools, in the rare
instances where any actually existed (like Infocom's adventure language,
and Sierra's graphics adventure system) were clearly of great benefit.
Today the landscape is very different. The number of platforms with a
significant share of the gaming market is smaller. While you could list
five - Windows, Mac, Playstation, Nintendo 64, and Gameboy... If you
eliminate the ones that Java isn't available for (Playstation, N-64 and
Gameboy), or that don't have modems available and can't play online games
anyway (Playstation, N-64, and Gameboy), the only two that apply here are
Windows and Mac. For choosing between a Windows-only .exe file and a
Java app, the gaming consoles are irrelevant to the discussion because
BOTH choices leave you incompatible with those, at present. So anyway,
lump in all other game sales with the Macintosh sales (a few Linux and
Amiga games are sold for actual money), and call it "other". You'll find
well over 90% of the revenues come from the PC clones, and a paltry few
percent comes from the rest. If you're more concerned with games that
people play for free and you don't care about commercial games - well,
Windows IS the dominant platform in terms of what kind of computer people
own and use. There's supposed to be over 100 million Windows-based PCs
out there now, isn't there? I lost track.
So I can gain some portion of the "paltry few percent" by using Java
instead, and lose some portion of the "90 percent plus" majority. This
can only be worthwhile if the percentage of Windows users lost is pretty
small. But in fact, I'd be willing to hazard a guess that you'd lose
more than half of the people that would have otherwise tried out the
game. The number one problem with computer games has always been that
they're too hard to set up. Putting two extra steps in the setup process
(download the Java VM, install the Java VM) is one of the worst things
you could do.
So if the goal of this port was to maximize the number of actual new
players to Crossfire, I think perhaps the tool chosen was the second best
choice, not the best. If the goal was to minimize the number of highly
motivated potential players who couldn't possibly try the game, it's
probably on target. But I'm more interested in the overal totals, not
just the totals amongst "those players who are willing to go to some
extra effort", who are becoming more and more a minority as the net
reaches increasingly towards the mainstream population out there.
An ideal cross-platform tool puts the extra effort more in the hands of
the developer, rather than the user. The ability to provide compiled,
machine-dependent versions would let the user go ahead and just download
a .exe file (or the equivalent on other platforms) and run it, the same
as they could with a Visual C++ app. All that's required of them is to
look through a handful of links to different versions, and be smart
enough to recognize the name of their OS and click on the right link.
The developer has to go through the extra work of compiling the client
multiple times with different libraries linked in, and keeping all the
different versions available on their web site. They also lose out on
the "coolness" of being able to brag that this one file can run on any
machine, which may be emotionally satisfying to them. But if it comes
down to one or two programmers doing some extra work recompiling, or many
users doing extra work downloading and installing runtime environments -
which is more efficient?
Perhaps Java compilers are sufficiently available and flexible now to let
you do this, and they just didn't choose to take this route. Or maybe
not - I don't really follow Java tools. I'm sure if they're not now,
they eventually will be. It's interesting, though - Visual C++ already
has a set of cross-platform tools available, that will let you compile a
version of an MFC-based app to run on a Macintosh without much effort.
With Windows and Mac, you really do have an overwhelming majority of the
market covered. My client isn't MFC based, though, so I haven't actually
Dr. Cat / Dragon's Eye Productions || Free alpha test:
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev