Unity3D is a powerful suite of tools (Project IDE, Code IDE, run-time) for game development. In Unity3D Game Architectures I present six different techniques for setting up your game. Depending on the size and maturity of your team, you are probably doing some form of those. I recommend checking that article out first, then read below. In Unity3D MVCS Architectures: StrangeIoC (recommended reading before continuing) we dove deep into the great, free framework. I also explored an idea I had for an extension called PropertyChangeSignal. Here is more;

PropertyChangeSignal

To aid my work with StrangeIoC, I created a few classes that function together to reduce the workload. I call this the PropertyChangeSignal. Again we saw above that signals are used for many things. Speaking from a model’s perspective for every property (variable) you want to update in your model you may need SEVERAL signals. That is fine in my demo above with exactly one property, but imagine a ScoreModel with 5 variables, a TimerModel with 3, and a GameLogicModel with 25 more variables. You can quickly grow a HUGE list of signals. Now, creating a signal is super quick. It takes 30 seconds to create, and another 30 seconds to optionally bind it to a Command. Its certainly possible to grow your app in this conventional way (or some variety of this conventional way). Most people do exactly that. But I wanted a start a discussion on a different way.

Here is an example.

Let’s say we have a public message string in your data model and the whole app needs to interact with it.

A. Conventional Signals Per Property (4)

• 1. requestMessageSignal.Dispatch() – If a mediator arrives on the scene late and wants to KNOW the current value of message.
• 2. clearMessageSignal.Dispatch(targetValue) – If a command wants to CLEAR the current value of message.
• 3. updateMessageSignal.Dispatch(targetValue) – If a command wants to SET current value of message.
• 4. updatedMessageSignal.Dispatch(newValue) – After any updates happen, the model sends this out to those listening who can GET the value.

B. PropertyChangeSignals Per Property (1)

• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.REQUEST) )
• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.CLEAR) )
• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.UPDATE, newValue) )
• 1. pcSignal.Dispatch (new PropertySignalVO(PropertyChangeType.UPDATED, currentValue) )

So in B, we see far less signals used (1 vs 4), but an longer syntax for the call. Soon I’ll request your feedback based on the source-code.

Update:  Download the full source below.

Syntax Example

1. CONTEXT – SETUP BINDING

[actionscript3]

commandBinder.Bind<GameListPropertyChangeSignal>().To<GameListPropertyChangeCommmand>();

[/actionscript3]

2. COMMAND – HANDLE BINDING

[actionscript3]
public override void Execute()
{

switch (propertyChangeSignalVO.propertyChangeType) {

case PropertyChangeType.CLEAR:
//ASK TO CLEAR THE MODEL
iCustomModel.doClearGameList();
break;
case PropertyChangeType.UPDATE:
//ASK TO UPDATE A VALUE IN THE MODEL
iCustomModel.gameList = propertyChangeSignalVO.value as List<string>;
break;
case PropertyChangeType.UPDATED:
//FOR THIS PROJECT, THE VIEW LISTENS DIRECTLY TO ‘UPDATED’
//OPTIONALLY, WE COULD ALSO DO SOMETHING HERE IF NEEDED
break;
case PropertyChangeType.REQUEST:
//FORCE THE MODEL TO RE-SEND ‘UPDATED’ (WITH NO CHANGE)
//THIS IS VERY COMMON IN APPS (E.G. A TEMPORARY A DIALOG PROMPT)
iCustomModel.doRefreshGameList();
break;
default:
#pragma warning disable 0162
throw new SwitchStatementException(propertyChangeSignalVO.propertyChangeType.ToString());
break;
#pragma warning restore 0162

}

}

[/actionscript3]

3. MODEL – DISPATCH CHANGES
[actionscript3]
private List<string> _gameList;
public List<string> gameList
{
get
{
return _gameList;
}
set
{
//TODO: CONSIDER ALTERNATIVE THAT CHECKS "_gameList != value" BEFORE DISPATCHING
_gameList = value;
gameListPropertyChangeSignal.Dispatch (new PropertyChangeSignalVO(PropertyChangeType.UPDATED, _gameList) );
}
}

[/actionscript3]

4. VIEW – HANDLE CHANGES
[actionscript3]
private void _onGameListPropertyChangeSignal (PropertyChangeSignalVO aPropertyChangeSignalVO)
{
if (aPropertyChangeSignalVO.propertyChangeType == PropertyChangeType.UPDATED) {

doRenderLayout(aPropertyChangeSignalVO.value as List<string>);

}
}

