Building Bases And Facilities

[reist]

I've been slowly moving all code that needs message boxes to python, sometimes only event handlers, sometimes a full class (e.g. Transactions). When I'll finish, the MessageBox and MessageBoxes classes are history.

 

Currently I'm looking at facility and base creation code. It's spread between baseview (almost none), earthpane (passing the blame around) and baseviewrenderer (almost all).

That's right, the renderers handle pretty much all base logic

Of course, such code is not the prettiest either.

 

I'll be moving all of this to python as this:

- BaseBuilder - responsible for base creation and facility construction.

- One(1) function handling earth pane events and calling BaseBuilder to continue it's work if BaseBuilder is active.

 

Does anyone have comments, ideas, objections?

[Beetle]

Oh come on, baseviewrenderer is handling facility building mode switching and caluclating from on screen coords into in game one. All other job is done by HumanBase class

[reist]

Well, I've looked there because I'm moving out code with lots of message boxes there, but...

It's a renderer. It should render and give back base coordinates. Game logic shouldn't be there at all.

I do have a longer explanations with reasons why moving the logic out is better.

Edited February 27, 2006 by reist

[red knight]

Renderers render, game logic should be in other layer. I support such kinds of moves, however reist, please specify how are you going to do it.

 

Greetings

Red Knight

[reist]

Alright. Here goes...

First, the current code to create a base (which is not complete, btw):

* Baseview - the button handler. Sets some state in EarthPane and closes.

* EarthPane - mouse click handler. Handles normal mouse clicks and base creation ones, in which case it waits for the user to choose a spot, asks for the name and creates a base with access at (0,0).

 

Code to create/destroy facilities and destroy bases:

* Baseview:

** mouse clicked/moved handlers and facility destroy button handler: passed to BaseviewRenderer.

** facility create button handler: runs choose facility dialog, sets state in BaseviewRenderer and passes control to it.

* BaseviewRenderer:

** 3 states: full base, zoomed in on a facility, building state.

** mouse clicked: split between three state, huge if-then-else tree that can create facilities and show message boxes.

** mouse moved: works only when in building state. Marks the current area.

** facility destroy: also takes care of destroying bases.

 

What I'm going to do is:

* Move EarthPane's handler to python and make it pass control to a new python class - BaseBuilder - when building a new base, which will be known to BaseBuilder, not anyone else.

* Converge all handlers having to do with facilities and bases in BaseBuilder.

** The math/rendering code happening in the handlers will be split into functions to be called from BaseBuilder.

** Facility choosing will be done by asking for coordinates from BaseviewRenderer and asking it to zoom to that area.

** To remove the remaining BaseviewRenderer zoom out/zoom states, create a boost function pointer to the right function - initialPickFacility or switchPickFacility.

** Register/unregister the mouse moved handler as needed instead of listening to it all the time.

** Add the ability to choose where to put the base access (with this structure, it's a very simple change)

After this, the only handlers in Baseview will be for switching bases, R&D and watching base information.

The handler for renaming a base is already in python, but could be moved back if it will be possible to rename by pressing the displayed current name and changing it.

EarthPane and BaseviewRenderer won't have any handlers at all.

 

The only issue I didn't yet think of is what to do with the demo base creation code in BaseviewRenderer?

Move it to BaseBuilder? baseview.py? Some other place?

[red knight]

Sounds good, If it is a demo base, move it to Python code in a DemoInitializer so we can have all demo state in just one place. The state set should be done via the BaseBuilder methods though.

 

Greetings

Red Knight

[reist]

Do you mean the zoom in/zoom out state? Why? The two functions that switch in BaseviewRenderer and a pickedFacility field should be enough without saving a state. pickedFacility is really all that's needed to show that there is a state at all.

Or did you mean building/not building state? That's going to be in BaseBuilder only anyway.

[Beetle]

The only issue I didn't yet think of is what to do with the demo base creation code in BaseviewRenderer?

Move it to BaseBuilder? baseview.py? Some other place?

 

Becouse nobody still didn't move it away from there . Of corse it should be in some sort of start game in player method, but there wasn't such a method at a creation time

 

About your ideas, yes they are much prettier to me , but (there is always some but ) maybe it's better to move forward. This changes will require quite much of work from your side that you could spend on something else , but if you want to do it, i don't have anything against (espescially that i'm very busy with my RL now )

[reist]

Don't think so. I've been working on it these couple of days. I'm already pretty close to finishing it

Anyway, this'll make that part of the code more flexible, so anything not yet done in the base view will be easier to do. I think that's good enough.

[red knight]

Just as a side note to both, do not overengineer... always go for the simpliest way, most of the time Python for game logic is cool, but think that some stuff (mostly the model) have to be in C++.

 

Greetings

Red Knight

[UnFleshed One]

(Nothing is complete without a bug report )

 

Why do I have a feeling that all that python stuff works by the means of throwing exceptions around?

 

Anyway. A click on empty space in baseview throws this exception:

XENOCIDE_EXCEPT("Trying to get facility that doesn't exist! pos:" + boost::lexical_cast<String>(px) + ", " + boost::lexical_cast<String>(py));

in

HumanFacility::SharedPtr HumanBase::getFacility(Sint px, Sint py)

[reist]

Seems I missed this when converting to python... <_>

Shouldn't be a problem to fix.