Advertisement
robn

Pioneer: Savefiles, player decoupling and core event system

Jan 10th, 2015
232
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.88 KB | None | 0 0
  1. From: Robert Norris
  2. To: pioneer-dev@pioneerspacesim.net
  3. Subject: Progress on savefiles, player decoupling and a core event system
  4. Date: Friday, June 28, 2013 5:57 PM
  5.  
  6. Just because its been quiet this month I thought I'd note down a few
  7. things I've been working on. Work has been smashing me so I've had very
  8. little brain available for Pioneer work but I have managed to write a
  9. few lines of code every day this week, which is a bit nice!
  10.  
  11. I was working on the new savefile code, and got a nice structure set up
  12. for instantiating objects from clean or from a savefile, and then
  13. calling an Init function to complete the rest of the initialisation. Its
  14. something between the Init() functions we have around now and
  15. PostLoadFixup() - it completes object initialisation including pointers
  16. to other objects.
  17.  
  18. But that got really complicated in ModelBody, Ship and Player because
  19. they expect to be able to effectively re-initialise the entire object
  20. when the player buys a new ship. The code ended up very fragile and
  21. non-obvious - lots of different initialisation fragments that did
  22. different things. Very hard to keep the whole lot in your head.
  23.  
  24. So I decided then that first I needed to decouple the Player object from
  25. the rest of Body hierarchy. The Player will become an object that holds
  26. player state (like money, rank, etc) and then has a pointer to the Ship,
  27. the Controller, and so on. So then swapping the ship should be as easy
  28. as removing the old one from space, destroying it, instaniating a new
  29. one, adding it to space, and pointing the Player at it.
  30.  
  31. To do that though I need to kill some of the old code in Player. There's
  32. some screwy stuff in there, mostly to handle the fact that a Player has
  33. UI and sound stuff that a Ship doesn't. There's no good places to move
  34. the code to, so I started doing something I've been thinking about for a
  35. long time, which is to create an eventing system in the core.
  36.  
  37. That's a rather grand description of what it actually is though. See my
  38. post on pioneer-dev. There's a GameEvents object attached to the Game,
  39. which has a bunch of sigc::signals in it. Various interested parties
  40. (mostly ShipCpanel and a new GameSound class so far) attach to signals
  41. and do stuff when they come in. Its conceptually identical to Lua events
  42. and indeed, my intent is to make Lua events run on top of them. See the
  43. robn/game-events branch for details.
  44.  
  45. Once its fleshed out properly I should have most of the painful stuff
  46. out of Player, and I can go back to detaching player and making the Body
  47. tree "non-resettable".
  48.  
  49. And then savefiles will be easy .. until the next thing comes along, of
  50. course ;)
  51.  
  52. The annoying thing about all of this its going to change the Lua
  53. interface a bit. Game.player will now refer to the player object, not to
  54. the player's ship. Some of the events might change. I'm not sure what's
  55. going to happen yet.
  56.  
  57. That's all. Lets see where this goes :)
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement