michael at sparta.mainstream.net
Tue Apr 1 09:47:55 New Zealand Daylight Time 1997
On Mon, 31 Mar 1997 claw at null.net wrote:
> On 29/03/97 at 09:10 AM, Michael Hohensee
> <michael at sparta.mainstream.net> said:
> > After diddling around with C for half a year, I started to write
> >what I call AeMud. The acronym stands for Arbitrarily Expandable
> >MUD. And, as you may have guessed, the idea was to make it so that
> >new things would be easy to add.
> I've not actually assigned a name to my server. Way back in the dawns
> of time it was named the "Black Hat MUD Server" due to my penchant for
> fedoras, but that only lasted for the first couple weeks of
> development. Since then it was called "Murkle" for all of about a
> week, and then nothing. I guess I ought to name it some day.
Well, I was going to call it "MyMud" for a while, but then I found that
name was already taken. I used the name AeMud as a guide to my coding.
Everthing has to work with everything else. That's caused a few total
> > A way of treating all objects (players, creatures, rooms, etc) as
> >if they were the same for certain common uses. (common-use being
> >defined as anything you want everyone to be able to do.)
> Hehn. I actually make no distinction among players, mobiles, rooms,
> objects, utility objects, etc. There are just no unique object types.
> They're all the same to the server.
Doesn't that waste memory? I did that for a while, but I couldn't see
why a jar needed to have a sex value... I solved it by using a two-level
memory structure, like this:
std_info contains data that everything needs to have, and spec_info is
type specific. The data in spec_info is rarely accessed, and checks are
always made as to the type of the object (stored in std_info) before an
attempt to access it is made.
> > Some of the cute things I've done with it are to make some really
> >interactive portals, and liquids that spill out of containers.
> How do you handle your liquids? I have liquids which just do ajacent
> space counts ala "There are X units of liquid here, and Y units over
> there, to even things out X-Y/2 need to move..." etc. This often
> resulted in one unit ripples, but was prerty tame for handling
> stream-type flows.
I treat liquids as independant objects. I've got an update pulse
(modeled after dikumud pulses) that will have the liquid check to see if
it is in a watertight container. If it isn't, some of it "leaks" out.
The liquid object has an "amount" variable, and this is decreased when
some leaves the container. I've also got one function for moving things
around, and it checks to see if the liquid has all been spilled (move
whole object to outer container) and checks to see if there is a liquid
of similar type in the outer container (sum the amount variables, and
recycle one object.)
One thing I had to watch out for was having a liquid leak out of a room
that wasn't carried by anything else. That path leads to memory-holes. :)
> J C Lawrence Internet: claw at null.net
More information about the MUD-Dev