[Underware-devel] First steps

[Loic Dachary]

        Hi,

        Although I'll only step in underware january 1st, I'm starting
to work and think about it already, as much as my current work let
me. Here is my understanding of the current situation.

        We are aiming at bootstrapping underware with a bomberman
implemented in 3D. This is not innovative at all from a game design
point of view (;-) but is a good template to design and tune 3D online
games software components.

        The components we will use:

        - C++
        - Python http://www.python.org/
        - OpenGL http://www.opengl.org/ http://www.mesa3d.org/
        - OpenAL http://www.openal.org/
        - STL    http://www.sgi.com/tech/stl/ http://www.stlport.org/
        - SDL    http://www.libsdl.org/
        - Single Unix Specification Version 3 
          http://www.unix-systems.org/single_unix_specification/
        - OpenOffice http://www.openoffice.org/

        The rationale behind this minimal consensus (I believe we
have a consensus ;-) is as follows:

        - C++: efficient and everyone involved in underware is skilled
              in C++
        - Python: we need a scripting language and python is the mostly
                  widely used scripting language in the Free Software 
                  gaming field. Inventing a new language would just be
                  a waste of time. We need a stable, portable, 
                  extendable, full featured language. We hope that
                  its wide use in Free Software gaming will allow
                  us to cut/paste existing code. However, even if
                  we don't, Python matches our need. 
        - OpenGL: the only option for cross-platform 3D programming.
        - OpenAL: the only option for cross-platform spatial sound
                  programming. It also handles regular sound files.
        - STL: the only option for cross platform C++ library.
        - SDL: non invasive set of cross platform functions to handle
               input devices, video initialization, etc. We are not
               to use all the facilities it provides (for instance
               OpenAL will be prefered for sound). However, using it
               for input devices is the best way to go because it is
               the most mature part of SDL and releaves us from the
               tedious work of deciding which symbols to use for keyboard
               events.
        - Single Unix Specification Version 3: although all platforms
          do not comply to these specifications, refering to it prevents
          the obvious mistakes of relying on a feature that is specific
          to a given platform. Rather than making sure the program 
          stricly comply, it is used to discard system calls or features
          that are not part of the specification.
        - OpenOffice: whenever a word processor might be used for 
                      documentation, relying on OpenOffice ensures
                      everyone is able to edit them, regardless of
                      the platform used.

        On top of that we may use whatever proves convienient at the
time such as OpenSceneGraph http://www.openscenegraph.org/, NGL/NUI
http://nongnu.org/projects/ngl/ ... Tapping in the large number of
Free Software projects providing solutions for specific problems may
save time or become a burden, depending on the maturity of the project
and the skills of the people using them. Finding the proper equilibrum
is kind of hard and we should be flexible. The only criterion for
chosing a software or the other is that it complies (or can be
modified to comply) with the components above (C++, Python, ...).

        Idealy underware would only be a set of dependencies to other
tools that provide all the features needed to develop our 3D online
games. Note that I say "our" and not "any". Providing generic and
flexible solutions belongs to the underlying components, not to
underware. We won't avoid writing specific code to cope with missing
bits. However, we will avoid at all cost to attempt a generic
implementation within underware. For instance, we are likely to define
a set of Python functions to ease the writing of gameplay scripts. We
won't attempt to write a generic gameplay scripting language. We will
keep it as specific as possible. Even if we strongly resist to a
natural tendancy to overgeneralize, we will have a hard time replacing
our specific bits with more generic ones when they become available.
It would be a lot worse if we spent a significant amount of work to
generalize some parts.

        I hope all this is making sense. Comments and criticisms are
wellcom so that I don't bootstrap myself on false ideas.

        Cheers,

-- 
Donate to FSF France online : http://rate.affero.net/fsffrance/
Loic Dachary, 12 bd Magenta, 75010 Paris. Tel: 33 1 42 45 07 97      
http://www.fsffrance.org/   http://www.dachary.org/loic/gpg.txt