There’s no question that the
for loop is a good idea, but events are much more complex. They’re enshrined into C# by the
event keyword, but not everything about them is good. Today’s article shows some considerations you should take into account when deciding whether or not to use an event. Bonus: it includes some little extension methods to make using events and delegates easier!
Posts Tagged event
There’s no question that the
One of the biggest source of bugs in our apps is state: all of that persistent data we keep around in memory. When things change we need to make sure to update all of it at the right times and with the right new parts of the state that changed. Inevitably things get out of sync and our app is in “a bad state”. Today’s article discusses some ways we can prune the “graph” of objects that we create in OOP so that there’s less state to maintain. Read on for some interesting techniques that could help you prevent bugs!
Callbacks are a mainstay of the real-time games and apps we build in Unity. We’re constantly writing asynchronous code for every operation from walking a character to a destination to making a web call. It’s really convenient for these functions to “call back” and report their status so we know how the operation is going. Unfortunately there are also a lot of dangers that come along with this. Today we’ll look into the surprisingly large number of ways you can “call back” in C# and some of the ways you can get burned doing so.
A lot of times we want to take some action when a value changes. If the player’s level increases I want to play a “ding” sound effect. If a player loses health points I want the screen to flash red. Today we introduce
Observable<T>: an easy way to track these value changes. Read on for the source code and examples!
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
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 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!
Unity’s garbage collector can be disastrous to our games’ framrates when it runs so we’d best not incur its wrath. We’ve seen that
foreach loops usually create garbage, so the natural followup question is “what other language features create garbage?” Events and delegates are extremely handy features of C#. They serve as the function pointers and
Function objects of the language. They replace signals and slots and allow for flexible callbacks. But a lot of what they do is behind the scenes. Are they creating garbage back there? Today’s article puts them to the test to see if creating and calling delegates and events creates any garbage. Read on to find out!
As mentioned in last week’s article on the “pure code” approach to Unity code design, capturing events can be problematic. I gave an example of how this could be overcome, but didn’t flesh it out to cover the sixty events that a
MonoBehaviour can receive. Today’s article includes the source code for a class that does just that. It should prove useful to anyone interested in exploring “pure code” design.
Chances are you’ve been bitten by the
ErrorEvent class at some point while programming AS3. It’s the asynchronous equivalent to
Error and it happens when, for example, a
Loader‘s load fails. If you write any code that performs an asynchronous task, perhaps more file loading, you too may want a way to inform users of your class that the task has failed. Just like with
Event, it’s nice to be able to add data on to the standard
ErrorEvent class. How does this work? Let’s dig in and find out.
I was reminded about the flash.sampler API by Grant Skinner’s recent post about it. While only available in the debug player, it can still tell us some valuable information about what goes on in the release player. Today I’m using the getSize function to find out how much memory overhead various classes impose, even when they are empty.