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?
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).
- 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…
- 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
- 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.
- 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”
- 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!
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.Vimeo responded to TubePress with an error: Not Found
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.
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!
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.
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 )