[/actionscript3]

Video

[tubepress video=”87903532″]

Member Resources

Members can access the full source-code for this post. Membership is free.

[private_Free member]Enjoy this members-only content!

• Download Source-code ( StrangeIoCTemplate2 )

[/private_Free member]

Unity3D is a powerful suite of tools (Project IDE, Code IDE, run-time) for game development. In Unity3D Game Architectures I present six different techniques for setting up your game. Depending on the size and maturity of your team, you are probably doing some form of those. I recommend checking that article out first, then read below.

The Strange IoC Template

I consulted for years with PureMVC. From that, a spiritual successor with dependency injection was born as Robotlegs (RL). RL became my default choice for many projects. I’ve used both within the last year. Depending on client preferences. To share with the world a simple, consistent, starter project I created and shared a Template for PureMVC and a Template for RobotLegs. I continue that same ‘template idea’ for the article here. There is no popular version of those for Unity, until now. StrangeIoC is a fantastic, free implementation of Robotlegs plus Signals. Signals for C# comes from separate project available in other programming languages which replaces the standard use of Events dispatched often through a central Event Bus. The benefits of Signals are well known, but not everyone prefers them. I do prefer them, so my template exclusively includes Signals instead of Events. You can do either or both in StrangeIoC. You can play the unshockingly unsexy demo here, and then read about the internals here in the article, with full source-code (See ‘Members Resources’ below).

Table of Contents

1. What is StrangeIoC?
2. My StrangeIoC Template
3. My PropertyChangeSignal Extension for StrangeIoC

---

1. What is StrangeIoC?

Strange is a super-lightweight and highly extensible Inversion-of-Control (IoC) framework, written specifically for C# and Unity. The StrangeIoC team has validated Strange on web, standalone, and iOS (currently testing on Android).

StrangeIoC includes;

• IoC through Dependency Injection
• Choice of Signals and/or Events (with 2 styles of EventBus)
• MonoBehaviour mediation
• Optional MVCS (Model/View/Controller/Service) structure
• Multiple contexts (parts of your app can ‘care for themselves’ if desired)
• And much more…

Pros:

• Public, Community-driven, well-documented. (e.g. You can hire/contract a new developer who arrives with this skill on day 1)
• Decoupled, testable, & D.R.Y.
• Scales-up well for large teams, large projects

Cons:

• Slower to setup (but faster to add last-minute changes)
• Steeper learning curve, especially for junior developers
• Demands discipline/know-how from your team to put logic in its proper place (but removes the ‘where should we put that code?’ decision process)

---

2. My StrangeIoC Template

While the MVCS setup for Strange is optional, it is my preference. To understand the template. It is absolutely necessary to understand the fundamentals before digging into my source-code. For those familiar with MVCS, the learning curve is very quick. For those familiar with Robotlegs, you are in luck, the creators of Strange have a special “Introduction to Strange for Robotlegs Users“. I haven’t read that, but in general the Strange documentation is very well written, light (fun?), and relevant.

Figure 3. StrangeIOC Template Diagram

Figure 4. StrangeIOC Template Console

Pros:

• Together with this article, I hope it the template is a GREAT way for you to learn StrangeIoC
• Coming from PureMVC or Robotlegs? (Download and compare the similar templates for PureMVC and RobotLegs)
• Intuitive for beginners, e.g. “Bowling-pin code goes on the bowling-pin”

Cons:

• My style is just ONE way to use StrangeIOC. Every team should learn their own style.
• It is a very, very simple example (this is also ‘pro’)
• My Unity3D/C# coding standards are NOT the official Microsoft way. Ha!

Video

Part of the Unity With Cocktails video training series,  this video covers the “My StrangeIoC Template” section of this article. While the purpose and definition of MVCS is not explicitly included, there is some related tidbits in there. Also we see the ‘5 major steps’ in setting up StrangeIoC. 

[tubepress video=”82322606″]

More Info on MVCS

For the uninitiated to MVCS, let’s dig in! There is tons of info online so I’ll keep this section light (fun?). The basic idea is that you purposefully separate you coding stuff (‘coding concerns’) into 4 distinct areas which are discussed below. If the app doesn’t talk to any backend servers, you don’t need the service. So you often see the same basic structure described as MVC. But we’ll use MVCS just to be comprehensive.  So, looking at the diagram (Figure 3.) we can see some major areas of the application. The layout of this diagram mimic like the StrangeIOC Official Diagram above (Figure 2.). MVCS (for laymans)

