[crossfire] Summary, was Re: The future of Crossfire

[Mark Wedel]

Nicolas Weeger wrote:

> As a related note, I'd use the 'lore' field of maps to describe what quests 
> they are part, things like that (lore is never displayed except by DMs using 
> the dumpmap command). Splitting the author field (as a feature request says) 
> could also help, maybe even a special "quest" field. But that's really not 
> that an urgent thing.

  Not sure, but I think the maplore field was envisioned as something that could 
be collected and then put into in game material (on a cave deep in the forest 
there is a power weapon) type of messages in books or scrolls, or even NPC's 
perhaps.

  But nothing preventing the addition of other fields to hold game information 
(related quests, etc).  Or maybe depending on the format of the data itself, 
could be in the lore.

  The lore idea, and discussion on it, I thought were really good.  It was just 
something never finished - lots of things like that in crossfire.


>> - Slow down combat - combat is too fast so there is no tactics.  Combat
>> should be slowed down so that there are tactics and time to react to
>> events.  IMO, crossfire should be an adventure/RPG game more than an action
>> game.  Note that slowing down combat will likely have other effects -
>> reduce gain of exp, reduce gain of wealth, etc.
> 
> Agreed, to the condition we don't become a turn-based game :)
> Let's say a reasonable reaction time and planning should save one's life 
> often, unless really going in weird places or really unlucky. I'd add stats 
> (wc/ac/...) rebalancing, while we're at it :)

  I don't think crossfire can ever become turn based, not so long as it remains 
multiplayer.

  A fair amount of rebalancing is probably needed - speed, weapon speed, and as 
said, wc and ac are also a bit out of whack.

> 
>> - Add better (some?) sound/music support.  Music files are on the tracker,
>> and so map level music probably isn't hard.  The game is missing lots of
>> potential sound effects (just things like gates opening), so would be nice
>> to be able to add more to give a more immersive feel.
> 
> Agreed. We need client support, though.

  Yes, I was planning on looking at that soon.

> 
>> - Races & Classes:  Need to be more distinctive.  Perhaps several races
>> should be removed (not especially distinctive from one another- was more
>> relevant back when race & class was the same thing).  Classes need to be
>> redone so that there is more importance in choosing the class you take
>> beyond starting skills, so that high level wizards and fighters actually
>> look quite a bit different.
> 
> Yep.

  It may be a question of how many races and how many classes there should be. 
IT seems to me that there are a lot of classes in addition to races.  We've had 
past discussions on some aspects - one thing may be to have a more basic 
selection of classes than we have now, with an idea of some custom class 
creation method, so that we don't have to try and cover all all possible 
magic/skill combos like we do now.


>> - Add missing documentation - everything about archetypes should be
>> documented. Some code cleanup likely in order to make objects behave in a
>> consistent fashion.
> 
> Agreed, but shouldn't be the priority. Documenting when fixing, yes. 
> Documenting just to document, well, rather do something else if you can 
> (what? I did document like crazy just for the sake of it? No, you're just 
> dreaming ^_-)

  But in some cases, it isn't clear what the correct behavior is - in those, we 
should just document something (x behaves like ...) vs trying to write in 
exceptions, etc.  I'm personally in favor of clean code with clear meanings vs 
code with lots of exceptions, questions on how it should operate, etc.

> 
> IMO, this should be our medium to long term. Of course if we could do all this 
> in a reasonable delay, it could be into CF 2.0, but it shouldn't delay the 
> release too much just for that. Better release incremental things if 
> possible.

  We should probably add these things to the main TODO list.  it may be worth 
while to add these items to the list.  OTOH, a fair number may already be there.

  The problem is that the TODO list is so long that it sometimes becomes hard to 
figure out what should really be tackled next.  I'll note that the TODO list on 
the wiki (http://wiki.metalforge.net/doku.php/dev_todo_new) often seems more 
code oriented, where a lot of the changes we're discussing here are more map 
level level.  In fact, of the list I did, arguably very few of those require 
code changes - many might just be archetype and map changes.


> As usual, we also depend on people actually doing the code/work at some 
> point :)

  Right - and the problem there is that whenever people are volunteers, they'll 
work on what they want to work on, and not necessarily lists like this that we 
put together.