[crossfire] TODO list

[Mark Wedel]

Nicolas Weeger wrote:
>>   I know someone sort of looked into doing crossfire in C++ several years
>> back. Their opinion was it was probably easier to start writing the code
>> from scratch vs trying to convert the existing code.  I haven't looked at
>> it enough to say for sure, but I could certainly see it may be easier to
>> start from scratch but keep in archetype/map/player/protocol compatible. 
>> On the same basis, one could use that to clean up lots of bits of code that
>> are their for compatibility reasons or because that is the way things
>> should work - one could actually define how those things should work.
> 
> Around one year ago I and another did an experiment converting to C++ and 
> introducing Qt.
> It was never completed, mind you (but as a by-product there is the CRE tool in 
> utils/), but it wasn't *too* bad to do.
> Making it build C++ mode was like 2h work. Introducing classes did take more 
> time, though, but was doable too.

  I could see that - C code in general should compile under C++, but there may 
be a few areas where it doesn't.  But just making it compile under C++ doesn't 
get a lot.

  To be really valuable, conversion to classes, etc, is likely needed, and that 
is a much bigger project.  And the question then is whether it is worth it to 
try to convert the existing code base (structure by structure) or start with 
something new, with perhaps lots of copy/pasting, but also proper/better design 
in how the classes and like interact.


> 
>>   But I suspect the stuff under Various is low priority - for the most part
>> it cleans things up for developers, but doesn't really change the
>> experience for players.
> 
> Correct. Various is more 'in some years', or 'never'.
> C++/Qt would be a real time-saver in the long run - don't have to redefine 
> shared strings, many many "free" stuff - threads, sockets, and such. And 
> using a tested library.

  I don't know a lot about Qt, but it looks like the big bonus is better cross 
platform stuff.  POSIX doesn't define everything we use, as evidenced by a fair 
number of #idef <platform type>

> 
> 
> But the first topic for me is gameplay / content. As long as no one is 
> seriously working on that, I'll not do much on code, I think.

  I agree that should be primary focus - we can always toss lots of stuff in 
code, but unless it makes the game better to play, doesn't get us a lot.

> 
>>   I guess my question would be whether food as a core stat really adds much
>> to the game or is as much a headache as anything else.
> 
> IMO it adds some fun.
> And you could still eat some raw meat from monsters, when they give some. And 
> you could introduce some fun diseases related to food - "hum, that cow steak 
> was good... err, why are you feeling crazy, suddenly?"
> 
> Or it could just be used to regenerate sp.
> 
> But right now it's useless.

  The problem is some maps are very food scarce, because of the monsters on 
them.  But maybe this just goes back to me playing a troll character at one 
time, and having to deal with carrying large amounts of food (due to the trolls 
bonus is HP regeneration, food usage goes up).

  Priests at least have the odd case where they can create food.  But I guess 
nethack had food.

  I think one change, relative to food, is for all flesh type things (which can 
be eaten as food) should have some time limit where they start to decompose/rot. 
  I shouldn't be able to carry around an ogre leg for a week and eat it like 
nothing has happened.  Just adding some form of rotting would probably reduce 
available food by a bit.