• Model – “I hold ALL of the data, ha ha ha.”
• View – “Hey, look at this” (graphics, gui, sound) and “Oh, you clicked the mouse” (input), “Either way I’ll tell the controller about it”.
• Controller – “Hey Model (or Service), someone clicked a button so do X or Y”, or “Service, you loaded? Ok, I’ll tell the model”, or “Thanks Model for the updated data, I’ll tell the view to show that”.
• Services – “Welcome everyone, I’m going to just load stuff from offline files and online servers and tell the controller”.

Sample Orchestration: Clicking the Load Button Orchestration is my term for one ‘trip’ through some part of the MVCS for a specific purpose. Here we go from a button click to data storage and back to update the screen. We’ll step through the numbers from the console output (see Figure 4.). From View To Model Starting with the view (1), the user clicks the button in the UI, and the UI holding the button tells its paired mediator about it. The mediator sends a message (dispatches a signal which is mapped already to a command) and a command is executed (2). The command knows what needs to be done (a.k.a. business logic) and in this case that means to tell the service to load data from a local file (3). When the service finishes loading (4), its sends a message (dispatches a signal which is mapped already to a command), and a command is executed (5) which knows to put the freshly loaded data from the service into the model (6). From Model to View Continuing on, the model updates its internal data storage and then sends a message which anyone who cares can listen to. In this case the mediator is listening (7) and knows to update the UI.

Its important to note that while data started in the service and was passed around a bit before finally landing in the model, that – its the model that STORES the data as a class variable. The other data is temporary variables and they go away quickly. Its like wires that hold electricity temporarily but really only the battery STORES the electricity.

That sounds like a lot of steps. Yes it is. And for each ‘button’ or feature you add to the app you do something similar. However, very early in the learning curve you will both a) get fast at adding new features and b) see the benefits of mvcs.

---

3. PropertyChangeSignal

To aid my work with StrangeIoC, I created a few classes that function together to reduce the workload. I call this the PropertyChangeSignal. It helps to streamline your workflow in data-heavy applications where you need signals for data events such as REQUEST, CLEAR, UPDATE, and notify upon UPDATED.

Update: The complete article “Unity3D MVCS Architectures: StrangeIoC 2 PropertyChangeSignal” is ready. Check it out!

---

What’s next?

Want to learn something more basic? Or are you ready for more advanced topics about UnityEngine and C#? Checkout my “Unity With Cocktails” HD Tutorial Video Series on C# and Unity.

Member Resources

Members can access the full source-code for this post. Membership is free.

[private_Free member]Enjoy this members-only content!

• Download Source-code ( StrangeIoCTemplate )

[/private_Free member]

What are your thoughts?

Do you prefer an alternative to the suggestions above? Or do you have an additional recommendation? Please comment below. [polldaddy poll=7611650]

Unity is a powerful suite of tools (Project IDE, Code IDE, run-time) for game development.

I have explored many architectural approaches to game projects. Architecture is a hot topic in Unity — especially related to scaling up to larger Unity game projects.

My architectural background includes many frameworks. Highlights include heavy usage of Robotlegs (I event contributed to the project and drew the official diagram), PureMVC (I was the technical editor for the O’Reilly book on it), and PushButton (I published related articles for Adobe). I also presented and taught about the three at conferences and weekend workshops. Of these, only PushButton is a game-specific architecture, but all can be applied to games.

What are the qualities of a good gaming architecture? Most architects applaud solutions which are flexible, readable, D.R.Y., testable, orthogonal, and “refactorable” (at an acceptable cost). I will discuss the philosophy of design in a future post, but for now I simply list the major pros and cons of each approach.

Unity3D Bowling

What are the qualities of a good gaming architecture? Solutions which are flexible, readable, D.R.Y., testable, orthogonal, and “refactorable” (at an acceptable cost). I will discuss the philosophy of design in a future post, but for now, I simply list the major pros and cons of each approach.

I review some common approaches and a few novel ones. For each, there are images, details, and an example with full source-code (See ‘Members Resources’ below).

Table of Contents

1. No Manager
2. EmptyGO
3. SimpleGameManager
4. uMom
5. Custom MVCS
6. StrangeIoC

---

1. No Manager

This is your most basic approach. First-time Unity-developers often start with this technique. Here you put bowling ball code on the bowling ball, bowling pin code on the bowling pin, and ‘game win vs game loss’ code on something random, like the bowling ball too.

