Last week’s article showed a technique that you can use to abstract the Unity engine so that you can test code that uses it. Today’s article presents another technique that allows you to remove this abstraction layer so your game code is faster and more natural. Read on to learn how!
Search Results
How do you write unit tests for code that uses the Unity engine to play sounds, make web calls, or render graphics? Today’s article shows one solution!
Sometimes we write code that’s meant to be run outside of the Unity engine. This could be anything from unit tests being run in MonoDevelop or Visual Studio to shared code that’s used on a multiplayer server. Regardless, the Unity engine isn’t available for use unless you’re running in the editor or a deployed build. This means you’ll have problems whenever you access the Unity engine via Debug.Log, GameObject, or MonoBehaviour. Today’s article shares some quick tips that enable you to tweak your code so that you can detect whether the Unity engine is available for use. Read on to learn how!
Last year I introduced a Unity-based model-view-controller (MVC) design pattern and in the many comments on that article, a theme arose. The “model” part of MVC is arguably not necessary since Unity stores so much of the data itself. Today’s article takes that theme and elaborates on it to create and introduce a new Unity-specific design pattern. Read on to see how this adaptation of MVC works!
By request, today’s article follows up on my Unity Function Performance article from a year and a half ago using Unity 5.0. It adds on GameObject.SendMessage and virtual functions to get a more complete picture of how various function calls in Unity perform. Of course it runs these tests using Unity 5.4 to see if there have been any changes in the engine. Read on for the results!
When writing code for a library, there is invariably some of it you want to hide from the users of the library. You want to keep the public API clean, but Unity makes this tough. Today’s article discusses a strategy for laying out your code so that users of the library aren’t burdened by classes, functions, and properties that they don’t need to know about. Read on to see how!
Unity programmers have their choice of two kinds of events. We could use the built-in C# event keyword or Unity’s UnityEvent classes. Which is faster? Which one creates more garbage? Today’s article finds out!
One of the advantages of Unity using Mono and IL2CPP as scripting engines is that any .NET language can be used to code your game or app. Today I’ll show an example of that in the form of F#. How do you go about using an unofficially supported language like this? Read on to for the step-by-step tutorial!
Today’s article introduces a small but capable and extensible finite state machine (FSM) that you can use to organize your Unity applications’ code. FSMs are commonly used to represent the different modes the app can be in—main menu, world map, gameplay, game over—and how the app transitions from one state to another. The FSM in today’s article follows the pure code methodology by not tying the code to game objects, MonoBehaviours, or scenes. So read on to learn about and make use of this “pure code” FSM for Unity!
What do you do if you want to use the Model-View-Controller (MVC) design pattern in your Unity app but you don’t want to use a framework like StrangeIoC? With a little thinking about the problem I think I’ve come up with a simple yet effective pattern to follow that doesn’t require you to use any framework. In today’s article I’ll talk about each part, how the parts fit together, and how you can use MVC to cleanly organize your “pure code” app. Whether you’re an MVC newbie or just want to see a new take on MVC in Unity, you’re sure to learn something today!