SDL interface ideas

[Stan Shebs <shebs at shebs dot cnchost dot com>]

The central problem with going to a low-level library like SDL is
that you end up having to do everything yourself.  If you take a
look at the games using SDL, you'll see two categories; a handful,
such as ASC and the commercial games, that have homemade widget
sets and a pile of code to manage them, and the arcade-style games,
for which the interface is minimal.

There is a lot to be said for minimality, and Xconq should adopt
that as a goal.  The map display (whether overhead or at an angle)
should be the focus of activity; any distraction from that must be
at most temporary.  That said, most of Xconq's games are too
complicated for a single map to be able to display everything
that the player needs to know, and thus we need to be able to add
auxiliary displays.

This is a common issue for strategy games in Xconq's genre, and
it's interesting to compare how different developers have solved
similar problems.  There is also an identifiable evolution towards
a common layout; information panels to the bottom or left, a minimap
using solid colors, a mouseover or rollover panel as the primary
text display, minimal text in general.

Since Xconq is really a game engine, what we really need from
interface support is a set of tools to build an interface tailored
to a specific game.  This may be a lot to ask for, but we have a
couple advantages; first, Xconq games do have much in common,
and second, we can do things incrementally, starting with less
flexibility and evolving as time goes on.  We just need to design
with the expectation of future change in mind.  In practice this
might mean that a first version has flexible layout, but only uses
one font, and game-specific fonts come later.

So given that we want to be map-centric, my suggestion is to
implement all other elements as either panels that come in from
a side of the map, or as popups that come up in the middle.
Ideally, every panel will have a button that brings it out and
pushes it back, so the players can choose which ones to have out.
At some point it may be possible for players to rearrange panels
by dragging.

Popups will have controllable translucency.  There can only be
one popup at a time, but it will be only semi-modal; in a network
game, things can still be happening (thus the value of translucency).
Popups will usually have dismissal buttons, although it should be
possible to bring up a simple menu and have a selection dismiss.

Panels will always be opaque.  In a first version I expect that
panels will take up an entire side of the window (so as to avoid
non-rectangular maps), which suggests that it should be possible
to fit multiple panels into a side, for instance unit info and
minimap side by side in a bottom panel.  So panels may have
subpanels, although I doubt that subsubpanels will ever be useful.
A game should be able to specify a default layout for panels
and subpanels; the tcl/tk packer's "cavity" model seems like a
good idea for this.

The types of panels are fixed - world map, unit info, notices,
etc, but we will need to define variable properties of each,
such as the background image/patterns.  Ideally, panels will
allow for some size flexibility, defining images for corners
and patterns for the middle, but it should be possible to have
a fixed-size panel tied to an image.  In practice, it will
probably make more sense to have multiple panel types, such
as distinct "horizontal layout" and "vertical layout" panels
for unit info, rather than trying to make a single panel have
super-intelligent layout code.

Most panels and popups will have widgets.  Mostly these will be
buttons, but some will be text widgets.  Random image display (such
as the unit type image in the unit info) can be handled as part of
the panel's regular draw/update.

Things like game setup screens and help info should be large popups
with blank screen (or decorative image) behind them.

Implementationwise, popups and panels are an integral part of the
screen drawing process, so everything has be designed to allow for
redrawing of small parts, such as when the cursor passes over them.

OK, there's my first pass - have at it. :-)

Stan