RE: CF: ideas for next experiments

[dragonm <dragonm@leech.org>]

-----Original Message-----
From: Mark Wedel
To: crossfire mailing list
Sent: 9/13/99 9:43 PM
Subject: Re: CF: ideas for next experiments

<snip>

Don't be so sure about memory usage.

The extra object in the inventory only costs extra memory for copies of
those object currently in play (ie, on a map, in someones inventory).

If you add extra damage fields (or any extra fields), that memory usage
will be for all objects of that type.  So if the weapon object type is made
larger, than all weapons use more memory.

In the end, there is some tradeoffs (maybe 10 objects with the extra
fields is the same as 1 object with inventory).  Note of course not all
weapons would have inventories - in fact, as I see it, it would actually be
a fairly small number.

In addition, that object in the inventory may be an actual different
object type (an effect and not a weapon), which is likely to have a smaller
memory footprint.

 The analysis of memory in this case is not worth it.  What I would really
say is lets not use memory usage as a justification for one method or
another at this point.  I personally would prefer cleaner code and the
expense of memory and cryptic code that minimizes memory usage.  Which is
sort of what the 0.95 to 0.96 tradeoff will be (although I have yet to do an
actual memory analysis there)
----------------
Hear hear!  Memory is irrelevant as an arguement for or against a method of
doing something.  I have 128 megs of memory.  Machines with 64 megs of
memory cost less than $600, including monitor.  Burn, baby, burn!

Really, memory is meaningful only to the server, and it's not meaningful to
the server until it can handle 500 simultaneous users.  Has anybody ever
seen a server with more than 8 people logged in at once?  I seem to recall
an older description of a server that noted that any more than 4 users would
slow it down to the point of unplayability.  I haven't tried any performance
testing yet myself, though I intend to.  But I suspect that the 500
simultaneous user region is thoroughly inaccessible right now.

Look at it this way.  We're Open Source.  We have no sponsors.  We have no
deadlines.  We can take as long as we like to do anything at all.  If memory
needs optimizing down the road, we can do it.  There's no manager to say,
"We have to meet our ship date!  No time for optimization!"  It has taken
since 1992 to get this far, and I think the general consensus is, this still
isn't a commercial quality game.  So what's a few more years?  :)  Our only
goad is each other.  Even the fans are singularly silent.  So...  <cracks
whip in Mark's direction>  Code 0.96!  :)
----------------

 For players, where the size of the inventory may very wildly, that is
difficulty to do.  An index table of 50 won't work very well if the player
has 100 items in their inventory (and the more they have, the more you need
such a feature).  So either you make a very large hashtable that you know is
large enough (which then consumes more memory), or you dynamically grow it,
which causes you to re-file the hash table, which impacts cpu at that point.

 There is no good solution to this.  Ideally, better programming may be
needed - if something is going to search the inventory for 10 different
objects, it should just traverse the inventory once, and store the 10
different objects as it finds them.
----------------
If you're going to spank David over memory usage, I get to spank you over
CPU usage.  Not only do we have memory to burn, we have CPU cycles to burn
as well.  That under $600 machine that ships with 64 megs of RAM also has a
300 MHz Celeron in it.  My machine has TWO Pentium II 300's in it.  If
memory usage isn't a valid argument for or against a method of doing
something, neither is CPU usage.

We're in a development phase until v1.0.  And we still have no deadlines.
If we discover something running very slowly, we can fix it.  But especially
in the case of CPU usage, I don't want to hear anything about it unless
you're quoting hard numbers from a good piece of profiling software.  If CPU
usage to accomplish some particular task isn't out of line by at least an
order of magnitude, as proven by a profiler, why worry about it?
----------------

David Andrew Michael Noelle wrote:
> 
> dragonm wrote:
> > I've always thought that part of the point of having more
sophisticated
> > spells, i.e. fireball instead of raw mana attacks, was to go the
extra yard
> > and make the attacktype appear to the attackee as a fire attack,
rather than
> > a magic attack.  Where the fire came from should no longer be an
issue,
> > magical or non-magical.  Once the spell is cast, the result is real
fire.
> > If you want immunity to fire, magical or otherwise, you need
immunity to
> > fire.  Immunity to magic should not affect a magical fire attack.
> 
>     This is not my proposal, this is how things currently stand.
Magic is
> only an attacktype when it stands alone.  Otherwise, it is an
attacktype
> modifier.  Immunity to magic makes you immune to the direct effects of
any
> magic spell, and there are rather a good number of magic immune
creatures in
> the game.  The one loophole that allows mages any chance of dealing
with
> those creatures is that magically summoned creatures have non-magical
> attacks.  One of the reasons I'm proposing this God of Magic is to put
the
> most common magic immune creatures, beholders and skulls, on his
slaying
> list.

 Note that I believe the current reason for magic protection working the
