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
"Felix A. Croes" wrote:
>
> Ben Greear <greear@cyberhighway.net> wrote:
>
> What constitutes a "real" programming language? My guess is that you
> consider internal programming languages too slow and not powerful
> enough.
Speed doesn't really bother me, unless it's attrocious. I'm more
concerned
with the power of the language. To me a real language is anything that
has
variables and conditional branches. I believe to use such a language,
you
need a decent understanding of logic flow and programming. I don't
think
this is readily found in the general gaming populous.
> 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.
>
> "Common users can't program in any real language": did you just grant
> internal programming languages the status of "real language"? Or do
> you mean that since internal programming languages are not "real", it
> is possible that common users may be able to program in them?
Oh, I absolutely think there are many people on this list and elsewhere
that can write a relatively complete 'real' language for their game. I
just don't think it's worth it! I am *not* convinced that common users
will ever be able to use them (well?).
> While a lot of users who attempt mud programming never master the
> basic principles, it is be surprising to see how much they can
> accomplish even so. Anyone can make rooms and monsters, which may
> have predefined behaviours implemented by more capable programmers.
That is why I see a more simple scripting language as more appropriate.
Let the real programmers program in a normal language, and let those
that can or want to script use the methods/commands available to them.
> However, those who stand to gain the most from an internal programming
> language are not the commot users -- who may never see any code,
> depending on the type of mud -- but the expert programmers, because
> of the boost in productivity obtained by writing in a high-level
> language.
That is a good point, and I agree.
> - 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.)
> - 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!
It would be much safer to have multiple copies of the servers, one to
develop on, and the other to host normal players on.
> - 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.
>
> Regards,
> Felix Croes
--
Ben Greear (greear@cyberhighway.net) http://www.primenet.com/~greear
Author of ScryMUD: mud.primenet.com 4444 (Released under GPL)
http://www.primenet.com/~greear/ScryMUD/scry.html - Virtual machine design Felix A. Croes
- Virtual machine design Matthew Mihaly
- Virtual machine design Hans-Henrik Staerfeldt
- 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