Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: more updates soon, comments/votes requested



Steven Lembark wrote:
> 
> normal habit on *NIX (for me at least) would be to have multiple
> servers running (with their own /var/ space for players, etc)
> sharing static data.  connect to port X and get a "stock" server,
> connect to Y and get the expirament.

 Yes, I agree.

> 
> point is that the law of unintended consequences is frequently
> better subverted by frequent testing rather than analysis (which
> invariably proves wrong in the end :-).

 Yes and no.  I think you can look at some things at know pretty quickly that
you really don't need to do any testing to know it will really mess with the
play balance.  Other things are opposite - don't affect it really at all.  It is
of course those things in the middle that are hard.

> 
> if you look at the linux configs there is an `expiramental
> drivers' switch.  turn if off you get stock choices; turn it
> on and get the beta stuff.  if the next version of CF made no
> user-level changes at all but made the code more modular then
> this method might work nicely.

 One difference that the analogy doesn't take into account is that by having
linux support every device under the sun, it really doesn't make linux any - it
expands the functionality, but really doesn't break anything that is there
(enabling support for some new sound card is not likely to mess with your scsi
card for example).

 Crossfire is very different - some data, by its nature, is quite static
(maps).  Now certainly, it is conceivable to have multiple set of maps - if you
run with these features, you should get set X because they are balanced for that
- if these other features, get mapset Y because they are balance like that.

 And in a perfect world, that is probably the way to go.  But realistically, I
think if you look at current map developement, you really want only one target
to be designing maps for, and to balance the maps against that target.
 
> 
> that's why the idea for two servers at one site:  people could
> compare things in a more-or-less uniform method, see how well
> they worked and come up with an answer.

 For expiremental stuff, that may work out (have config options to
enable/disable it).  And in fact, that is what has been done in the past.

 The problem is that too often, that code sticks around forever whether or not
it really should, on the basis it is just a simple config option.  If you remove
that option, and the code that supports it, someone is almost always bound to
say 'what did you remove that feature for - it was really cool'. (and there is
also the actual work of removing the now unneeded code).  

 If anything, perhaps that testing phase should be quickened up.  That new
feature/config option goes in for one release, and after that release, we see
which way we want to go (or maybe it sticks around for another if that release
has shown problems, but the code writer has made various adjustments).  IF it
doesn't meet standard at that time, that code goes away, and we can go on.

 My personal opinion is that the actual gameplay itself isn't a real problem -
adding a bunch of new spells or other features really isn't going to make the
game much better for me (an experience player), and for inexperience players,
there is already 150 spells, so adding 5 more is not likely to make it a game
worth playing or not.

 For me, the issue much more is actual interaction on the maps - dealing with
NPC's, having good/clever/challenging maps that are not just slugfests.  Adding
character to the game.

 Some of these features certainly do require coding, and I think after about
0.96.5 (depending on the release schedule - with CVS and nightly snapshots, I
don't really feel as much need to make incremental releases since people can get
the latest anyways), the focus really should shift to map design, and adding
code that makes the maps more interesting.

 One such example was the random button pusher.  And there are almost certainly
others - things like 'I would really like to be able to do X on my map, but
really can't because the code doesn't support it'.  To me, that means adding
coding to support X may be in order.  Code to support map features is not likely
to affect game balance much, but may make for much more interesting maps.



 
> 
> aside: last linux journal, in the game section, had a nice
> writeup of crossfire (along with other graphical MUD's).
> suitable for framing, etc :-)
> 
> --
>  Steven Lembark                                   2930 W. Palmer St.
>                                                  Chicago, IL  60647
>  lembark@wrkhors.com                                   800-762-1582
-
[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]