...and that is exactly what I will do. Unity Game Logic Visualisation Tool.

Kinda.

As briefly mentioned in the last post, I would ideally like to create an extension for the Unity Editor to visualise State Management in a friendly, easy-to-manage fashion.

I am currently working on a large-scale project in a rent-paying fashion, utilizing State management and synchronization between many clients and a master server (using the model outlined in the previous post) but the large number of active states, and the manner in which they are natively displayed in Unity, makes maintenance and development extremely difficult and time-consuming.

The design model itself is good, I believe. It's abstract and modular, but management of the game logic is tricky.

To test this theory, I wrote the Plane game (I'm calling it Gyro now, previously Airborne) in a purely 'dev-styled' manner. All code, no States. But it quickly became obvious that things that are achievable utilizing states are much trickier in a straight-forward class-and-code fashion; especially given Unity's event-driven model.

And thus we are back where we started, with an issue: management of many many States, Actions and Entities.

And so I present a very small, very primitive initial overview of my State Management Extension for Unity.

In eight easy screenshots....

(Easy maybe. Copy - mspaint - paste - copy to: file - open that file - save as - jpeg - repeat. Damn man.)

State Management - in the Window menu.

 

The Spartan State Management Window - Note the currently-empty Hierarchy.

 

 A project has been created, and the State Management window will now default to inspect it.

Note that the project has appeared as the parent node in the hierarchy, and it currently has No Entities.

Creating another Entity. Note that the Entity Plane has been created already.

GUIDs are generated to uniquely identify components from the server, and the client if required.

Adding a Function to Entity Plane.

Functions are basically a container for States and Actions in the Hierarchy, to keep them logically ordered and observable.

 

Inside the Plane Entity, with Function Engine added. Note that No States or Actions have been added. 

 

 Adding a State to the Engine Function. Note the types of State available (enumerated and expandable) and the value field, which changes according to State type.

 

Plane, Engine - Speed State has now been added, all existant in the Hierarchy for use in game logic.

So that's what I've been working on. We'll see how it goes. There's always a point of hesitation in working on any form of workflow-improving mechanism:

Is the cost of improvement less than the savings that the improvement will bring?

Or is the improvement redundant?

And a minor update on Gyro, prev: Airborne - I've put together a little app that I will publish once it's pretty (e.g: has a skybox and trees) so that the public can tweak and test my plane control scheme in a manner that you like. It will upload the scheme to my online database (ooooh, there's a story to tell there) and we'll be good to go.

Out.