The main player-facing changes here are the rebalancing of fuel and power.
Fuel costs have been halved so that your fleet size is not almost always capped by Fuel, but sometimes by Science.
Power costs themselves are unchanged, but spending science on power-consuming units now gives you a galaxy-wide +% boost to power production. So if you have Planet A which naturally produces 1000 power, and Planet B which naturally produces 1500 power, spending 1000 science on turret techs increases Planet A’s power output by 100 and Planet B’s by 150. This allows you to invest in “thicker” defense rather than only in more diverse defense.
More changes are needed in both areas, of course. Please let us know what you think.
On the non-player-facing side, there’s the huge addition of letting modders attach custom data to the xml records that form the meat of the game definitions. So you can add custom external constants, or custom fields to map types or AI types or ship types or whatever. These use a namespace system similar to the External Data you can attach to in-game objects, so that different mods don’t stomp on each other.
Keith here. Sorry I haven’t been keeping things up to date over here. I’ve mainly been doing release notes on the wiki, the forum, and the other blog, and I was only dimly aware of this one.
So, to summarize the releases in the last 40-ish days, we:
* Completely redid the build and tech menus with fancy icons and sub-icons and keyboard navigation.
* Replaced the text-heavy unit-mouseover-tooltip with a mostly icon-based display, and this glorified “tooltip” has tooltips of its own!
* Spent an unfortunate amount of time handling the platform-bug fallout from updating to a new version of unity (to address a unity developer-side security issue).
* Added an in-game settings menu and moved the settings definitions themselves out to external xml so modders can add their own settings (community member BadgerBadger is already hard at work using that to transform the map-type selection process into something horrifyingly more powerful).
* Made it possible to scale your ui if you want the gui to use a different percentage of your available screen area. Especially useful for large monitors.
* Constructed an “external data” framework that allows modders to attach arbitrary data directly to ships, factions, planets, and the gamestate-as-a-whole, and to correctly persist that data across saving and loading the game.
* Endured absurdity (largely of my own making) for hours and hours convincing the build process to allow us to rename System.XML.dll to System.Xml.dll to un-break the linux build, and finding that the OSX build required a radically different version of UnityEngine.dll.
* Provided some heavy-duty power tools for controlling your fleets, specifically rally commands to automatically forward replacement units to your fleets, active selections to automatically select those reinforcements when they arrive, and moddable formation algorithms to automatically arrange your ships in relation to each other when you give a move order.
* Put in actual models for several existing ship types and finally made squads form up in interesting shapes.
And quite a bit more (updated Badger’s Nanocaust faction, added some new Galaxy Display Modes from the same, fixed a bunch of bugs, etc)
The key quality-of-life improvements, in no particular order, are:
– You can now choose to start with the first planet already under your control, and thus skip that first battle that tended to be the same.
– Turrets and similar structures that you build now leave remains that you can rebuild, similar to AIWC. Not having to manually re-place turrets after every significant defense is very nice.
– Tech costs and various other numbers are now rounded to not be weird values like 1199 (instead 1200, in that case).
– BadgerBadger’s “Find Planet” function has been integrated. Thanks Badger!
– BadgetBadger’s improved campaign-based save/load system has been integrated. Thanks Badger! (I keep finding myself saying that) The structure of the campaign data is likely to change to something more robust before 1.0, but this is a definite step in the right direction.
Up next is more of the same troubleshooting: finding the trouble that gets in the way of the game being fun, and shooting it. For now I’m focusing on my own testing as it’s a tighter feedback loop in many ways, but that will be broadening out.