> 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)
Indeed, I meant server-side. Client-side is JXClient IMO :) Nicolas > > 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 > > > > <[email protected]> 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 > > > [email protected] > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > _______________________________________________ > crossfire mailing list > [email protected] > http://mailman.metalforge.org/mailman/listinfo/crossfire -- http://nicolas.weeger.org [Mon p'tit coin du web]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
