Progress: Day Eleven. Signals or Messenging in Unity / C#, the battle between modularity and performance.

A busy busy week of paying rent - was this week past, and it is this moment that we take the time to reflect on those who didn't make it to Sunday.
Free time *hold for applause*
Energy and enthusiasm *hold for applause*
x-hundred dollars for a one-use suit *hold for applause*


Yes, it's been one of THOSE weeks - a week of fulfilling the old 'non-optional social obligations'.


But rest assured, my dear friend - that you have always, always been in my mind. And with that, allow me to give you a rundown on what we have been doing in Unity and C# this week.

Signals and Messenging.

This week I was quite concerned with developing a small framework that would handle the management of states and variables between objects in the gameworld.

This framework had to fulfill a handful of contradictory requirements:

• Modularity / Abstraction
• I would prefer this framework to be applicable to ANY game design scenario, to allow reuse in the future.
• HOWEVER the issue with this is that it extends the due-date of a deliverable. Working on frameworks is fine, BUT it must be actually used to make something. Keep on the straight and narrow.
• Efficiency
• Obviously, for iPhone, efficiency is key. So the elimination of un-necessary function calls is key.
• Small memory footprint
• I believe the iPhone has something around the 43meg memory mark for an application, which means that we want to eliminate sprawling data structures and retain memory for graphics and sound.

Unfortunately, these are relatively contradictory - as modularity and abstraction usually increase the memory footprint of a program and decrease (slightly) it's efficiency.

I understand this is an arguable statement without qualification, but it is generally correct.

We can try though, can we not?


So here is a breakdown of how the game object code is put together:

There are four main classes in the Game Object:

• Event
• An event is an action that is performed in the gameworld.
• It may be user input (key down), or an internally-initiated event (game object-to-game object).
• As the result of an event, one of many variables may be altered, and one or many states may be changed.
• E.g: Key down - jumping = true, gravity = 20.0f, something = false and so forth.
  
• Variable
• A variable is set as a result of an event.
• It may be the value of the input (axis value) or a predefined value (eg: speed += 10)
  
• State
• A state is a true/false indicator that the game object is in a given state (eg: jumping).
• A state is evaluated either per Update() or upon state change, and will trigger one or many actions.
  
• Action
• An action is initiated when the game object is in a given state
• An action has a lifespan that is internally defined and regulated
• Upon completion, and action will revert given states and set given variables (through the use of an event).
• The Action is the core of all gameplay-specific logic - all gameplay is contained in actions.

So this is the core of the state management logic - as all gameplay feeds from a common repository of variables, communication between gameplay elements can happen in a relatively transparent manner.

I have some very nice graphical examples to include later - stay tuned.