As the codebase grows, pains of bad practices accumulate. The fact that production gets slower with more code, is a sure sign there are abundant bad practices in the project. Eliminating all the impedance - the crud - will increase the speed to the point where production speed accumulates. Although counter-intuitive, this speedup comes from code re-use and established working pipeline.

Recently I've been working with Unity UI, and its event system. This system is seemingly user-friendly in the sense that components have event fields where we put scripts that will do the work. This is already off-standard (bad practice): the GUI button should not be bound to the logic that it does. Instead, something else that does the logic should subscribe to the event of the button, and that thing that does the work should have a field to know which button it takes events from. In that way we can have reusable UI prefabs that are unrelated to any logic. 

I just found a piece of code that demonstrates what I'm talking about in these series. This is from Unity's standard assets, I somehow imported this old version with some asset for testing, and it started throwing errors. Looking in, this is what I've found.

Recently I was working on a rebindable input system for my upcoming game Disturbancy. I've discovered many interesting properties that emerge when working with inputs and controls, but I will share one.

This article is a personal opinion on the different use cases related to fields and properties. We all know that fields are data holders without logic, while properties look like fields from the user's point of view, but actually execute a method, usually storing/retrieving data from a backing field.

I have recently started using ReorderableList element. I've had to implement some kind of 'list of lists' and would like to share my ideas about improvements.

Recently I've had to implement a very high performance component that required treating elements of an array differently based on their type. All the elements were put into a generic list of base types, and the method operating on the elements had to behave completely differently based on the exact type. Generally, this is a typical example where polymorphic behavior should be considered, the subclasses could override a base method and do the operation themselves. This was not an option in my case for certain architectural reasons.

This is a command line calculator program, serving to demonstrate OOP and TDD concepts. Calculator forms token trees and evaluates them recursively. 

This is a small collection of simple tools to help in scene editing workflows. Duplicating, parenting and renaming are a big part of what we do when editing scenes, so it is worth automating as much as possible. All shortcuts are relevant for Windows systems.

Unity 5.5 ships with NUnit 2.6. It is accessible through the Window menu, Editor Test Runner. The documentation on NUnit 2 is good, but admittedly isn't very accessible. I will provide my collection of most important attributes and assertions, also with my comments (taken at the time of Unity 5.5 release), saving you the trouble of having to click through the whole documentation. My comments are shown in italic.