[crossfire] TODO list

[Alexander Schultz]

No, not client or GUI-related. Nicolas means to use it as a utility
library for C++, along the lines of the "Boost" libraries (which I
personally thing are better suited)

On Fri, 2010-01-15 at 13:52 -0500, Dany Talbot wrote:
> 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
> >
> >
> 
> 
>