[MUD-Dev] Re: MUD Development Digest

[Dr. Cat]

> You could always run without swap under Linux and (I believe) Solaris.
> 
> While this raises a lot of red flags - if you are the only person running on
> the system, and you are pretty sure that the only real process on the system
> is your game server (no sendmail, no ftp, etc), then go for it.

Well, for a commercial game server, I can't imagine why I'd want to let 
other people run on the system, or run any major processes other than the 
game.  Of course I understand that in most of the mud development world 
things are different, with servers often running on Unix machines at 
universities that are used for all manner of other things at the same 
time.  The fact that I'm from another planet and speak a different 
language is probably why I don't participate in discussions about mud 
development too often, I just go and do it.  :X)

Anyway I'd prefer to be telling a system "Don't swap unless most or all 
of the physical RAM is used up", just in case some unexpected situation 
turns up, or I'm running near the edge and might need to swap a little.  
Rather than telling it "Don't ever swap, I'd rather have things explode 
horribly if you run out of RAM".

> It is very easy to start a project with your mentality, and then deal with
> issues as you run into them. This approach is not uncommon when it comes to
> multi-user games in general.
> 
> However, to start a project and say "I want >this< to be possible" is to set
> your limits. If you plan on supporting up to 100,000 players, do the math,
> figure out what your game would be like if that happened, figure out every
> worst case scenario. Then ask yourself if your code is truly up to it.

The intention from before the day I wrote the first line of code was to 
say "We've gotten 100 on at once, let's go for 1000".  "We've gotten 
1000, let's for 10,000".  Always adding zeroes each time, even up to 
"We've gotten a million, let's go for ten million".

The only server component with any sort of "deal with it as it arises" 
mentality is the central process, which is designed to not be a critical 
part of the game anyway.  It will need to evolve from a process to a 
group of processes that distribute the load between them, if we get 
REALLY huge.  But if the interface the other server processes talk to 
stays the same, they don't need to change.  I think they could remain 
about like they are indefinitely, presuming I cap the maximum number of 
users on a map at around 500 or so.

I do have some general ideas about how the central process group will 
evolve.  But I don't think it's appropriate to spec it all out now.  A 
simpler, easier to implement design than the final form will take us up 
into the thousands, and brings the "first day when people can actually 
play" (and when I can potentially bring in money) closer to the present.
I'm likely to be able to design the next revisions better with more time 
and experience, and also likely to have more money to spend expanding the 
programming team beyond one so I don't have to do it all myself.

I'm not really too worried if the central logic falls behind the demand 
curve for a few days, weeks, or even months, either.  It'll mean things 
like a 30 second wait for your buddy list to come up.  Walking, talking, 
picking up objects and using them, etc. will still perform quickly and 
responsively.

There is the issue that revenues could be dependent on your central 
chokepoint, and on it not getting too clogged up to measure and record 
all activity and make sure you get your ad revenues for us.  But I'm not 
building that technology, I'm going to use the stuff from TimeSink (my 
last "day job" also, by the way).  Their advertisement 
enabling/tracking/billing stuff is described at www.timesink.com.  And 
with the technical background those guys have, I think they've proved 
they know how to build scalable systems that can handle huge loads.

Anyway I still feel I'm on a path that's reasonably clear, although new 
details are always becoming apparent to me.  The same path I've been on 
since I had the initial inspiration, many years ago.  And ultimately I 
know I want to stick with RAM, which just sits there and doesn't have to 
spin around, rather than disk drives, which have to spin around.  Things 
that have to move physical components just have a hard time acheiving the 
same theoretical maximum speed as things that don't have to.

> Bytecode could easily be dubbed a "fancy" proceedure. Why do it? Simply
> put - Extendability. I want to be able to change fundamental game concepts
> in areas as I wish, on the fly, and without rebooting the game.

I suppose you'd call my language "bytecode", though I might use the term 
"tokenized interpreter" or something instead.  I don't care much whether 
I have to reboot the game to change stuff.  But it's crucial for players 
to be able to change the game, and a tokenized interpreter was just the 
right match for my goals for the language I give them in every way.

