[CF-Devel] Future development & version 1.0.

Mark Wedel mwedel at scruz.net
Tue Jan 2 22:48:38 CST 2001


Jan Echternach wrote:
>
     
     
     >
     
      On Thu, Dec 07, 2000 at 11:31:57PM -0800, Mark Wedel wrote:
     
     >
     
      > 2) Scalibility of server.  I don't know the most heavily loaded a server has
     
     >
     
      > been, but potentially if we are trying to make crossfire mainstream, this could
     
     >
     
      > be tens to hundreds of users.  I'm not sure how well it currently does - even on
     
     >
     
      > my slow sparc 10 running the tavern, a couple players did not seem to chew up
     
     >
     
      > much cpu, so I think we may be OK on that.
     
     >
     
     
     >
     
      I think I've figured out what caused very bad performance on my local
     
     >
     
      server.  It's easy to reproduce this way:  Take a level 100 wizard and
     
     >
     
      cast meteor swarms at a wall for about 10 seconds.  My Pentium-133
     
     >
     
      slows down to a crawl because there is a O(n^2) in this scenario.
     
     >
     
      There can be as many as 100 active fire cone objects on one map square,
     
     >
     
      each trying to hit each other in hit_map().
     
     
 Any reason we can't make them sort of mergable?

 IF for example they are the same except for damage (ie, they are moving the
same direction, have the same distance to still move, and so on), merge them but
have the damage additive?  Would that work? (I guess the better question is -
does anyone see any terrible side effects with that?)

 Otherwise, other than limiting amount of objects per space, I don't see an easy
solution to that (a harder one would be to have a seperate list/stacking on each
space that represents objects or livable creatures, which wouldn't get too large
by its nature, so performance wouldn't get as terrible).

 Another possible solution which may work would be to stop searching the space
(which goes from bottom up) once we find another arch of the same type.  This
would sort of make the assumption that anything to be affected would already be
below it, but that isn't perfect in that if a monster moves, it will now be on
top.

 Also, insert_ob_in_map would need to be changed in a similar fashion, as
otherwise I think it will have to travers X number of objects in order to find
the top to insert the fire.  This could be changed by using double pointers in
the map structure - top and bottom.  Probably a good thing to do for 2.0, as
lots of places out there need to go and find the top object and they then work
downwards.


>
     
     
     >
     
      > of various buildings/dungeons having bee ncleared out.  With 30 players on a
     
     >
     
      > server, I could see it being quite difficult to find available dungeons.  The
     
     >
     
     
     >
     
      One thing that makes this worse is that each time a player enters a map
     
     >
     
      to look if it has been resetted the time until map reset is restored to
     
     >
     
      its initial value.  All players would have to agree on using the "maps"
     
     >
     
      command to find available dungeons.
     
     
 Lots of maps are also only 1 player friendly at a time (narrow passages and the
like).

 The map reset also gets a little tricky - if your working on some of the longer
quests, it will simply take more than 2 hours to complete it, so you don't want
the maps reseting behind if you leave/beam out for whatever reason (say to pick
up some new items/food/whatever else).

 What would probably be useful is some object on the map that could be a trigger
to reset a bunch of maps.  So for example, you complete the quests, and in the
process of stepping over some space or using the exit, there is some object that
contains the maps to reset.  The server then goes through and marks those maps
to say reset in a few minutes (in case there were any stragglers with the first
player player on a map or two behind lets say), and we also set a flag so force
a reset (so if someone does wander in or as the other players are leaving, it
doesn't postpone that for a few hours).

 The only potential problem with this is that if a player knows that behaviour,
they could perhaps go through and wait on the next to last map, know it will
reset in just a few minutes and grab the loot again.  But I don't think that is
too terrible - the toughest monsters tend to be on the last map, and repeat
treasure doesn't get you a lot.

    
    


More information about the crossfire mailing list