April 1999
- In-Game Languages Eli Stevens {KiZurich}
- In-Game Languages Per Vognsen
- In-Game Languages Chris Gray
- In-Game Languages Caliban Tiresias Darklock
- In-Game Languages Eli Stevens {KiZurich}
- In-Game Languages Matthew D. Fuller
- In-Game Languages Mik Clarke
- In-Game Languages Michael Hohensee
- In-Game Languages Ben Greear
- In-Game Languages Michael Hohensee
- In-Game Languages Mik Clarke
- In-Game Languages Hans-Henrik Staerfeldt
- In-Game Languages David Bennett
- In-Game Languages Richard Woolcock
- In-Game Languages Hans-Henrik Staerfeldt
- In-Game Languages Caliban Tiresias Darklock
- In-Game Languages Hans-Henrik Staerfeldt
- In-Game Languages Andrew Ritchie
- In-Game Languages Matthew D. Fuller
- In-Game Languages adam@treyarch.com
- forward: consistency Ola Fosheim Grøstad
- Confined Gameworld Ling
- Confined Gameworld Caliban Tiresias Darklock
- Confined Gameworld Richard Woolcock
- Confined Gameworld Eli Stevens {KiZurich}
- Confined Gameworld The Wildman
- Confined Gameworld Koster, Raph
- User centered? Ola Fosheim Grøstad
- User centered? Caliban Tiresias Darklock
- User centered? Marc Bowden
- User centered? Adam Wiggins
- User centered? Richard Woolcock
- User centered? Benjamin D. Wiechel
- User centered? Koster, Raph
- target audience Matthew Mihaly
- target audience Caliban Tiresias Darklock
- target audience Marc Bowden
- Fw: Self-organizing worlds (was: Elder Games) Kylotan
- Fw: Self-organizing worlds (was: Elder Games) Matthew Mihaly
- ScryMUD 1.8.11 released. Ben Greear
- Mud driver architecture info B. Scott Boding
- Blending graphics with text u1391470
- Blending graphics with text Laurel Fan
- Blending graphics with text Kylotan
- Blending graphics with text Chris Gray
- Blending graphics with text J C Lawrence
- Blending graphics with text Caliban Tiresias Darklock
- Blending graphics with text Chris Gray
- Blending graphics with text Ola Fosheim Grøstad
- Blending graphics with text Hans-Henrik Staerfeldt
- Blending graphics with text Mik Clarke
- Blending graphics with text u1391470
- Blending graphics with text claw@kanga.nu
- Blending graphics with text Alex Stewart
- Blending graphics with text J C Lawrence
- Virtual machine design Shane King
- Virtual machine design Alex Stewart
- Virtual machine design Jo Dillon
- Virtual machine design Ben Greear
- Virtual machine design Niklas Elmqvist
- Virtual machine design Shane King
- Virtual machine design Ben Greear
- Virtual machine design claw@kanga.nu
- Virtual machine design Alex Stewart
- Virtual machine design Felix A. Croes
- Virtual machine design Eli Stevens {KiZurich}
- Virtual machine design Mik Clarke
- Virtual machine design Schubert, Damion
- Virtual machine design Ben Greear
- Virtual machine design Ben Greear
- Virtual machine design Felix A. Croes
Ben Greear <greear@cyberhighway.net> wrote:
> "Felix A. Croes" wrote:
>
>[...]
> > Lacking in power: may be true for some languages, but not necessarily
> > for all of them. Some are powerful enough that you cannot just write
> > muds in them, but any sort of internet server.
>
> Yep, but once you reach this stage, I think the benefits of a more
> standard language (c/c++/java/whatever) outweigh a proprietary language
> that you write. That doesn't mean that you couldn't write a perfectly good
> language for this sort of thing, but more that the effort you put into
> it may not be justified, compared to what you can do with an already
> written language/compiler/profiler.
It depends on how much importance you assign to the respective
benefits. If the benefit of code that cannot crash your
server outweighs the advantages of C and C++, then C and C++
won't do. If the benefit of multiple inheritance outweighs the
advantages of Java, then Java won't do.
It is of course possible to appropriate an existing language,
including compiler and profiler, for your mud server.
Suppose that, instead of developing your mud server from scratch,
you take one of the already existing ones and write your mud in
the server programming language. Now your whole efford to gain
the advantages offered by this language is reduced to learning it --
a few hours, assuming that the language is sufficiently like
programming languages that you already know. Right?
>[...]
> > - Programmers cannot crash the mud. Nothing as silly as dereferencing
> > a NULL pointer is possible.
>
> So your internal language has no pointers? I guess you could just
> crash the individual 'programlets' instead of your entire server
> if desired. (By crash I mean abort abruptly, as the programmer
> probably did not want it to happen.)
What if a programlet in C++ decides to trash data at a random memory
location?
> > - Any change can be made without taking the mud down, and takes effect
> > immediately. If necessary, it can also be instantly undone. A well-
> > run mud doesn't have to reboot. This is particularly interesting
> > for commercial muds, where downtime means loss of revenue and/or
> > customer dissatisfaction.
>
> I wonder if commercial muds would do *any* development on production
> servers. If your language is powerful enough to affect the game play,
> then it's definately powerful enough to affect it negatively!
Not development, upgrading. And yes, commercial muds do this all
the time.
During the time that I played UO, the mud (and simultaneously, the
client) were upgraded several times. At least one of these changes
was later rolled back when it turned out that the effect was not
quite as desired. This was around the time that the new reputation
system was introduced. All of the changes involved server reboots.
> It would be much safer to have multiple copies of the servers, one to
> develop on, and the other to host normal players on.
UO indeed has a separate development/test site. Sometimes, a problem
will remain unnoticed until the code is run on a real mud :)
> > - The mud can be made enormously complex without affecting the
> > complexity and reliability of the basic server, which can in fact
> > be smaller and simpler than what would be needed for even a
> > medium-sized mud without internal programming language.
>
> This implies an enormously complex set of internal programs, which I
> would imagine would be just as hard to maintain as the normal server
> code, perhaps more-so because you also have compilers to deal with, and
> a non-standard language that your programmers must become proficient at.
It would be very much easier, considering that the code is written
in a high-level language. Additionally, only the actual server
code could contain bugs that seriously affect the stability of the
mud, i.e. that cause the mud to crash or would require a reboot to
fix.
Regards,
Felix Croes - Virtual machine design Matthew Mihaly
- Virtual machine design Hans-Henrik Staerfeldt
- Virtual machine design Felix A. Croes
- Virtual machine design claw@kanga.nu
- Virtual machine design Mik Clarke
- Virtual machine design Oliver Jowett
- Virtual machine design Chris Gray
- Virtual machine design claw@kanga.nu
- Virtual machine design Chris Gray
- Virtual machine design Ola Fosheim Grøstad
- Virtual machine design claw@kanga.nu
- Virtual machine design Petri Virkkula
- Virtual machine design Ben Greear
- Virtual machine design Chris Gray
- Virtual machine design Ola Fosheim Grøstad
- Virtual machine design Nathan F Yospe
- Virtual machine design Ola Fosheim Grøstad
- Virtual machine design Petri Virkkula
- Virtual machine design Jon A. Lambert
- Virtual machine design Koster, Raph
- Virtual machine design Jon A. Lambert
- Virtual machine design Chris Gray
- Rebooting (was: Virtual machine design) Eli Stevens {KiZurich}
- Game design highpoints (was Virtual machine design) claw@kanga.nu
- Sockets Quzah [softhome]
- ScryMUD 1.8.13 snapshot released. Ben Greear
- Interview I did that may interest you Koster, Raph
- Censorship Greg Munt
- Censorship Ben Greear
- Censorship Matthew Mihaly
- Censorship Shawn Halpenny
- Censorship Darren Henderson
- Censorship Quzah [softhome]
- Censorship Hans-Henrik Staerfeldt
- Python B. Scott Boding
- Python Gaffney, Jeremy
- AW: Censorship Hofbauer Heinz
- AW: Censorship Matthew Mihaly
- AW: Censorship Damion Schubert
- Censorship, Virtual v Artificial Worlds, Python Greg Munt
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Ben Greear
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Ben Greear
- Censorship, Virtual v Artificial Worlds, Python Dan
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Marian Griffith
- Censorship, Virtual v Artificial Worlds, Python Benjamin D. Wiechel
- Censorship & Its Impact On World Immersion Greg Munt
- Censorship & Its Impact On World Immersion Matthew Mihaly