Personal Update:

Busy week! We bought bikes for the family and I'm teaching the kiddo how to ride. We had some car trouble where the front wheel well was smoking terribly and we had to get it towed and repaired (leaky pump dropping coolant onto the wheel). And I should be getting to the quarter-round trim soon in order to finish the laminate floor installation. And my free AutoSave Asset finally got published:
https://www.assetstore.unity3d.com/en/#!/content/43605

I'm happy I shared an early version for the Week of Awesome III. Otherwise it would have been far too late. Also, as of the writing of this, the Check Engine light came on in my other vehicle. >.<

Game Update:

This week, I started working on my "overland" movement system. It's called overland because originally I was thinking of a medieval travelling merchant game and I couldn't think of a better name. I may change Overland to Solar or Space. Anyway... I now have planets being randomly positioned, and the player can send his ship around on the map. Currently, you can only choose to go to a planet, but in the future, I'll be letting the player select deep space locations, intercept other ships, etc. As the player moves, there's a random chance that he gets jumped by a pirate scout which triggers the battle scene.



I'm debating on whether or not to go with a more realistic layout of the solar map. Like have a star in the center, and let the planets travel an orbit path very slowly each turn. Or something like I have now where planets, star ports, and other interesting things are just scattered about. My original grand idea was on the more realistic side. Planets orbit the star, moons orbit the planet, space stations orbit any of these. There's definite cool factor there, but a single solar system might have over 200 meaningful places to dock. When I'm planning to allow the player to travel between star systems, it's a little overwhelming. Lately, I've been enjoying some more abstract games with text popups describing different scenarios, so I'm leaning that way. I'm also thinking about going with 2d sprites instead of 3d models.

Next week I plan to focus on learning Unity's UI system. I need better user feedback on the selection of units, and I also want to offer the user choices during their random encounters. Hopeuflly I'll get a simple system in place for that. I also want to work on cleaning up my Game State management and look at different screen transitions.

Unity Gotchas:

Unity does not like how I setup my objects, or i'm just doing it wrong. Case in point, my ship configuration works like this:
I have a ShipParentController that dynamically loads game objects for the Hull (physical/visible/game stats), the GhostModel (for indicating planned movement), and the GameObjectCanvas for the health bar. To spawn a particular ShipConfiguration, you just have to set a ShipConfigurationName and then in Start() it loads everything up and sets some local reference variables to the child objects. No big deal yet... But when I create a random encounter, I generate an enemy ship by picking a ShipConfigurationName and passing the ShipParentController to the BattleSystem. The problem is that the BattleSystem is expecting those child objects to already be loaded but the ShipParentController.Start() hasn't been called yet. I guess I just can't treat the Start() function like a constructor.

I ran into similar issues when I have game objects start out disabled in Unity. Setting a GameObject to Active doesn't run Awake or Start right when you turn it on. Unity has to do an Update cycle first to call these. Then after that, all my child objects are loaded up nice and neat. I was mainly doing this to avoid GetComponent/GetChildComponent() calls in Update code so my performance didn't go to crap. And I prefer to do this dynamic wiring up rather than using the Inspector to wire up my Child objects because when I refactor code by changing the name of a field, it breaks much more cleanly.

I'm an old Object Oriented Programming vet so it's taking some adjusting to shift my mental paradigm over to a Component Entity System. I hacked together some things just so I could "finish" for the week and get things working, but I'm not happy with the current state of the code. I think I'm going to have to move my initialization code into my own function with a flag. Anytime I need to create a new object, I'll have to run the initialization code myself and the function will set a flag to say it's Initialized.

I'm also still a little fuzzy on scene changes. Right now, I don't have separate Scenes. Since I'll have so much data to go from overland to battle and back again. LoadSceneAdditive did not seem like the wise choice. I just have the relevant objects childed to an OverlandScreen and BattleScreen GameObject and I disable/enable when I'm switching scenes. I have a zoomed out orthographic camera for the Overland screen. And a zoomed in, perspective camera for the Battle screen. Both are AudioListeners which is one problem, and the other is that the OverlandScreen and BattleScreen are turning each other on and off. I think I'm going to need a GameStateController for Screen changing, and I'm going to need to separate out my AudioListener to follow around the currently active camera.

Tons to do!