For all Unity developers and developers-to-be, both beginners and professionals!

Report article RSS Feed Kelso: The Return - Part 1

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.

Revamped UI System

Do you have any other ideas for UI features you'd like to see? Leave them in the comments!

  
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Established
Oct 31, 2010
Privacy
Public
Subscription
Open to all members
Homepage
Unity3d.com
Contact
Send Message
Email
Members Only
Membership
Join this group
Group Watch
Track this group
News
Browse
News
Report Abuse
Report article
Related Games
Fractured State
Fractured State Indie Single & Multiplayer Real Time Strategy
Related Engines
Unity
Unity Commercial Released May 30, 2005
Related Groups
Indie Devs
Indie Devs Hobbies & Interests group with 1,047 members
Mechanical Monocle
Mechanical Monocle Developer & Publisher with 3 members
Unity devs
Unity devs Hobbies & Interests group with 1,069 members