November 2003
- Fwd: Web vs. Java client Eric Merritt
- Fwd: Web vs. Java client Mike Shaver
- MUD-Dev Digest, Vol 6, Issue 3 Alex Chacha
- MUD-Dev Digest, Vol 6, Issue 3 Zach Collins {Siege}
- java clients (was: MUD-Dev Digest, Vol 6, Issue 3) ceo
- MUD-Dev conference 2003/2004 Brian 'Psychochild' Green
- Biz: Game support Peter Tyson
- Biz: Game support Damion Schubert
- Biz: Game support Daniel.Harman@barclayscapital.com
- Biz: Game support Michael Sellers
- Biz: Game support John Erskine
- Advantage for outside skills T. Alexander Popiel
- Advantage for outside skills Jeff Fuller
- Advantage for outside skills Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment szii@sziisoft.com
- Removing access to entertainment Patrick Dughi
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment Hans-Henrik Staerfeldt
- Removing access to entertainment apollyon .
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Peter Keeler
- Removing access to entertainment Matt Mihaly
- Removing access to entertainment Amanda Walker
- Removing access to entertainment John Buehler
- Removing access to entertainment Daniel.Harman@barclayscapital.com
- Removing access to entertainment John Buehler
- Removing access to entertainment Michael "Flury" Chui
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Daniel.Harman@barclayscapital.com
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Jeff Crane
- Removing access to entertainment John Buehler
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment Chanur Silvarian
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Michael Sellers
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Matt Mihaly
- Removing access to entertainment Kwon J. Ekstrom
- Removing access to entertainment Brian Lindahl
- Removing access to entertainment John Buehler
- Removing access to entertainment Damion Schubert
- Removing access to entertainment John Buehler
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Corpheous Andrakin
- Removing access to entertainment Darren Hall
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Chanur Silvarian
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Jeremy Neal Kelly
- Removing access to entertainment Corpheous Andrakin
- Removing access to entertainment John Buehler
- Second Life's customers own the IP of their creations Mike Shaver
- Second Life's customers own the IP of their creatio ns Christer Enfors XW {TN/PAC}
- Second Life's customers own the IP of their creatio ns Lee Sheldon
- Second Life's customers own the IP of their creatio ns Christer Enfors XW {TN/PAC}
- Second Life's customers own the IP of their creatio ns Jeff Thompson
- Second Life's customers own the IP of their creations Corey Crawford
- Second Life's customers own the IP of their creatio ns Corpheous Andrakin
- Second Life's customers own the IP of their creatio ns Ren Reynolds
- Second Life's customers own the IP of their creatio ns Daniel.Harman@barclayscapital.com
- Second Life's customers own the IP of their creatio ns Crosbie Fitch
- Second Life's customers own the IP of their creatio ns Amanda Walker
- Second Life's customers own the IP of their creatio ns Ren Reynolds
- Second Life's customers own the IP of their creatio ns Ola Fosheim Grøstad
- Effects of skill-imbalances? Joshua Judson Rosen
- download-barriers Joshua Judson Rosen
- download-barriers Matt Mihaly
- Language and platform for Text MUD server =?koi8-r?Q?=22?=Andrew Batyuck=?koi8-r?Q?=22=20?=< javaman@mail.ru>
- Language and platform for Text MUD server Miroslav Silovic
- Language and platform for Text MUD server Kwon J. Ekstrom
- Language and platform for Text MUD server Patrick Dughi
From: Andrew Batyuck
> I am doing non-commercial text MUD and rewritten platform from
> scratch several times. Main question is - "What language and
> platform can give good speed and decent extensibility" I
> discovered following in my efforts:
> - Java - VERY extensible, cross-platform and VERY slow and
> memory consuming
> - C# - MOST extensible, cross-platform? =) and rather slow
> - C++ - extensible, cross-platform with usage of third-party
> libs and decent speed
> - C - best speed, but not extensible
I want to describe my experiences with these languages to shore up
my argument a bit more, but I think it would just descend into a
holy war and serve no purpose.
Instead I'll just say C and C++ would be my most favorite choices,
and here's why.
C and C++ can be feisty, but I'd bet that you can compile a C
program on more systems than you could run a java interpreter. They
may not claim platform independence, but existing free text MUDs
like CircleMUD show that they can be set up to compile cleanly
out-of-the-box for most systems out there. Though it is not 'Free'
software, it is free, you can find information about it at
http://www.circlemud.org.
Using C also removes you from the rather arcane and difficult
non-platform dependant features of the poorly designated
platform-independent languages; things like features which silently
return when not supported, operate in slightly different ways, or do
not work and fail at runtime due to environmental setup being
slightly incorrect. Java version changes catch me every other week,
and I couldn't assure you that users are going to be using the
version I developed with - but the standard C and C++ libraries
haven't changed in some time.
As for speed, yes, C and C++, and correctly written, there isn't any
appreciable difference between the two. Drop too far into
abstraction, and yes, you'll start hitting problems - but that's the
trade off for OO design; bloat vs. ease of development. The same
goes for memory for all OO oriented languages, as well as this speed
issue.
As for extensibility .. I'm not sure what you're talking about here.
As far as I know, there are many libraries for C and C++, and using
an OS that supports dynamic linking ensures that you can even have
run-time loading of libraries. Ever try to use the Reflect class in
Java? Not only ugly, but it's not designed to be used in that way
since it breaks the pure OO model. It's also very very slow
(improvements in 1.4 still show lackluster response). Remote method
techniques are possible, but involve a nontrivial amount of external
setup and configuration, not to mention resources for
servers/application frameworks.
Or were you just talking about overloading operators?
Of course, if you were going to develop an interface for your MUD
that works through the web, rather than simple, standard Telnet, you
may want to consider the previous threads on Web Clients. In this
case, C and C++ may not be exactly right for you.
> The only variant i see is to implement own language compiler or
> interpreter that would be extensible and quick - the only choices
> here are C and C++.
I think you are talking about writing a scripting system, so I'll
focus on that. Scripting systems can be written and compiled in
which ever language you'd like. Java can lex and compile as well as
C or C++ - in fact, it may even be a tiny bit easier (at the cost of
speed and memory, of course). You usually don't need speed for
compilation of scripts anyway; it's not something you'd do in game,
on a time table, and memory will be a short-lived issue.
Once the scripts are compiled (whatever that means for you - I
assume a set of bytecode-like instructions or the sort), then it
doesn't matter which language they were originally parsed in, or
even if they mimicked a real language at all. They can be
lua-based, for example, and be compiled and run through the lua
engine and called directly from a C or C++ program. You could even
write up your own parser and lexxer and interpret your own language
from scratch.
Either way, unless you're interpreting your scripts continually
during runtime, I don't think the language you choose to represent
the scripts in, or that you use to parse them will make any
difference.
You may want to look at some script-intensive MUDs or MUSHs for
their techniques on scripting systems.
A last set of questions:
Who is your target audience for this project?
Are you developing this so only you and perhaps some friends can
develop it, is it intended for wide (non-commercial or otherwise)
distributions, or do you just want to get a game out as fast as
possible for your users to enjoy?
Where do your priorities lie?
Will there be any external dependencies like databases, or
maintenance scripts?
Perhaps most important, is it intended to run on both Windows and
UNIX derivatives (inc. Linux)?
These all affect the 'what is best for me' question.
PjD - Language and platform for Text MUD server Alex Chacha
- Ragnarok Wisdom Michael Tresca
- Java on Linux gbtmud
- Java on Linux Artur Biesiadowski
- AS TECHNOLOGY SCATTERS VIEWERS, NETWORKS GO LOOKING FOR THEM Michael Tresca
- Breakdown of Java users Christopher Kohnert
- Second Life's customers get [copyright?] of their creations Joshua Judson Rosen
- Rubies of Eventide shutting down Mantees de Tara
- Rubies of Eventide shutting down Zach Collins {Siege}
- Rubies of Eventide shutting down Sheela Caur'Lir
- Rubies of Eventide shutting down Michael Sellers
- Rubies of Eventide shutting down Koster, Raph
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction David Love
- Dopamine and addiction a t y mcguire
- Dopamine and addiction Lars Duening
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction Rayzam
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction Rayzam
- Dopamine and addiction Marian Griffith
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Eli Stevens
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Jessica Mulligan
- Trusting the client, encrypting data ceo
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Peter Harkins
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Crosbie Fitch
- Trusting the client, encrypting data Richard A. Bartle
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data ceo
- Trusting the client, encrypting data J C Lawrence
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data Paul Schwanz
- Trusting the client, encrypting data Vincent Archer
- Trusting the client, encrypting data Felix A. Croes
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Alain Hamel
- Trusting the client, encrypting data Richard A. Bartle
- Trusting the client, encrypting data Alex Chacha
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Crosbie Fitch
- Payment Transaction Processing altug
- Payment Transaction Processing Sean Middleditch
- Payment Transaction Processing Jason Smith
- Payment Transaction Processing stanza
- Payment Transaction Processing Matt Mihaly
- Payment Transaction Processing Gary Cooper
- Payment Transaction Processing J C Lawrence
- Payment Transaction Processing Gary Whitten