In my last article about Finite State Machines (FSM) for Unity, I showed a “pure code” way to create a state machine, states, and transitions between those states. It worked, but I wanted to create a simpler system. I’ll show you it today!
Posts Tagged pure code
This article shows you how to remove events from the MV-C design pattern to make it simpler to understand, safer to use, and faster to execute. It’s a step-by-step lesson in refactoring. Start by reading the MV-C article, then read on!
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!
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!
One apparent downside to the “pure code” approach to Unity app code design is that it makes less use of the Unity Editor. Because it only uses one main MonoBehaviour, there aren’t a lot of MonoBehaviour classes that can be modified by the Inspector panel- a mainstay in Unity design and debugging. Today’s article introduces another kind of auxiliary MonoBehaviour to work around this issue enabling you to use the “pure code” approach without sacrificing the Inspector panel.