[Freeciv-Dev] Re: [Kde-games-devel] libadvkdegames (was qt)

[Andrew Sutton <ansutton@xxxxxxx>]

sorry for all the cross posting...

On Monday 31 December 2001 01:41 pm, Per I. Mathisen wrote:
> On Mon, 31 Dec 2001, Andrew Sutton wrote:
> > i don't think the proposal was for a kde-only civ clone. i believe what
> > gregor is talking about is a system independent library that implements
> > code common to civ clones - e.g. maps, units, technologies.
>
> All very good, but if such a library is to be adopted by existing game
> projects like freeciv, it can require only dependencies acceptable by all
> projects, which would rule out both Qt and KDE. Please remember that
> freeciv is not a Linux/Unix only game.

qt works on windows too - and embedded platforms (palm civ!). i don't think 
that would rule out qt. as an underlying library (or set thereof) Qt would 
make a great choice.

> A starting point for such a project would instead be something like eg
> the Kyra sprite library (http://www.grinninglizard.com/kyra/).


> If you want a common API for games, why go for Qt, when SDL fits the bill
> a lot better? Qt is not designed for game programming, SDL is. SDL is more
> portable. SDL is faster. (See http://www.libsdl.org/)

SDL is a media access API - its not really something you'd use to build, say, 
a server. Qt is actually pretty good in that regard. although its primarily 
seen as a gui toolkit, it actually has a couple of very nice properties that 
make it specifically suited for game development - mainly the signal/slot 
type stuff.

what would be REALLY, REALLY nice would be the porting of Qt to SDL. then you 
could work with a highly customizable widget set on top of SDL and you retain 
the capabilie of both Qt and SDL.

there seems to be some confusion about the underlying software package. 
unless i'm mistaken. gregor's original post was about a configurable game 
engine library - not the client representation of it. if this were to move 
ahead, it would most likely be a set of libraries. each game (component) 
would use only a subset of the total available libraries. there could be nice 
little wrappers for the following (sort of like directX).

        - 2d gfx
        - 3d gfx
        - sound
        - networking
        - control (joystick, keyboard, mouse)
        - windowing
        - players (single player, multiplayers, groups, clans).
        - various gaming frameworks (civ-style, cards, rpg, etc...)

granted some of these would be implemented by the underlying package (SDL, 
Qt, other), but they could be wrapped for the gaming libraries.

> Well, there is always xconq (http://sources.redhat.com/xconq/), but yes,
> that could be both fun and useful. As I said, the more the merrier :)

agreed ;)

andy