The SDL client (fwd)

[James McCann <jmccann at WOLFENET dot com>]

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.

If the transition to SDL is screwed up it will be a terrible waste of an
opportunity.  I for one have played xconq and think it is a great idea
but I have been turned off by the awful (sorry guys) interface.  This
is a very important chance to make this into a terrific and widespread game.
I for one would play it and develop for it, I have a First Age game 
gathering dust on my hard drive.  I would also like to see the game have
an email mode.

> 
> Secondly, how about using libSDL_image to handle image loading - this
> would make it easier to read the .gif images used elsewhere in xconq as
> well as .png images for fancier (24bpp) screen graphics. I imagine that
> a future SDL client propaly needs lots of small images acting as widgets
> and large images as backgrounds/helpscreens/... which would seem to
> motivate an image loader supporting more than just .bmp images (which
> usally takes up lots of space for larger images - ie. bad packing
> algorithms).
> 

Definitely use a flexible image loading library.   I think that these images
would be a part of a "skin".

> Also, IMHO - it would be good if the framework for deciding where things
> should be drawn on the screen is settled for as quickly as possible. It
> probably wouldn't be a good idea if I started writing some dialogs 
> displayed simultanesouly with the map (eg. sides/building/research etc.)
> unless we have atleast some more infrastructure. Perhaps something along
> the lines of having a number of structures (as below) which can be 
> initialized by the drawing routines and read GDL data to describe what
> actions to be taken when the mouse is clicked on various parts of the
> screen etc.
> 

I advise against quickness and for correctness.  Do not force any decisions
about placement, allow that to be set by interface or game designers.  
Consistency is good but "a foolish consistency is the hobgoblin of little
minds".  It is also my opinion that the "capability not policy" attitude
behind X provides less capability than a system w/ a little more policy.
The key is to provide a policy that can accomodate a variety of interface 
styles.  There is no reason to rush.  

I think that a mechanism for providing "skins" should be designed.  The
game designer should have first crack at placing dialogs, then user 
preferences should be considered in some instances.  

> struct panel {
>   SDLRect r;
>   void (*draw)(struct panel*);
>   void (*mouse_clicked)(struct panel*);
>   void (*mouse_moved)(struct panel*);
> };
> 

I think it is too early to write anything you are thinking of compiling
(not that I see anything wrong w/ this as far as it goes)

> (I'm assuming we don't want to do the drawing stuff with C++ and
> inheritance - correct?)

It should be done in C, despite C++ having some real advantages.

> 
> I'll start writing some form of new_game_dialog this week, it seems like
> that stuff can be done quite indepedently from the rest of the SDL client.
> (It needs its own event loop).
> 

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 know that as a non-xconq-developer my opinion is probably worth little, but 
I think that having a good design is far, far more important than hurrying.
It is not like you have deadline pressure, and you don't have the ability to
hire contractors to hurry things along.  So just slow down, and come up w/
a correct design that all can live with.  Switching to SDL is such a huge win.

James