What do you think of Introductions?
David W Serhienko
I have been considering how I would implement a system on a mud ala
Genesis (and others) wherein players do not see the name of other
player's until they have been 'introduce'd to each other.
I know how I would do it, and I think I have an elegant solution, if I
decide to do it, but I wondered what people who have played on these
muds think of such a system?
What does it add, in your opinion, to gameplay? What roleplaying
implications have you noticed? How about the social sphere? Does it
improve or suffer?
Thanks for any thoughts you might have to share,
Tigycho
Richard Woolcock
Well as someone who has implemented this code, I have noticed a definate
improvement in roleplaying on my mud (although admittedly I added a number
of other roleplaying encouragements at the same time). It does also add a
certain level of anonymity to the mud as well, which means you have to
actually go and meet people formally.
One of the more interesting aspects I noticed was players reactions to
appearance - before you know someones name, you see a very simple short
description comprising of age and appearance (an ugly teenage boy, a
handsome elderly gentleman, a beautiful young woman, etc). Thus people
would start getting addressed as 'Hey, ugly', or 'Who are you, old man?'
- and an 'beautiful young women' would immediately get a lot of attention
from the mainly-male playerbase. This was a side-affect I hadn't even
considered while writing the code.
As far as the implementation goes...there are many different ways to do
it. How will you store the data (one file per player per player? one
file per player? one huge file? part of some other file?), how will you
access the data (linked/double linked lists? a binary sorted tree? some
other way?), what about the introduction itself - do you 'intro <target>',
or - the more realistic way - intro to everyone in the room (mine makes it
look like a 'say'). Do you have to give your real name, or can you make
one up? Does it cater for people who want to only give their first name
or last name rather than both names (assuming you have multiple names)?
Is the recognition binary, or can you know some people better than others
(and thus see through their disguises better, or recognise them later in
life)? Is there a limit to the number of people you can know, and can
you forget people? Will you be using the recognition code for anything
else as well (ie information known about a particular person)? Will voice
recognition be seperate from appearance recognition? What about other
senses such as smell, touch, etc? ("Hey, I recognise that perfume...")...
What about the ability to change your appearance, thus fooling other people
(unless they know you really well), perhaps even disguising yourself as
another player? What about mistaken identities?
You see, player-recognition is a very simple feature to add, but it is one
with many, many possibilities, and can be as complicated as you are willing
to make it.
KaVir.
Scatter ///oo/\)
In <34D66A...@hotmail.com>, David W Serhienko <tig...@hotmail.com> writes:
>I have been considering how I would implement a system on a mud ala
>Genesis (and others) wherein players do not see the name of other
>player's until they have been 'introduce'd to each other.
>
>I know how I would do it, and I think I have an elegant solution, if I
>decide to do it, but I wondered what people who have played on these
>muds think of such a system?
>
>What does it add, in your opinion, to gameplay? What roleplaying
>implications have you noticed? How about the social sphere? Does it
>improve or suffer?
I've only ever played one mud that did this. It was a very AD&D based
role-play mud but I can't remember the name of the place. I didn't stay
there very long because it seemed that the lack of names effectively
hid people from you. You walk into a room and see "an elven man is here" -
is he an npc or a player? Do you wander around saying hello to every single
thing you meet on the off chance that it is a player? I found you very
quickly assume that everyone is an npc unless they say something to
indicate otherwise. Once most people are making that assumption there is
very little interaction between new people and established players. New
players get the impression that there's an established group of friends
that they are excluded from etc.
I guess it depends on what goals you have in mind. If you are building a mud
where your primary concern is realism and role-play then this can help you
achieve it. But I think it is detrimental to the social side of the mud.
--
Scatter
///\oo/\\\
John Freese
David W Serhienko wrote:
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
>
> I know how I would do it, and I think I have an elegant solution, if I
> decide to do it, but I wondered what people who have played on these
> muds think of such a system?
>
> What does it add, in your opinion, to gameplay? What roleplaying
> implications have you noticed? How about the social sphere? Does it
> improve or suffer?
>
the idea of that sounds great, however, you also have to think of all
the data you would need to store as players introduce themselves to each
other. Provided that you have a small player base, it wouldn't be such a
bad idea, however, if you have a large player base such as a mud like
duris, toril, medivia, rights of passage, mume and others. then you would
have a problem on your hands. :) I haven't played on a mud like that yet,
but the idea does sound neat.
-------------------------------------- - --- -- -
John Freese (van...@mediaone.net)
Play Duris: Land of BloodLust (duris.org 6666)
---------------------------------------- - --- -- -
Lars Duning
Scatter ///oo/\) wrote:
>
> In <34D66A...@hotmail.com>, David W Serhienko <tig...@hotmail.com> writes:
> >Genesis (and others) wherein players do not see the name of other
> >player's until they have been 'introduce'd to each other.
> I've only ever played one mud that did this. It was a very AD&D based
> role-play mud but I can't remember the name of the place. I didn't stay
> there very long because it seemed that the lack of names effectively
> hid people from you. You walk into a room and see "an elven man is here" -
> is he an npc or a player? Do you wander around saying hello to every single
> thing you meet on the off chance that it is a player? I found you very
> quickly assume that everyone is an npc unless they say something to
> indicate otherwise. Once most people are making that assumption there is
> very little interaction between new people and established players. New
> players get the impression that there's an established group of friends
> that they are excluded from etc.
>
> I guess it depends on what goals you have in mind. If you are building a mud
> where your primary concern is realism and role-play then this can help you
> achieve it. But I think it is detrimental to the social side of the mud.
Personally I'd implement introduction only halfway, allowing players to see
all other players in the who, and also allow tells (and channels) to
non-introduced players.
But in any case you need a large playerbase, else lonely players will introduce
themselves to anything in sight, just in case, which is not the intention either.
--
Lars Duening; la...@cableinet.co.uk (Home)
A. Eschenburg
David W Serhienko wrote:
>
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
>
> decide to do it, but I wondered what people who have played on these
> muds think of such a system?
>
> What does it add, in your opinion, to gameplay? What roleplaying
> implications have you noticed? How about the social sphere? Does it
> improve or suffer?
>
> Tigycho
Hello,
i have been playing on a mud with such a system for some time, and
now that i started playing another one, i miss it. Keeping track of
whom you remember or not is something which adds a lot of
opportunities if done right. There are a few things to watch out for,
though.
The main problem of the system actually is the question how to
determine who is remembered. Logic would suggest a limited size
for this. Which opens up a whole bag of things to consider.
But in the end, it is well worth the trouble, and does add a lot
to Roleplay and atmosphere of a mud, at least in my eyes.
Axel
Alan Schwartz
>Genesis (and others) wherein players do not see the name of other
>player's until they have been 'introduce'd to each other.
>
>implications have you noticed? How about the social sphere? Does it
>improve or suffer?
One neat thing that an introductions system makes possible is
simulating "amnesia" (from drinking from that sacred spring, via
a spell, etc.) in a meaningful way -- you no longer recognize your
associates or remember their names!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Alan Schwartz
Paul@DuneMUSH | dune...@pennmush.org
Javelin@Belgariad, and elsewhere | PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
PennMUSH Source: ftp://ftp.pennmush.org/pub/PennMUSH/Source
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Space Girl
David W Serhienko wrote:
> I have been considering how I would implement a system on a mud ala
> Genesis (and others) wherein players do not see the name of other
> player's until they have been 'introduce'd to each other.
>
> I know how I would do it, and I think I have an elegant solution, if I
> decide to do it, but I wondered what people who have played on these
> muds think of such a system?
>
> What does it add, in your opinion, to gameplay? What roleplaying
> implications have you noticed? How about the social sphere? Does it
> improve or suffer?
>
> Thanks for any thoughts you might have to share,
> Tigycho
I've played on two muds so far that use longdesc systems.. Enjoy them
both quite a lot. On one, my char is very outgoing and vivacious, and
goes out of her way to make friends. On the other, my char is a lot
quieter, and doesn't know many people, consequently. But it's like RL, ya
know.. I know lots of people by face and talk to them on a daily basis
and haven't a clue what their names are. It doesn't bother me, to be
honest. It rattled me a lot at first but now it's quite natural to me.
I agree about the amnesia comment.. hilarious, I love that.
I don't see how it'd alienate newbies. I was a newbie to it too and it
didn't seem too hard to deal with. And on the other mud I play that uses
this system, I got snapped into the action fairly quickly.
Space Girl, mhm9x5
Herding Cats My Specialty
Holly Sommer
David W Serhienko wrote:
: I have been considering how I would implement a system on a mud ala
: Genesis (and others) wherein players do not see the name of other
: player's until they have been 'introduce'd to each other.
A possible way...
Include two fields in your playerfiles:
int pnumber;
char *introduced; /* or int introduced[MAX_PLAYERS] */
For each new player saved, that pfile gets the next available pnumber.
When someone decides to introduce themself, it flips a bit in
that players' pnumber position on the other players' indroduced[].
To illustrate:
Newman, a grey kender, has a pnumber of 341.
Shaendra, a willowy half-elf, has a pnumber of 200.
Newman introduces herself like this:
Introduce me halfelf.
Shaendra's introduced[199] is set to 1 (true).
Or, instead of a 1/0, you could put a number in there which could be
like a "memory" length. When first introduced,
shaendra->introduced[199] = 100;
This number decreases every MUD hour, unless she sees Newman again,
and then it goes up by 5... or perhaps grouping with Newman increases
it by 25 or something like that.
You'd just have to up the MAX_PLAYERS every so often, and change
pnumber to type long, as you get more saved pfiles
-Holly
Richard Woolcock
Holly Sommer wrote:
>
> David W Serhienko wrote:
>
> : I have been considering how I would implement a system on a mud ala
> : Genesis (and others) wherein players do not see the name of other
> : player's until they have been 'introduce'd to each other.
>
> A possible way...
>
> Include two fields in your playerfiles:
> int pnumber;
> char *introduced; /* or int introduced[MAX_PLAYERS] */
>
> For each new player saved, that pfile gets the next available pnumber.
> When someone decides to introduce themself, it flips a bit in
> that players' pnumber position on the other players' indroduced[].
>
> You'd just have to up the MAX_PLAYERS every so often, and change
> pnumber to type long, as you get more saved pfiles
Ack! Sorry, but that is really horrible - if you had even 1000 players then
that would require an array at least 1000 big PER pfile. Even if you only
stored people you knew, eg:
#MET 1 20 (Met player number 1, counter of 20).
#MET 5 30 (Met player number 5, counter of 30).
It would still get pretty silly - and in addition you would have to update
the MAX_PLAYERS (and recompile all the code) every time you wanted to change
the pfile limit.
The only reasonable way to do it is via a double linked list or a binary
sorted tree (the former is probably the best in this situation).
Note that this follows the merc ascii-style saving - I am unfamiliar
with the method that lp muds use, but I'm sure they would have a similar
problem.
KaVir.
George Reese
You could also do it as a mapping instead of as an array. Though I am
not recommending such an approach or disavowing it. I have not put
any thought into this issue :)
In rec.games.mud.lp Richard Woolcock <Ka...@dial.pipex.comNOSPAM> wrote:
: KaVir.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
Matt Chatterley
On Sun, 8 Feb 1998, George Reese wrote:
> You could also do it as a mapping instead of as an array. Though I am
> not recommending such an approach or disavowing it. I have not put
> any thought into this issue :)
As George, I'm speaking without really thinking about this, just a random
idea - perhaps this could be approached with hash table stored somewhere
central by the mud, so that data is cross-referenced (a cross-linked list
of some sort), letting it tell who knows who, and how well, rather than
storing the data from an individual perspective (which as Richard pointed
out, is a LOT of data).
--
Regards,
-Matt Chatterley
"Every breath you take, every bond you break.. I'll be watching you."
-The Police
John Viega
In article <34DE72...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
> Holly Sommer wrote:
> >
> > David W Serhienko wrote:
> >
> > : I have been considering how I would implement a system on a mud ala
> > : Genesis (and others) wherein players do not see the name of other
> > : player's until they have been 'introduce'd to each other.
> >
> > A possible way...
> >
> > Include two fields in your playerfiles:
> > int pnumber;
> > char *introduced; /* or int introduced[MAX_PLAYERS] */
> >
> > For each new player saved, that pfile gets the next available pnumber.
> > When someone decides to introduce themself, it flips a bit in
> > that players' pnumber position on the other players' indroduced[].
> > [snip]
> >
> > You'd just have to up the MAX_PLAYERS every so often, and change
> > pnumber to type long, as you get more saved pfiles
>
> Ack! Sorry, but that is really horrible - if you had even 1000 players then
> that would require an array at least 1000 big PER pfile. Even if you only
> stored people you knew, eg:
Welll, this isn't horrible at all under the assumtion that players
introduce themselves to a _lot_ of people. Looking up a bit in a bit
vector based on an index is very fast (O(1) w/ a low constant). Of
course, that probably isn't a _great assumption, but nonetheless, I
think "really horrible" is too harsh. In your example, you'd be
storing on disk 125 bytes per player, which over 1000 players would be
about 120K. As your mud gets larger, That's not bad if you've got a
fair bit of disk space devoted to the mud, since most of the info is
going to be on disk at any given time. You're not going to get too
much faster in terms of lookup time, that's for sure.
If the user is expected to meet only 1 in 100 players AND you have a
ton of players, then I'd probably switch to a mapping and store
player_number : do_i_know_you in each player. (In general, as your mud
gets to be of a significant size, this array is going to be full of a
*lot* of 0's, and so even though you're storing one bit per person,
you may be better off storing say 64 bits for each person you know
(mapping 2 32 bit ints together), and paying the of extra storage
overhead for keeping it in a mapping.
> The only reasonable way to do it is via a double linked list or a binary
> sorted tree (the former is probably the best in this situation).
Actually, I'd prefer the mapping, it's essentially O(1) to store and
look up. If you write your own dynamically resizing mapping code
specifically for this job in C, you could even compact the table, and
map 32 bits onto single bytes (or 1/2 bytes even). That would *more*
than offset the mapping overhead. The doubly linked list is going to
take O(n) time, where n is the number of players on your game. The
tree will be faster than the linked list (O(log n)), but both the tree
and the linked list will end up using more memory than the mapping as
your player base grows, since the doubly linked list you suggest would
require 96 bits per player on most machines, as would the tree. If
you drop to a singly linked list, you're still going to use 64 bits,
and have an unacceptable lookup time.
BTW, if you're _really_ into the bit per person method, you don't need
anything like a MAX_PLAYERS variable in LPC (or C if you're willing to
dynamically realloc), which I assume the original poster was refering
to, since this thread is crossposted in r.g.m.lp. Use the
set_bit()/test_bit()/clear_bit() functions.
John
----------------------------------------------------------------------------
|John Viega "The public at large tends to confuse the |
|vi...@list.org composing of a symphony with the writing of |
|http://list.org/~viega/ its score." |
|University of Virginia -- Edsger Dijkstra |
----------------------------------------------------------------------------
Richard Woolcock
John Viega wrote:
>
> In article <34DE72...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>
> > Holly Sommer wrote:
[snip]
> > > You'd just have to up the MAX_PLAYERS every so often, and change
> > > pnumber to type long, as you get more saved pfiles
> >
> > Ack! Sorry, but that is really horrible - if you had even 1000 players then
> > that would require an array at least 1000 big PER pfile. Even if you only
> > stored people you knew, eg:
>
> Welll, this isn't horrible at all under the assumtion that players
> introduce themselves to a _lot_ of people. Looking up a bit in a bit
> vector based on an index is very fast (O(1) w/ a low constant). Of
> course, that probably isn't a _great assumption, but nonetheless, I
> think "really horrible" is too harsh. In your example, you'd be
> storing on disk 125 bytes per player, which over 1000 players would be
> about 120K. As your mud gets larger, That's not bad if you've got a
> fair bit of disk space devoted to the mud, since most of the info is
If disk space became a problem I would use binary files. If you only
want to know if you know the person or not, then 4 bytes would easily
suffice per player per player (just store an id for the people you know).
If there were 1000 players, and everyone knew each other, that would
take up less than 4 meg of disk space.
Of course, you don't have to remember EVERY player...
> going to be on disk at any given time. You're not going to get too
> much faster in terms of lookup time, that's for sure.
The array would be faster for lookup - and if I only wanted one bit
per player I could always typedef a bit field. However the real problem
is that you are specifying how many players are allowed to exist (exist,
not just be online at once) and allocating space for each player^player!
> If the user is expected to meet only 1 in 100 players AND you have a
> ton of players, then I'd probably switch to a mapping and store
> player_number : do_i_know_you in each player. (In general, as your mud
> gets to be of a significant size, this array is going to be full of a
> *lot* of 0's, and so even though you're storing one bit per person,
> you may be better off storing say 64 bits for each person you know
> (mapping 2 32 bit ints together), and paying the of extra storage
> overhead for keeping it in a mapping.
Why not just use a single 32 bit integer? You could use the last bit to
represent if you knew them or not, and the rest of it to correspond to a
unique player id. Stored in a seperate binary file, this would take only
4 bytes of space per person you knew...
> > The only reasonable way to do it is via a double linked list or a binary
> > sorted tree (the former is probably the best in this situation).
>
> Actually, I'd prefer the mapping, it's essentially O(1) to store and
> look up. If you write your own dynamically resizing mapping code
Won't this cause memory fragmentation if people are being constantly added
and removed from memory?
> specifically for this job in C, you could even compact the table, and
> map 32 bits onto single bytes (or 1/2 bytes even). That would *more*
> than offset the mapping overhead. The doubly linked list is going to
> take O(n) time, where n is the number of players on your game. The
Nope - every time my code checks to see if you know someone, that person
is moved to the front of the list (thats why I use a double rather than a
single linked list). As you usually interact with a few players at a time,
the lookup time is pretty quick. This is why I used a list rather than a
tree.
> tree will be faster than the linked list (O(log n)), but both the tree
> and the linked list will end up using more memory than the mapping as
> your player base grows, since the doubly linked list you suggest would
You're assuming that I store in RAM everyone that everyone online knows.
I don't. I load them up as needed. You can't do this with a static
array (well you could, but there would be no advantage).
> require 96 bits per player on most machines, as would the tree. If
> you drop to a singly linked list, you're still going to use 64 bits,
> and have an unacceptable lookup time.
The lookup time is quite reasonable. I actually use 128 bits though,
because in addition to the 2 pointers and unique ID, I also use a long
int to store various things you know about that person.
> BTW, if you're _really_ into the bit per person method, you don't need
> anything like a MAX_PLAYERS variable in LPC (or C if you're willing to
> dynamically realloc), which I assume the original poster was refering
> to, since this thread is crossposted in r.g.m.lp. Use the
> set_bit()/test_bit()/clear_bit() functions.
The person I responded to was a diku owner, and I just followed the cross
post. I try to realloc as little as possible (my allocated recognition
blocks just get moved onto a 'free' list when people quit, ready to be
reused).
KaVir.
Holly Sommer
Richard Woolcock wrote:
: Ack! Sorry, but that is really horrible
Heh, well, it was just off the top of my head. I'm sure there are much
more efficient ways of doing it. I was just trying to illustrate that
there are quick-n-dirty means available. :)
-Holly
Katrina McClelan
In <34E11B...@dial.pipex.comNOSPAM> Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>Why not just use a single 32 bit integer? You could use the last bit to
>represent if you knew them or not, and the rest of it to correspond to a
>unique player id. Stored in a seperate binary file, this would take only
>4 bytes of space per person you knew...
Actually, you wouldn't need the sign bit if you're only storing who you
know (you could tell by having a record or not). If you're storing
everyone you need the sign bit, and 4 bytes per person in existance.
>Won't this cause memory fragmentation if people are being constantly added
>and removed from memory?
Yes, and no.... if you have a free_blah() function that collects unused
memory in a stack and a malloc_blah() that checks to see if you have a
block availible on that stack you tend to fill in the gaps.
>The person I responded to was a diku owner, and I just followed the cross
>post. I try to realloc as little as possible (my allocated recognition
>blocks just get moved onto a 'free' list when people quit, ready to be
>reused).
Heh... didn't realize you already use the same scheme I just mentioned :)
-Kat
Nathan Fenenga Yospe
Katrina McClelan, is it true that on 10 Feb 1998 15:29:53 -0600, you
posted to rec.games.mud.admin:
: In <34E11B...@dial.pipex.comNOSPAM> Richard Woolcock
<Ka...@dial.pipex.comNOSPAM> writes:
: >Why not just use a single 32 bit integer? You could use the last bit to
: >represent if you knew them or not, and the rest of it to correspond to a
: >unique player id. Stored in a seperate binary file, this would take only
: >4 bytes of space per person you knew...
: Actually, you wouldn't need the sign bit if you're only storing who you
: know (you could tell by having a record or not). If you're storing
: everyone you need the sign bit, and 4 bytes per person in existance.
Of course, this gets more interesting if you weight it by familiarity,
frequency, and freshness. By this, I mean the following: a time stamp,
specifying the last meeting, a frequency count, averaging how often an
occurance said meetings are (and weighted to the difference between t0
and t for said stamp, so as to account for a suddenly increased rate),
and a familiarity value, probably either specified by the player, with
an alternative (that I use) being the duration of meetings between the
two players, on average. This still fits in under 8 bytes apiece. That
is even better if the storage is client-side on a non-telnet mud. This
allows some other interesting possibilities:
Bubba is secretly dissatisfied with his gender. He has been dressing
as a woman and going by the name Buffy. Boffo hangs out in the Green
Marine, the same bar as Bubba, but doesn't really know him too well.
Boffo has a serious crush on Buffy, who he met at the poodle museum.
One night, Boffo ends up in a card game with Bubba. Suddenly, he has
a startling insight...
: >Won't this cause memory fragmentation if people are being constantly added
: >and removed from memory?
: Yes, and no.... if you have a free_blah() function that collects unused
: memory in a stack and a malloc_blah() that checks to see if you have a
: block availible on that stack you tend to fill in the gaps.
With a client side storage, this is more of a problem. How do you know
if someone has died? Would you want to delete them even if they had? I
expect you would still remark on similarities...
You stop, and your heart thuds hard. A woman with pale blue hair and
silver eyes peers up at you, her face exactly like that of your dead
wife Loena. She frowns and hands you a cup. "Fill this, please," she
instructs you. I second glance dispells her resemblance to Loena.
: >The person I responded to was a diku owner, and I just followed the cross
: >post. I try to realloc as little as possible (my allocated recognition
: >blocks just get moved onto a 'free' list when people quit, ready to be
: >reused).
: Heh... didn't realize you already use the same scheme I just mentioned :)
: -Kat
I do a lot of virtual allocation - use of space from a previously set,
page-sized block. I'm still playing around with other memory solutions
that don't result in so much unused allocated memory.
--
Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe#hawaii.edu nyospe#premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/
John Adelsberger
Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote regarding intro systems:
: If disk space became a problem I would use binary files. If you only
: want to know if you know the person or not, then 4 bytes would easily
: suffice per player per player (just store an id for the people you know).
: If there were 1000 players, and everyone knew each other, that would
: take up less than 4 meg of disk space.
Lets assume that I want to allow every player to have one of the set
<UNKNOWN, SEEN_BEFORE, FAMILIAR, FRIEND> each of which is represented
by an integer(a 4 byte quantity, herein) to represent his relation to
each and every other player. If there are 5000 players total, which
is more than any mud I'm familiar with, save commercial garbage, each
player then needs 4999 bytes of storage, plus one for the size of the
array or a null terminator, and you end up with 5000 x 5000 = 25 megs.
Frankly, 25 megs of disk is an hour's pay these days, or less. In
addition, this implementation was DELIBERATELY chosen to SUCK for
efficiency.
Writing in C seems to convince most people that EVERYTHING is an
efficiency concern. This is not true. Almost nothing in a mud
is an efficiency concern. Get over it.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
Richard Woolcock
John Adelsberger wrote:
>
> Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote regarding intro systems:
>
> : If disk space became a problem I would use binary files. If you only
> : want to know if you know the person or not, then 4 bytes would easily
> : suffice per player per player (just store an id for the people you know).
> : If there were 1000 players, and everyone knew each other, that would
> : take up less than 4 meg of disk space.
[snip]
> Frankly, 25 megs of disk is an hour's pay these days, or less. In
> addition, this implementation was DELIBERATELY chosen to SUCK for
> efficiency.
>
> Writing in C seems to convince most people that EVERYTHING is an
> efficiency concern. This is not true. Almost nothing in a mud
> is an efficiency concern. Get over it.
The disk space is not of major concern to me, although I do prefer to
avoid sloppy coding techniques - maybe thats just personal preferance?
Of course I don't work on commercial software, and - I can assure you -
when developing realtime embedded software in the aerospace industry,
efficiency is very important. But then I'm sure you knew that already.
I wrote the bit about optimising hd usage in responce to the following
from John Viega:
think "really horrible" is too harsh. In your example, you'd be
storing on disk 125 bytes per player, which over 1000 players would be
about 120K. As your mud gets larger, That's not bad if you've got a
fair bit of disk space devoted to the mud, since most of the info is
I just wanted to point out that should the space be a problem, it can
easily be avoided. For a lot of people, such space IS a problem - if
you don't own the machine, you can hardly stick a spare drive on it.
KaVir.
John Adelsberger
Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote:
: John Adelsberger wrote:
: > Frankly, 25 megs of disk is an hour's pay these days, or less. In
: > addition, this implementation was DELIBERATELY chosen to SUCK for
: > efficiency.
: >
: > Writing in C seems to convince most people that EVERYTHING is an
: > efficiency concern. This is not true. Almost nothing in a mud
: > is an efficiency concern. Get over it.
: The disk space is not of major concern to me, although I do prefer to
: avoid sloppy coding techniques - maybe thats just personal preferance?
There is nothing sloppy about the method I suggested - it sucks compared
to other methods in terms of efficiency, but it doesn't NEED to be
efficient, and this was the sole point.
: Of course I don't work on commercial software, and - I can assure you -
: when developing realtime embedded software in the aerospace industry,
: efficiency is very important. But then I'm sure you knew that already.
What does realtime embedded avionics work have to do with muds? If you'll
note, above, I said 'Almost nothing in a mud is an efficiency concern.'
I admit, if your mud runs an F-15's avionics package, you probably need
more concern for efficiency, but why do I doubt this?
Richard Woolcock
John Adelsberger wrote:
>
> Richard Woolcock (Ka...@dial.pipex.comNOSPAM) wrote:
> : John Adelsberger wrote:
>
> : > Frankly, 25 megs of disk is an hour's pay these days, or less. In
> : > addition, this implementation was DELIBERATELY chosen to SUCK for
> : > efficiency.
> : >
> : > Writing in C seems to convince most people that EVERYTHING is an
> : > efficiency concern. This is not true. Almost nothing in a mud
> : > is an efficiency concern. Get over it.
>
> : The disk space is not of major concern to me, although I do prefer to
> : avoid sloppy coding techniques - maybe thats just personal preferance?
>
> There is nothing sloppy about the method I suggested - it sucks compared
> to other methods in terms of efficiency, but it doesn't NEED to be
> efficient, and this was the sole point.
You said that almost nothing is a mud is an efficiency concern, I simply
stated that just because it isn't doesn't give an excuse for sloppy coding.
I am used to restrictions of ram/cpu/hd space, and so I try to optimise as
much as possible.
KaVir.