[crossfire] TODO list

[Dany Talbot]

What would be redone with Qt ? anything GUI-related ? so the client(s)
[which ones? cfclient ?] the map editors [which ones? cfeditor? or the
java one or the gtk one?]? would you need/want to add some sort of
server admin console?

On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger
<nicolas.weeger at laposte.net> 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 probably dig the source code if needed, even if it is obsolete by now.
> Oh, and it did have dynamic archetype loading ;)
> (ie change an archetype in the tree, it'd pick up the change a few seconds
> later - worked for faces at least)
>
>
> But maybe yes rethinking the whole game architecture could be done taking the
> opportunity.
> Of course, not a 2 days project.
>
> And we would need to know the focus - modular design? robuste? performant?
>
> (and see next reply :))
>
>
>
>>   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.
>
>
> 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.
>
> Unless I get seriously bored with reinventing the wheel and just introduce Qt
> to have basic functions - and not change the current non class mode. But I
> wouldn't do that without having a consensus on the list - worse case I'd make
> my own branch and work still on content :)
>
>
>
>
>>   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.
>
>
>
>
> Nicolas
> --
> http://nicolas.weeger.org [Mon p'tit coin du web]
>
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>



-- 
Dany Talbot, Quebec, Canada [ Crystalmir at gmail.com ]
"Per aspera ad astra"