Because Unity’s ‘component-based’ approach is so intrinsically awesome (reusable code ‘components’ sit on 1 or more GameObject ‘entities’) you can indeed get very far using this approach. If you are coming from a hierarchical approach to gaming, learning the component-approach can be a challenge and your first projects may be of this ‘No Manager’ approach here in #1 or soon evolve to the ‘EmptyGO’ approach we see below in #2.

Diagram

Hierarchy

Type: Component-based

Pros:

• There are MANY free, useful tutorials created using this “No Manager” approach. So its easier to learn the basics of Unity this way.
• Flexibility for prototyping
• Intuitive for beginners, e.g. “Bowling-pin code goes on the bowling-pin”

Cons:

• It is the very definition of spaghetti code
• Very low scalability for teams (of 3 or more)
• Very low scalability for projects of intermediate or high complexity.

---

2. EmptyGO

This is a slight evolution beyond #1 above. Still you put bowling ball code on the bowling ball, bowling pin code on the bowling pin, BUT you try now to put all the rest of code which has no visual representation in the world onto an invisible or ’empty’ GameObject (GO). Hence the name ‘EmptyGO’.

This technique still has alot of drawbacks, but at least we begin to see game logic more centralized (on that EmptyGO). This aids readability for newbies working on your project, or for you after you return to an older project after a long time. You don’t need to hunt around everywhere to find your core code — most sits there on the EmptyGO.

Diagram

Hierarchy

Type: Component-based

Pros:

