glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Re: I am taking upon the task as to redesign the map e


From: Stéphane Magnenat
Subject: Re: [glob2-devel] Re: I am taking upon the task as to redesign the map editor
Date: Mon, 17 Apr 2006 11:28:25 +0200
User-agent: KMail/1.9.1

> I'm considering moving the DrawMap and DrawMiniMap code from Game into
> libgag widgets, which would be a logical start.

Yes. But I would move the drawing only part to a drawer helper class that, at 
first, can be used from the game directly without the need to port all game 
gui code to libgag. Then a widget which uses this drawer will be done and 
used in the new map editor which will be based on libgag widgets. Once this 
is done and tested, we might change the game gui to libgag.

The drawer will have some state such as the viewport and wether the lines, 
accessibility things, etc.. must be shown. Those state must be easily 
accessible from outside.

> After that, I might seperate out GamePanel, which draw the transparent
> background for the side and top panels. The DrawMiniMap would fit
> snugly into this, hopefully.

Please note that there is already a GUIMapPreview widget which might be a good 
base for the minimap.

> Then I would make a set of graphic buttons for what goes under the
> minimap, and these buttons would swap hide/show other panels, such as
> ChooseBuilding, or GameStatistics. Further more, GameStatistics could
> be devided into a generic Statistics widget which would be provided a
> reference to a vector which would hold the current statistics.
>
> Buildings and flags could be done using a GraphicalRadioButton type
> widget, which is a set of buttons of which only one can be selected at
> a time, and this could then be reused in the MapEditor.

A normal TextButton can already have graphics. But if you want to make a 
graphics only button, faire enough.

> The "zones" however pose a particular problem in the widget system,
> however. I think the only possibility would be three widgets, a
> ZoneType, ZoneAddOrRemove, and BrushShapeChooser widgets, which we
> could use boost::function to provide callbacks in which we would tie
> them together in the main program.

Well, we should have a graphical check box widget. Then we should add the 
possibility to group check box together such as activating one disable 
others.

> As a side note, boost::function makes a very convient way to provide
> callback type interface without virtual functions, which would allow
> are wigets to be used dynamically.

Problem is that in the gui, you typicall want to associate to the callback a 
method in a certain instance of object (such as MapEdit). The Qt style signal 
and slot are nice for this. Libgag's actual solution is an old-fashioned one 
with a general callback and some standardised parameters. It has the 
advantage of being easy to understand, fast to compile and easy to debug. But 
it's not very nice. As far as I remember boost has signal/slot mechanism.

Just one comment : beware over engineering ;-)

> I think it might all be do-able using libgag, although it would take
> allot more work than seems nesseccary just to re-write the map editor.

Yes. So I strongly suggest not touching the in game gui for now, only putting 
drawer in a separate class, and only make clean libgag-based map editor. This 
will also give us experience of potential problem of this method. We can 
always change the game gui to libgag later.

Steph




reply via email to

[Prev in Thread] Current Thread [Next in Thread]