This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: The SDL client (fwd)
- To: James McCann <jmccann at WOLFENET dot com>
- Subject: Re: The SDL client (fwd)
- From: Stan Shebs <shebs at shebs dot cnchost dot com>
- Date: Mon, 15 Jan 2001 10:56:27 -0800
- CC: xconq7 at sources dot redhat dot com
- References: <200101151812.KAA22336@gonzo.wolfenet.com>
- Reply-To: shebs at shebs dot cnchost dot com
James McCann wrote:
>
> I will delurk for a while to comment. I think using SDL is an
> outstanding idea and can transform xconq into a game that is playable
> by a much larger public -- IF and only if the interface is done correctly.
> It would be a shame if enthusiasm for coding immediately drove some poor
> design decisions. Now is the time to provide a modern, flexible UI that
> can look fantastic.
There's an interesting tension here - the current interface has
elements that have hardly changed since 1987, and there are players
that think they are great. But in general it's very dated. SDL
offers a chance to start fresh, although that means extra work!
> Rushing would be a mistake, unless you are prepared to throw this away. I
> think it is very important at this stage to understand the issues and to
> correctly design an interface framework. I think this means writing "xctk"
> the xconq toolkit. There should be discussions, followed by a RFC, followed
> by everyone blessing it and only then should any code which will see the
> light of day be written. I also think that SDL should be completely wrapped
> to allow for the inevitable GL port (now wouldn't that be cool? I can't wait
> to play the Kursk 1 to 1 vehicle scale 1st person scenario).
I'm OK with doing a certain amount of prototyping. This is my
own first experience writing new SDL-using code, and it's been
interesting to observe what's cheap and what's expensive (for
instance, updating the whole screen seems much cheaper than I would
have guessed). But you're right, in the end we need a framework
good enough to support a large number of interface elements.
(Funny you should mention Kursk - I've been studying Combat Mission
a bit, wondering how hard it would be to do... Dunno if Xconq would
reasonably stretch that far though, the underlying engine is very
much 2d-cell-oriented, while CM is all about polygons.)
Stan