Feedback on non-game based architecture

First a quick background.
I am a senior developer with over 15 years experience(Java, Javascript AS3) OUTSIDE OF Unity. But only intermediate level C# developer. Still so much to learn!
So I thought I’d share a brief description of my most recent project, a network connected video ad player, and see if more experienced C# Unity devs could provide some feedback

From my experience building AS based apps I still prefer to use some form of MVC, at the very least separating responsibility between ‘view based’ classes that control actual appearance and movement of Game Objects, and Model or proxy classes, which have no physical counter part in terms of Game Objects and often act as sort of inputs to getting data from out side the application.
So in the case of my Ad playing application I have 3 ‘Model’ or ‘Proxy’ non-MonoBehaviour classes defined as Singletons.
One is a ‘Config’ or ‘Startup’ proxy that is responsible for loading a .cfg file and controlling any customizable application settings.
Another is a ‘TCP Server’ proxy which listens to a specific port for a signal to start the application.

And a 3rd is a 'OSC" proxy which receives OSC data from another application. In this class I also have a precise 30 second count down timer using System.Timers.Timer to determine when the ad is complete.

The entry point for my Application is a calls I call of course ‘Main’ and is defined as a MonoBehaviour.
From Main I get instances of my proxy Singletons.
If any Proxy class needs to know about another one, I pass an instance of it to the Model class that needs it also in Main.

I make use of an Event manager which acts as a sort of central clearing house for creating listeners as well as many custom ‘Event’ classes.

In general the Proxy or Model Classes communicate with the rest of the application via these custom events

I also have what I describe as a ‘FrontController’ similra to what I think game developers would describe as a ‘game manager’ It is responsible for receiving events from the Model calsses, performing some logic, and then directly manipulating any View or Game Object classes it has knowledge of.

I don’t avoid threads although I know they can be problematic. For instance in System.Timers.Timer and also in the TCPServer I make use of the widely available ‘UnityThreads’ class which simplifies using threads in a Unity application. My understanding is that threads are a ‘good thing’ that can only help with application performance, but perhaps I am wrong!

Anyways, these are the broad strokes! Any feedback on the above greatly appreciated!

So I’ll start by saying… same here, I started out in AS3 and what not. Flash was a lot of fun back then!

On to your description…

I don’t understand why these 'model’s need to be Singletons. Why use a pattern as restricting like that if they aren’t necessary. Especially since you said “If any Proxy class needs to know about another one, I pass an instance of it to the Model class that needs it also in Main.”… ok, so again, why is it a Singleton?

Also… the models don’t seem like models at all, and more like controllers. Especially since you’re saying that the other things react to it, rather than it reacting to other things.

I also don’t know where the View and Controller is here (the controller usually being the one that manipulates the others).

Like usually it’s:

Model - represents the data that is to be manipulated

View - displays the Model, more than 1 View may exist for a single Model… for example a line graph as well as a spreadsheet

Controller - interrupts events/user interaction to manipulate the data in the Model

Thanks. Controller in my case would be the FrontController class. View classes would be Monobehaviour classes attached to GameObjects visible in your scene. For convenience sake I would also make the FrontController a MonoBehavior so I could simple drag references of any gamobjects it needs to be aware of to the Inspector.
No, the Proxy or Model classes as described don’t have to be Singletons, it just makes more sense to me and is a preference. There should never be more than a single instance of any Proxy-Model.

If you are familiar with PureMVC the FrontController could also be likened to a Mediator, although it contains more code logic to handle any data sent by Proxy-Models before manipulating the view classes. BTW, are u by any chance familiar with or have used this CSharpNext plugin? https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration/src

Looks very cool…hope to use more C#4,5,6 features in my next project!

I’m familiar with Alexzzzz’s work on that project.

I personally don’t use it. It adds another layer of possible bugs that I don’t want to have to chase down. I stick to officially supported compiler services to avoid any headaches.

It’s nice for toying with, but not implementing in production code.

With that said, Unity is currently beta testing its own upgrade of the C# language version in the latest builds of Unity, with plans of putting them into official release soon. And sometime in the future even upgrading the framework (finally!). Once they’ve hammered out their bugs, then I will start using them, as I can be sure the community and support options out there are all on the same page rather than having to go it alone.

1 Like