Re: Documentation about Crimson Architecture?

[Jens Granseuer <jensgr@xxxxxxx>]

On 08.01.2005 10:19, Sascha Flohr wrote:
> On Fr, 2005-01-07 at 17:29 +0000, Jens Granseuer wrote:
> He misses the regard of different heights for units. Now you can not fly
> over your own units (or drive underneath). He is apparently in the fear
> of loosing his copters in our current fight :-)

Please also see this thread for the discussion I had with Dave about this
topic some time back:
http://archives.seul.org/crimson/users/Feb-2004/msg00025.html
My opinion on this hasn't changed since then, but it seems Dave's has
which makes me happy ;-)

> > Unfortunately, no, there is currently no design document but if you like
> > I can give you a short tour of the most important parts (though that'll
> 
> That would be a great thing.

File structure:

src/cf/      - stuff used by crimson
src/comet/   - stuff used by comet (and some of the tools in tools/)
src/common/  - stuff used by both crimson and comet

Ideally there would be much more files in common/ but I made a few
not so smart choices when starting with CoMET and haven't had the
motivation to correct this afterwards.

To understand why some parts of the engine look like they do, a
little bit of history is probably helpful (and might make it a
little less embarrassing for me). CF originally started out as a
project to learn C++ (and OO in general). I had been coding in C
for some time, but it was my first venture into OO land and in
certain parts it still shows. Most of these are pretty low-level
and not very well encapsulated so they would require a significant
amount of work to refactor which is why I mostly haven't bothered
to do anything about it.

With that out of the way let's start the tour.

The most basic class from an application's POV is the View
(common/view.cpp) which represents the display surface and is
responsible for managing the windows and the input events.
Nothing is ever directly drawn to the View. This is what Windows
(common/window.cpp) are for. Windows are stackable Surfaces
(common/surface.cpp, basically just a wrapper for SDL_Surface)
that can be attached to the View, drawn to, and blitted to the
display. There are several specialized Window subclasses (e.g.
DialogWindow, MapWindow, FileWindow), many of them in
common/extwindow.cpp.

Windows can contain Widgets (common/widget.cpp), e.g. buttons
(common/button.cpp), sliders (common/slider.cpp), or checkboxes
(also in common/button.cpp). This concept isn't handled as
strictly as I would like, e.g. widget labels and images are
no widgets themselves and have to placed and drawn individually.

You can attach callback objects (WidgetHook, common/widget.h)
to any widget that get notified when the widget is activated
(what this means depends on the widget; some widgets are
read-only and cannot be activated at all). There is also a
CompositeWidget so you can treat multiple widgets as a single
one.

As you can see, most of the user interface stuff is shared
between crimson and comet.

With regard to the game mechanics the central class is the
Game (cf/game.cpp). This is where most of the game logic
resides, and it also is the controller for most of the user
interaction (the great WidgetHook if you like). The other
game related classes (cf/mission.cpp, cf/player.cpp,
cf/event.cpp, cf/unit.cpp...) are mostly just data containers
(although this is one area where separation between model and
controller could be improved).

I'd say we've covered most of the basics now. If you still
have questions feel free to ask.

> Perhaps adding a few words about in what
> direction do you want to go technically (features and such) with the
> engine.

Well, CF has never really had a fixed agenda, and most of what we
have today has been the result of a gradual process where someone
proposed this, someone else chimed in with that, there was a little
discussion (or not), and then it was or wasn't added.

The main points I'd like to improve on are listed in the TODO
but that list is neither exhaustive nor does it represent any kind
of final goals for a 1.0 version. The major list item when talking
about engine features is without a doubt support for network play.

Jens