Pioneer: Savefiles, player decoupling and core event system

From: Robert Norris
To: [email protected]
Subject: Progress on savefiles, player decoupling and a core event system
Date: Friday, June 28, 2013 5:57 PM

Just because its been quiet this month I thought I'd note down a few
things I've been working on. Work has been smashing me so I've had very
little brain available for Pioneer work but I have managed to write a
few lines of code every day this week, which is a bit nice!

I was working on the new savefile code, and got a nice structure set up
for instantiating objects from clean or from a savefile, and then
calling an Init function to complete the rest of the initialisation. Its
something between the Init() functions we have around now and
PostLoadFixup() - it completes object initialisation including pointers
to other objects.

But that got really complicated in ModelBody, Ship and Player because
they expect to be able to effectively re-initialise the entire object
when the player buys a new ship. The code ended up very fragile and
non-obvious - lots of different initialisation fragments that did
different things. Very hard to keep the whole lot in your head.

So I decided then that first I needed to decouple the Player object from
the rest of Body hierarchy. The Player will become an object that holds
player state (like money, rank, etc) and then has a pointer to the Ship,
the Controller, and so on. So then swapping the ship should be as easy
as removing the old one from space, destroying it, instaniating a new
one, adding it to space, and pointing the Player at it.

To do that though I need to kill some of the old code in Player. There's
some screwy stuff in there, mostly to handle the fact that a Player has
UI and sound stuff that a Ship doesn't. There's no good places to move
the code to, so I started doing something I've been thinking about for a
long time, which is to create an eventing system in the core.

That's a rather grand description of what it actually is though. See my
post on pioneer-dev. There's a GameEvents object attached to the Game,
which has a bunch of sigc::signals in it. Various interested parties
(mostly ShipCpanel and a new GameSound class so far) attach to signals
and do stuff when they come in. Its conceptually identical to Lua events
and indeed, my intent is to make Lua events run on top of them. See the
robn/game-events branch for details.

Once its fleshed out properly I should have most of the painful stuff
out of Player, and I can go back to detaching player and making the Body
tree "non-resettable".

And then savefiles will be easy .. until the next thing comes along, of
course ;)

The annoying thing about all of this its going to change the Lua
interface a bit. Game.player will now refer to the player object, not to
the player's ship. Some of the events might change. I'm not sure what's
going to happen yet.

That's all. Lets see where this goes :)