<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: MUD Development Digest -->
<!--X-From-R13: "Re. Qng" <pngNotn.pbz> -->
<!--X-Date: Fri, 27 Apr 1998 20:45:31 -0700 -->
<!--X-Message-Id: 199804280344.WAA07021#zoom,bga.com -->
<!--X-Content-Type: text -->
<!--X-Reference: 000101bd71b2$0b049910$243939cc#foghorn,toon.org -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: MUD Development Digest</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cat#bga,com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00785.html">Previous</a>
| <a href="msg00789.html">Next</a>
]
Thread:
[ <a href="msg00766.html">Previous</a>
| <a href="msg00283.html">Next</a>
]
Index:
[ <A HREF="author.html#00788">Author</A>
| <A HREF="#00788">Date</A>
| <A HREF="thread.html#00788">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: MUD Development Digest</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: MUD Development Digest</LI>
<LI><em>From</em>: "Dr. Cat" <<A HREF="mailto:cat#bga,com">cat#bga,com</A>></LI>
<LI><em>Date</em>: Mon, 27 Apr 1998 22:44:46 -0500 (CDT)</LI>
<LI><em>Delivery-date</em>: Fri Apr 27 20:45:32 1998</LI>
<LI><em>Delivery-date</em>: Fri, 27 Apr 1998 20:45:32 -0700</LI>
<LI><em>Envelope-to</em>: claw#kanga,nu</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent,,,," <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
> 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:
*-------------------------------------------** <A HREF="http://www.bga.com/furcadia">http://www.bga.com/furcadia</A>
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------*
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00283" HREF="msg00283.html">[MUD-Dev] Re: MUD Development Digest</A></strong>
<ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00766" HREF="msg00766.html">[MUD-Dev] Re: MUD Development Digest</A></STRONG>
<UL><LI><EM>From:</EM> "Justin McKinnerney" <xymox#toon,org></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00785.html">[MUD-Dev] Re: Java for Mud Client (Crossfire MUD topic)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00789.html">[MUD-Dev] Re: Group mechanics/Leadership [was: Room descriptions]</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00766.html">[MUD-Dev] Re: MUD Development Digest</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00283.html">[MUD-Dev] Re: MUD Development Digest</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00788"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00788"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: MUD Development Digest</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00533" HREF="msg00533.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Fri 24 Apr 1998, 05:51 GMT
</LI>
<LI><strong><A NAME="00544" HREF="msg00544.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
Justin McKinnerney <a href="mailto:xymox#toon,org">xymox#toon,org</a>, Fri 24 Apr 1998, 05:55 GMT
<UL>
<LI><strong><A NAME="00631" HREF="msg00631.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Fri 24 Apr 1998, 22:31 GMT
<UL>
<LI><strong><A NAME="00766" HREF="msg00766.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
Justin McKinnerney <a href="mailto:xymox#toon,org">xymox#toon,org</a>, Mon 27 Apr 1998, 07:59 GMT
<UL>
<LI><strong><A NAME="00788" HREF="msg00788.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Tue 28 Apr 1998, 03:45 GMT
<UL>
<LI><strong><A NAME="00283" HREF="msg00283.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 30 Apr 1998, 21:26 GMT
<UL>
<LI><strong><A NAME="00286" HREF="msg00286.html">[MUD-Dev] Re: MUD Development Digest</A></strong>,
Matt Chatterley <a href="mailto:matt#mpc,dyn.ml.org">matt#mpc,dyn.ml.org</a>, Thu 30 Apr 1998, 23:01 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
</ul>
</LI>
<LI><strong><A NAME="00036" HREF="msg00036.html">[MUD-Dev] GRUPMS?</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Mon 06 Apr 1998, 04:58 GMT
<LI><strong><A NAME="00031" HREF="msg00031.html">Re: [MUD-Dev] caved in: Algorithms for for storing free space.</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 05 Apr 1998, 18:39 GMT
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
