This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Converting xconq to C++


I'd prefer to get the code into C++.  I sense that there's common agreement
that being in an OO language is a good idea, and the guy doing the work has
limited time, and already knows C++, so let's get that done and working
cleanly.

I would imagine "objectifying" the game is a lot more work, than porting
from
one OO to another, once the game is in an OO language.  But, I don't know
these other languages, either.

Erik

----- Original Message -----
From: "Bruno Boettcher" <bboett@bboett.dyndns.org>
To: "xconq mailing list" <xconq7@sources.redhat.com>
Sent: Friday, April 05, 2002 7:03 AM
Subject: Re: Converting xconq to C++


> On Fri, Mar 29, 2002 at 01:02:15PM +0100, Alan Schmitt wrote:
> > What I'd really like to understand, if xconq is ported to another
> > language, is what we gain from it. If xoncq fits nicely in an object
> hmm seems i am too late to really give my opinion :D but here it goes
> nevertheless...
>
> as others stated OO is more fun to code and allows to strip down the
> code into managable trunks.... furhter it allows to test and apply all
> those nifty concepts we learned at university (even if it is now some
> time ago :D)
>
> as sayd i tryed my self a port to java some time ago, with some other
> guy from this list, but it was a fiasko :D :D
>
> from my time scedule i will only issue advice and not be able to let
> those follow some real help, but anyways :D
>
> > oriented programming style, why not. But choosing which object language
> > to use depends on 3 things I can think of: efficiency (both of the
> > resulting code and of the coding process), portability, and extra
> > features (what librairies are available, what additional language
> > constructs may be used).
> agreed!
>
> > language that could be used: objective caml (http://caml.inria.fr). In
> yup nice! i like also eiffel a lot!
>
> > why not rewrite xconq (it seems to be quite an undertaking, but why
> > not), why not do it in a different programming style, but why c++ ?
> the general idea is that the migration from C to C++ is really easy....
>
> but, having myself participated in the migration of a C program into a
> C++ program (don't know if anyone knows the circuit simulator acs...) it
> can go down the path of the programmer hell.....
>
> at last i rewrote a new simulator from scratch (even if largely
>     profiting from the concepts i acquired by helping port acs to C++)
>
> concerning xconq i think the porting will be simpler, since the C base
> is way more sound than the acs base was ever, but since we are about
> rewriting, why not try to change directly some paradigms in the game and
> make immediately a move to a client server architecture?
>
> i know it is a recurrent design thread :D and that the actual stage now
> appears to come back to something usable, but i really think that a
> client server design would be way more robust.
>
> Moreover, a client-server design is really easy to implement in C++,
> there are even ready library classes and templats for such stuff....
>
> so i would suggest another approach:
>
> take the actual code base, and build up a new sourcebase, copying from
> the old code base where appropriated, but building on an own scema....
>
>
> --
> ciao bboett
> ==============================================================
> bboett@adlp.org <- UPDATE your address books please!!! CHANGE!
> http://inforezo.u-strasbg.fr/~bboett
> ===============================================================
> the total amount of intelligence on earth is constant.
> human population is growing....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]