Since their introduction in part 7, support for C++ MonoBehaviour messages has always been a special case. The reason for this was that we didn’t have good enough support for what I’m calling “factory functions.” These are functions like GameObject.AddComponent<T> that instantiate a generic type. This week we’ll go over why that support was lacking, what was done to fix it, and how the new system works.
Posts Tagged monobehaviour
The series continues this week by addressing a pretty important issue. Previously, we were limited to doing all our work in just two C++ functions: PluginMain and PluginUpdate. This isn’t at all the normal way to work in Unity. It’d be a lot more natural to write our code in MonoBehaviour classes. So today we’ll come up with some tricks to allow us to write our MonoBehaviour code in C++ so we are truly scripting in C++.
At first glance an Updater class seems unnecessary in Unity. All you have to do is inherit from MonoBehaviour and add an Update function. But what if you don’t want to inherit from MonoBehaviour? Enter Updater, an easy way to still get an update event and cut your dependency on MonoBehaviour. This works great for code in DLLs, “pure code” projects, or just projects that don’t want to put everything into MonoBehaviours. Read on for the source code and how to use it!
Unity apps are structured very strangely. They’re a lot different than Flash or standalone apps and definitely take some time to get used to. Today’s article is an introduction to how a Unity app’s code is structured from the perspective of a Flash developer. It should give a basic understanding of where your code goes and how the basic architecture of a Unity app looks.