It's actually in many ways the feature I'm proudest of, both in design 
and in implementation.  And possibly the most innovative and interesting 
to this list.  But I hate to spend the time describing everything about 
it - and sadly I lost one of my design specs last year when my OS died, 
and I'm going to have to redesign what I lost from scratch.  Anyway only 
around 15% of the language is done, and I'd hate to spend hours and hours 
shooting my mouth off lecturing about it instead of implementing the 
other 85% and the fancy visual editor and stuff.

What the goals are, though, I think it achieves very well.  Easy and 
non-intimidating for non-programmers (the majority of the human 
population, in case anyone forgot!)  I never use the words "programming", 
"program", or "programming language" ever.  It's all "scripting".
Impossible to violate security with.  Impossible to write an endless loop 
or a script that crashes.  Minimal use of bandwidth necessary for the 
server to keep the clients up to date with effects caused by script 
execution.  Server CPU usage by most scripts fairly insignificant.  And 
lastly, a very close mapping between "the kinds of things most people 
want to make scripts do", and what the primitives of the language are.

I'm pretty impressed with what people have done with the scripting 
already, even though it's missing such critical features as "variables", 
"math", and relative coordinates.  It was amazing that one of them got a 
complete Mastermind game working - an excercise in masochism if you 
ask me!  Anyway it's in a pretty primitive state now, but I think when 
it's fully realized it's going to be something pretty special.  And 
people will probably get quite addicted to it.  Having a rapid, 
convenient trial-and-error cycle, with no bad crashes possible and the 
feedback of seeing your scripts work presented in the form of appealing 
sounds and visuals...  It's a pretty tempting combination.

Anyway the interpreter may have a few fancy or clever algorithmic 
structures in it, but they please me because I invented them myself.  And 
the underlying data structures are all nice, clean fixed-size arrays!  
Still, I don't mind using "fancy coding" when it's the only way to 
acheive a certain goal.  I can't imagine any other way I could have 
implemented my scripting language that would have fulfilled all of my 
goals for it.  But the basic map server functionality just doesn't 
require any fancy techniques at all, unless there's some need to run it 
in a resource-poor environment.  About the only fancy thing in there is 
the stuff that tracks who is in interaction-range with whom, to minimize 
n-squared overhead issues.  Even that code has one major optimization 
that's still just in my head and not implemented, because we haven't yet 
had enough overhead to need to improve the performance of that routine.  
I know how it will be done if the time comes when it's needed, and I can 
code it in a couple of hours if need be, and none of the other code that 
talks to it will need to change.  But until it's needed, there's no point 
in wasting time coding it.

> If you possess the ability/time/resources to, it never hurts to shoot for a
> goal that is beoynd what you think will actually happen. Because if it does
> happen, everyone involved will be happy you did, and guarenteed, someone
> will be unhappy that you didn't make your goals *higher*! :)

My goals are to have the largest and most successful game in history, to 
bring all mankind closer together, put an end to all war, and make enough 
money to be considered the Bill Gates of the online gaming industry (or 
maybe the Walt Disney - less people hate him.)  If I only achieve some 
small percentage of that, then it's ok too.

Unlike most people who set lofty goals, though, I feel it's essential to 
take a pragmatic approach, where you build towards them in steps, where 
each step is accomplishable on its own, and is something that could 
serve as the end result and be viable, respectable, and profitable if it 
happens to be the last step you get to, rather than one more along the way.
I worked for Origin for many years, where "bite off more than you can 
chew" was always a core element of the design philosophy.  Games like 
Ultima VI had elements, like the weights of objects, that just didn't 
contribute anything significant to making the game fun, and had a lot of 
game mechanics that didn't harmonize well together, the combat and 
economic elements weren't carefully balanced, etc.  The game was 
extremely ambitious, so it never got fine-tuned.  Compare it with 
something like Civilization by Sid Meier - a game design with hardly a 
single hair out of place, anywhere!

To actually achieve an ambitious future plan, you need to think HARD 
about what features you're going to have on that single next step, and 
how to do them.  And think a bit vaguely and abstractly about what you're 
going to do in all the future steps, so you don't sabotage your future 
progress.  But you mustn't tie yourself up with thinking in TOO much 
detail about them, and certainly not in implementing much (if any) of 
their stuff, or you'll simply never climp up that first one step from the 
ground at all.

I'm abnout half a step off the ground right now, and I kind of like 
it...  But I really need to quit talking so much and get up all the way 
on top of that first step.  :X)

*-------------------------------------------**-----------------------------* 
   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.