• More readable (than #1 above)
• Good mix of flexibility for prototyping (yet not AS much spaghetti code as #1 above)
• Intuitive for beginners, e.g. “Bowling-pin code goes on the bowling-pin”

Cons:

• Less testable
• Less refactorable (since less code is likely to be properly abstracted, decoupled, and reusable when compared to 3,4,5,6 below)
• Communication and referencing between GameObjects is likely too brittle (e.g. using GameObject.Find() or inspector target references)

---

3. SimpleGameManager

Probably the most mature technique which is in WIDE usage within the free tutorials and sample projects you find in the community is something like my SimpleGameManager technique. Imagine the ‘EmptyGO’ from #2 above, but now its a persistent (between scenes) Singleton.

Code still exists directly the GameObjects in the world, but whenever possible it calls centralized code [e.g. ‘SimpleGameManager.Instance.playSound (“GunShot”); ] Its a good approach and an appropriate (simple) solution for many small projects.

Diagram

Hierarchy

Type: Component-based w/ Manager

Pros:

• Ultra-fast setup (but with minimal functionality). Its more of a racetrack — where YOU must supply the race-cars.
• Persists between scenes, and if its not created it will create itself as soon as it is referenced (because its a Singleton).
• Ideal for prototypes (but thus not scalable)

Cons:

• Its not plug-and-play per say. The current workflow is to import the package and EDIT the core class, rather than use/extend.
• Not D.R.Y.
• Less testable. Much of your code STILL sits around on various GameObjects (like in 1 & 2 above).

Sample Game

• Coins And Platforms (Play The Game, View Video, Download Full Source-Code)

---

4. uMOM

My (unreleased) uMOM Asset Store project arose from a problem inherent in Unity. There is no default Main.main() type ‘hook’ to centralize the entry into your run-time and no default way for UI and code to persist from scene to scene. This was the genesis of the Unity Manager of Managers (uMOM), pronounced as /you-mom/. You can read more at the uMOM Dev Diary and see the status of the project (it has some issues). Here is a short summary of purpose and benefits;

The uMOM package allows developers to add one or many reusable, custom manager classes to the project. Each ‘start’ automatically, have a predictable life-cycle (reset, add, update, remove), optionally receive ‘update()’ calls, optionally run during edit mode, and optionally persist between scenes. Managers operate as singletons and can easily address each other to collaborate.

Types of uMOM Managers: Really anything is possible, but here is the short list of use cases I will address first. Use some of mine or none of mine – then create your own. Most any existing manager class you have can easily be converted for compatibility here. 

• uEventManager -Streamline messaging between classes. Replace the need for Unity’s clunky ‘SendMessage’ and instead dispatch strongly typed objects. (The uEventManager will also be available separately).
• Store references to audio clips (drag-n-drop) and control audio playback via C# from one place.
• GUIManager – Layout UI which optionally persists between scenes. Centralize the controls to handle clicks, etc…
• PoolManager – Optimize your run-time performance by persisting GameObject or prefab instances in RAM and displaying them as needed.
• LevelManager – Queue up levels and perform transitions (e.g. fade-in-out) between them.
• GameManager – While other managers are not project specific, this one likely is. Here you manage the core game mechanics, how the user wins and loses, store the score, etc…
• SaveManager: Takes care of saving and loading user preferences and achievements.
• MenuManager: Controls all menus, managing their animations, their contents, and their behaviors. Perhaps it heavily uses the GUIManager for layout.
• Much, much, more…

Diagram

Hierarchy

Type: Component-based w/ Manager

Note: The images and source-code for this architecture are not yet available.

Pros:

• Reuse code between projects. That is probably its greatest strength. Ultra fast to setup with mucho out-of-the-box functionality. Nice GUI!
• Have global access (also a con) to managers which are decoupled by discipline (GUIManager, LevelManager, AudioManager, etc…) each with a common interface and life-cycle.
• Scalable to large teams such as 4-10 developers (but may require more planning upfront and dedicated team members creating the managers vs. those using the managers)

Cons:

• The benefits of MVCS separation are not implicit ( but are possible ).
• More scalable to complex games than 1,2,3 above, but far less than 6 below.
• Still in alpha with bugs which prevent production-readiness.

---

5. uMVCS

For non-game projects, such as data-driven applications, there is a clear favorite in architectures; the Model-View-Controller-Service (MVCS or MVC). For the uninitiated, its where you separate your code into 4 areas; the data, the user interface, the core functionality, and any calls to/from backend-servers. It seems like OVERKILL at first, but once one is well-practiced he/she can drop in a template (e.g. Unity Package) and in 5 minutes  be ready to rock.

The “uMVCS” is a ultra-light framework I created myself. Its one of many, many setups for MVCS. I created recently, from scratch in just few hours for ACADEMIC PURPOSES ONLY. It is not complete and scalable like other implementations, but if you have never touched MVCS before, its a great way to learn.

Diagram

Hierarchy

Type: MVCS

Note: The images and source-code for this architecture are not yet available.

Pros:

• Great for learning
• Uses a custom event-dispatcher implementation of the observer pattern for decoupled communication from any scope to any scope.
• Heavy use of Singletons (also a con) allows access to the ‘architecture’ from any coding scope.

Cons:

• Purposefully incomplete, it exists just to help newbies learn about code-separation with MVCS.
• No command-pattern.
• I created it in 90 minutes. Ha.

---

6. StrangeIoC

Here we add to organizational benefits of MVCS the ease-of-development feature called inversion of control (IoC). To learn more. Here is the official Strange diagram of the MVCS overview and the StrangeIoC website.

Diagram

Hierarchy

Type: MVCS w/ IoC

Note: The source-code for this architecture is available below. It works great, but upon clicking to restart it breaks. Still working on that. Have a solution? Download the source and comment below this post. Please!

Note: Updated! Now see my complete article on StrangeIoC For Unity3D

Pros:

• Public, Community-driven, well-documented. (e.g. You can hire/contract a new developer who arrives with this skill on day 1)
• More decoupled, testable, & D.R.Y.
• Scales-up well for large teams, large projects

Cons:

• Slower to setup (but faster to add last-minute changes)
• Steeper learning curve, especially for junior developers
• Demands discipline/know-how from your team to put logic in its proper place (but removes the ‘where should we put that code?’ decision process)

Sample Game

• Spider Strike 3D (Play The Game, View Video, Download Full Source-Code)
• Paddle Soccer 2D (Play The Game, View Video, Download Full Source-Code)

---

What’s next?

Want to learn something more basic? Or are you ready for more advanced topics about UnityEngine and C#? Checkout my “Unity With Cocktails” HD Tutorial Video Series on C# and Unity.

Member Resources

[private_Free member]Enjoy this members-only content!

• Download Bowling Game source-code (1. No Manager )
• Download Bowling Game source-code (2. EmptyGO )
• Download Bowling Game source-code (3. SimpleGameManager )
• Download Bowling Game source-code (6. StrangeIoC )
• Update: April 2014 – I don’t think any more source will be added to this post, until I add a new architecture to the list some day.

[/private_Free member]

What are your thoughts?

Do you prefer an alternative to the suggestions above? Or do you have an additional recommendation? Please comment below.

[polldaddy poll=7611650]