I know how much you all love dense technical jargon about boring-but-necessary coding tasks that don’t really advance the progress of the game, so here’s some. Of that.
Seriously, you might as well just skip this post, it’s gonna be dull. You were warned!
I’m currently finishing up a task that I started back in 0.6.1: unifying the UI Stat Dictionary with the Simulation Stat Dictionary. Until now, we’ve had two separate dictionaries: the UI one was handling things like describing and displaying stats (translating “47 attack damage” to “mostly harmless” or “-0.68 diet” to “herbivore”), as well as populating those horrifying stat dropdowns in the Rover settings. Meanwhile, the Simulation’s stat dictionary handles things like creating and determining stat values based on genes and environmental variables.
This isn’t a major deal, but it was enough to make keeping them synchronized annoying whenever I add a new stat, because I invariably forget to add it to one or the other and then have to deal with exceptions further down the track. I still don’t actually have a “Diet” or “Attack Damage” stat in the Simulation’s Stat Dictionary. The game’s been computing them on the fly.
So I’m killing the UI Stat Dictionary and transferring all of it’s functions to the Simulation one.
After that, I’m looking at ways to clean up the UIManager class. It has around 9000 lines of code, and is exactly as much of a mess as “9000 lines of code in one file” would imply.
Around a thousand of those lines belongs to the aforementioned UI stat dictionary.
Another 5000 or so of that is dedicated to simply defining the UI: the positions, types, starting values, ranges and so on of every 2D Control on every screen in the game. This is usually the sort of thing you’d build a tool to generate, but I typed each of those lines out by hand because I’m an idiot who thought once I had the simulation working, the UI would be easy. Afterall, it’s only 2D sprites! How hard can it be?
One of the major tasks for this update is to take all of that, drag it out into external files (probably either *.cfg, or *.xml, I haven’t decided which yet), and restructure the remaining code to read as elegantly as possible from those files.
I have some interesting idea’s for this as well, including separate dictionaries for each type of control (simply so I don’t have to cast the base class “Control” to “Label” or “ValueSpinner” or “ComboBox” or whatever the control actually is every. damn. time), as well as using either Unit Tests or a pre-compilation pass to detect typo’s in the string keys to make debugging easier.
And after those, I want to transfer the Simulation Stat Dictionary to external files. At first, this will just be data storage: text files for names, descriptions, and things like each individual stat’s mutation rate, maximum/minimum bounds, etc.
Further down the track, I’d also like to transfer the actual calculations for each stat into these files, in Lua format. This might require some reformatting, and probably some optimisation as well (it’s doubtful Lua could match the performance of native .Net code, so I may have to experiment with a hybrid system which only uses Lua for modded stats) but it would give modders a chance to read and play with with the fundamental calculations that define the simulation.
This would also require the long-overdue upgrade to something later than VS2008, so I could use .Net 4.0.
Not sure if this will happen for 0.9.0, but it’s on the table. I’ll keep you informed.
And after all (or at least some) of that is done, then we’ll get to move on to the fun stuff. 🙂