[MUD-Dev] Re: (fwd) AD: [custom graphical] whitestar Crossfire MUD

[Dr. Cat]

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 
tried this.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
*-------------------------------------------**  http://www.bga.com/furcadia
  Furcadia - a new graphic mud for PCs!     ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*

--
MUD-Dev: Advancing an unrealised future.