[CF-Devel] Future development & version 1.0.

[Mark Wedel]

Peter Mardahl wrote:
>
     
     
     >
     
      >  I've taken a little time to think through future enhancements going towards
     
     >
     
      > 1.0 release.
     
     >
     
     
     >
     
      I think crossfire was a good game deserving of 1.0 years ago.  It's
     
     >
     
      been fun to play the entire time I've worked on it.  I really think
     
     >
     
      that in the last years, we've added icing to an already good cake.
     
     >
     
      It was a good game before I ever touched it.
     
     
 I think before the client server split, crossfire would not have been ready for
1.0.  Back when the server did remote x displays, lag was determined by the
laggiest connection.

>
     
     
     >
     
      Now it is a 3-layer cake with a lot of innovations seen in no other game.
     
     >
     
      The only major thing I think that has been missing is a real
     
     >
     
      bugkill push.  Jan in particular has done a lot in this direction:
     
     >
     
      if we're close to 1.0, he gets a lot of the credit for the bugsquishing,
     
     >
     
      though the rest of us have done some, too.
     
     
 It helps a lot of major new features are not being done, and I think that has
also stabilized (except for PR code) in more recent times.


>
     
      That is not to say crossfire is perfect, or "finished."  It'll
     
     >
     
      never be either, and I don't think anything remaining in the
     
     >
     
      TODO list should stop us from promoting the game.
     
     
 agree.

 
>
     
      Heck, we could have called the last release 1.0, and it would
     
     >
     
      be a credit to us and everyone who has contributed.  Omega was very
     
     >
     
      fun to play, but let me tell you, it was FAR less balanced than
     
     >
     
      crossfire is right now (even with the recent PR stuff.)
     
     
 Perhaps.  But with multi player games, I think balance becomes a bigger
concern.  But I do think we are in pretty good shape.


>
     
      > 1) Stability of the server.  The server really needs to be able to run for da
     
     >
     
      > under heavy loads with no problems.
     
     >
     
     
     >
     
      The only remaining serious bug I know of is "that map bug":  the one
     
     >
     
      where you come out of an exit and end up in the sea.
     
     
 I'll re-look at the enter_exit code - a rewrite may be in order in any case. 
But even that bug seems pretty rare.

>
     
     
     >
     
      > 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 cou
     
     >
     
     
     >
     
      Honestly, I think we should make it easy for someone to play the
     
     >
     
      game by himself on his own machine.  The game is great standalone as
     
     >
     
      well as networked, and I think we'd be better showing what crossfire
     
     >
     
      can be like played locally as well as on the... few... laggy....
     
     >
     
      public servers.  We should rename the client "crossfire", and have
     
     >
     
      it start up a server, "cfserv" locally if the player doesn't
     
     >
     
      select a network game:  and all this stuff should be 1 package.
     
     
 Including the server with maps makes a pretty big distribution.  For example, a
client with sounds archive would probably be around 500k or so (presuming we
only ship the raw sounds and don't do the au sounds).  The bzip2 map archive is
a tidy 2.6 megabtyes.  Untarred, its like 15 megabytes (or 30 mb - don't
remember if linux du shows blocks or kb).  That becomes a non trivial archive.

 But more importantly, it probably would not be too hard to do binary only
distributions of the client if you wanted to - binary distributions of the
server would be more of a pain.

 But perhaps at least for unix folks, you want to force them to compile?  As
said, more players is good, but if they can't figure out how to compile &
install the server, they probably will run into other troubles.

 Now what may be worthwhile is including a nice big notice with the client that
you could get and set up a local server.  And certainly, for many places (like
behind firewalls), that may be the only viable option.


>
     
     
     >
     
      > 3) Playability - how easy will it be for new players to play the game.  Even
     
     >
     
      > some of the current public servers without many players, you can get into cas
     
     >
     
      > 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
     
     >
     
      > only real solution to this I can see is just have a lot more maps/choices.
     
     >
     
     
     >
     
      Random maps.  This is why I DID random maps.  My whole reason for making
     
     >
     
      that huge exertion.
     
     >
     
      This is why I once proposed making cities where, by default,
     
     >
     
      each exit led to a random map.  The random maps are pretty good.
     
     >
     
      They could be much better.  However, no one has done significant work
     
     >
     
      on them but me.   The existing potential of random maps has been only
     
     >
     
      5% exploited....  For example, I could probably pretty much duplicate
     
     >
     
      nethack with random maps.
     
     
 But random maps are still persistant - ie, if I go on the goblin quest, those
maps stick around for some amount of time (as evidenced by the fact I can go
back and haul out my loot and make multiple trips).  So while it may be easy to
add lots of random maps, I don't recall a lot of exits leading to them right
now.

 this is of course easy to fix, and maybe it should be worked on.  I still think
one of crossfires stronger points are the pre-made maps, but simply put, we
can't make enough of those fast enough - perhaps with new players, we can get
new maps created.


>
     
     
     >
     
      > If possible, it would be much better to grow the user base slowly and not a
     
     >
     
      > sudden 10 or hundred fold increase.  The former will let us address some of
     
     >
     
     
     >
     
      I disagree.  We want a HUGE player base.  We just don't want them all
     
     >
     
      joining public servers.  Start up a server on their machine for them,
     
     >
     
      unless they specify a remote one.
     
     
 See note above.

 But my point is more that if you get tremendous growth and they find a large
number of problems (server unstable or other major bugs), you may end up with a
large dissatisfied user base who will never look at the game again (I've bought
some games that were pretty poor in terms of reliability and made the decision
not to buy that game/series again).

 I agree a very large user base is good.  I would just like to get to that point
over some amount of time (months) and not days.  Hopefully, some of these new
users will also set up public servers.

 And note that for windows client at least, their only real option is to play
against a public server.  Now the downside of windows only users is that they
will not contribute much to the project, as they're not using the server code
nor do we have a generic editor for other platforms.

 That later point is more difficult - the two solutions I could see would be to
use a web based application for creating maps, use something like java which
should run on all platforms, or resign ourselves to having to port the editor to
each platform.  For the current editor, this is probably a really big pain as it
uses Xt (which I don't think as an easy translation), and the graphics code is
mixed in much more than say on the client (which I've at least tried to
isolate).


>
     
      Well, we can try this out now.
     
     
 True.  Helps if we have real players and not dummy logins or windows that
aren't doing anything.


>
     
     
     >
     
      Nah, I think you're taking this too seriously.  People can live with
     
     >
     
      a few bugs or instability in their free game.  Either that, or they
     
     >
     
      can help us fix it.  Right now, we've not the manpower to do what
     
     >
     
      you're proposing, two CVS branches.  I'd rather see a development-release
     
     >
     
      cycle, like many codes do.  That's not to say we shouldn't make an
     
     >
     
      effort to respond to suggestions and fix bugs.  But let's not turn
     
     >
     
      our hobby into a job.
     
     
 Fair enough, but to rephrase, you are basically saying to make a 1.0 release,
branch continues forward, and  patches, while integrated, will be handled by
keeping a seperate patch file or the like with no additional releases.

 If so, then I would suggest this for a timeframe:
 In a few weeks, make a 0.99 release to get it out there (basically a 1.0
beta).  Other than what we have and already proposed enhancements (gods
rebalancing, PR adjustments), no new features.
 See how that release works out, and a month or so after that, release 1.0. 
Basically only difference from 0.99 is to squash some more bugs and try to
balance any remaining issues.

 Sound reasonable?