- Home /
Game Architecture in Unity
What is the most common and natural approach to game architecture for Unity? I'm new to this technology as well as to game development, though have some experience at desktop application development on .NET. But I cannot find out how to apply this experience to development on Unity in the right way.
In usual programming one controls application's entry point, can set up IoC container, service locator, instantiate some managers, controllers, view models, providers, factories, and so on. What is the counterpart in Unity?
How to decouple logic from presentation? How to organize definitions of reusable classes in the Unity project tree, where should instantiate them? What additional entities should involve? What patterns should I use?
Does it make sense to use .NET events or Rx instead of performing all in update()
function?
I have already read some topics such as this, but have not found any convincing examples.
Excuse my messy questions and poor English. Thanks in advance!
Answer by doug · Dec 15, 2011 at 06:07 PM
Unity is a great platform for prototyping.
It has a good workflow for importing content, and it's relatively easy to bind logic to objects and group objects into scenes to make a demo.
However, that tends to mean that the quality of the code in the tutorials on the net tends to be very low, and basically prototype quality only.
Speaking to people who are writing serious code in Unity and reading around it seem the best solution is to build a set of mono assemblies (ie. .dll's) that encapsulate the game logic, along with unit tests, etc. for that code then link your dlls to the mono project and have very light weight MonoBehaviour objects that simply inherit from the assembly code.
Its kind of helpful to think of it almost like a web app; the core logic must take place on the server side, and the graphical fluff can happen inside the frontend, with the associated baby-sitting to make it all work.
Hope that helps.