way it likes is to probably sort of mimic the AD&D idea of magic resistance
in monsters.

 For background, some monsters in AD&D have some percentage value of magic
resistance.  When hit by a spell, roll the percentile dice, and if less
than that value, the spell does nothing.

 This of course works easy in a real life game where the GM can make
judgement calls on what is magical and not magical and should the monster
get a roll or not, and so on.

 Now maybe that should not be - maybe creatures should really just be
immune to the specific types (fire,cold, electrical, etc), and do away with
the idea of magic resistance (and thus rethink magical attacks).

 I don't really have a good answer - the current implementation makes
things more complicated, and a mage can't do a thing against a magic immune
monster.
----------------
I think I didn't make myself clear, and confused the issue even more as a
result.  Mark's last paragraph there is the salient point.  A mage can't
touch a magic immune monster.  I think that should be fixed.  As I said
above, magic immunity should disallow damage from raw mana attacks, but
shouldn't a magic immune monster take fire damage from a magically generated
fireball?

I'll try to rephrase what I was saying above.  With David's new spells,
we're differentiating between raw, unsophisticated magic usage and more
sophisticated usage.  When an amateur casts a magic spell, it's an
indescriminate blast of energy that can hit any kind of non-magic-immune
monster, but it costs twice as much mana to achieve the same amount of
damage.  When an experienced mage casts a magic spell, the expedenture of
mana generates a fireball (for instance).  It costs half as much mana
relative to a raw mana spell to generate a fireball that does the same
damage, but it will only damage a monster vulerable to fire.  My point is, a
magic-immune monster vulnerable to fire should take SOME damage from a
magically generated fireball, if not all damage.  The more sophisticated
usage of mana by the experienced mage channels mana's raw energy into more
mundane fire energy.  The result should be something close to real fire, if
not the real thing.  I thought David was proposing modifying how magic
immunity works, so that was my two dollars and 15 cents worth.  Maybe I
misunderstood him, in which case modifying magic immunity this way is my
proposal.  Whichever.
----------------
> > taking advantage of the existence of the server and having a more
persistent
> > universe.  I think that would dovetail well with the stated intent
to become
> > more RPG-oriented.  It would obviously have some truly immense
ramifications
> > to how maps are made and how quests are implemented and basically
how the
> > game is played today.  However, I think it deserves some thought,
and some
> > consideration as a long-term goal.
> 
>     Yow.  Major change there.  Even if that was adopted as a long term
goal,
> I don't know how we could move in that direction without changing the
basic
> nature of the game.  Maybe a few non-resetting rooms here and there in
> towns, but all of the dungeons are designed on the principle of being
reset
> frequently.  I suppose artifacts could be made more unique by not
placing
> them on their maps if any player who is known to have one either in
their
> inventory or in their apartment(s) is currently in the game.  That's
about
> as far as I can see it going without a complete replacement of all the
maps.

 There has been discussion about making some aspects more persistent.

 Instead of a shop completely resetting, rotate portions of the inventory
through.  So eventually all that stuff sold would disappear, and other
stuff would rotate through the inventory.

 The problem with doing this with dungeons is there is no current method
of regenation - if cleared out, it is empty until it resets.  And to try to
put programming logic in this would be very difficult.
----------------
I disagree.  See below.
----------------

 as an multiplayer game, you sort of need stuff to reset - otherwise,
the first people that venture onto the server would do all the maps, and
leave nothing for anyone else.
----------------
Maybe not.  Also see below.
----------------

 But it is unrealistic that stuff does just reappear - you completed the
pirate quest, and two days later they are back again.

 From an RPG perspective, that makes it less itneresting, because the player
feels he didn't complete anything that has a permanent (or even long
lasting) affects.
----------------
Very true.  We'll get back to that.
----------------

 I don't have a good solution to that however.
----------------
The solution is obvious.  Change things.  I never said it was easy.

I was going to say some things here, and discovered I had embarked on a very
long harangue covering a whole lot of bases.  Rather than make this e-mail
ridiculously long, I've decided to put all of that into its own message.
Basically, everybody's objections can be dealt with.  :)

DM
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]