For all Unity developers and developers-to-be, both beginners and professionals!
Before I left on my vacation I was pushing towards getting a playable prototype up and running. In the midst of this it started to dawn on me that the code base was becoming unwieldy and difficult to manage.
Posted by Kelso on Nov 18th, 2012
That's right - I'm back.
Before I left on my vacation I was pushing towards getting a playable prototype up and running. In the midst of this it started to dawn on me that the code base was becoming unwieldy and difficult to manage. When I started delving deeper and found three separate places where I was serializing data into a Vector3 array I knew it was time to get out the broom.
So I started massively overhauling everything. This - generally - involved ripping all the old code out and then replacing and rewriting it in chunks in a new project. I've managed to organize all the calls to load data when the game is started into a single manager which makes catching errors much easier. I was also able to add in some features that I had wanted but that got swept by the wayside. Namely among these was some cross-reference validation. So now the game will tell you when - for example - you've assigned an armor to a unit that doesn't exist; or you've told a weapon to use a damage type that doesn't exist. Also to that end - one of the things that I found frustrating in older moddable games (namely on the SAGE engine) is that their damage types were hardcoded enums inside the engine. We're not doing that. Damage types are just another data file so everyone will be able to declare as many of them as they want instead of the dark ages of shoe-horning weapon requirements into a set list of damage types.
I also decided to rethink how we were developing UI screens. Previously - elements were declared layer-by-layer. What I wanted to do was make the coding process more intuitive as well as making some of the features more robust. So I went with a model that looks more like an HTML web page and let the engine determine what elements were drawn on top of others (ie elements nested inside other elements are drawn on top of their parents - like you would expect when writing HTML). The new framework also uses a fair bit of reflection to hook up button functions to instructions within the engine. So whenever I add new methods to the UI framework they should just work when writing screens.
Do you have any other ideas for UI features you'd like to see? Leave them in the comments!