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]

Re: The SDL client (fwd)


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

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