This is how I have my shortcuts set up, in both Visual Studio (VS) and Visual Studio Code (VS Code). The setup will require some tweaking to get the same results in both editors.

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.

In the process of development it's important to stay on the cutting edge and be aware of how things are developing in our profession. Recently I've been researching one particular game dev code module. There were numerous open source solutions online, so I thought it would be good to start from there as rewriting from scratch seemed a bit excessive.

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 article has been inspired by a recent show on Channel 9, which presents design patterns. While these have been around for a long time and certainly have had great influence on how we write code, the implementation can actually get more lightweight in modern programming languages such as C# and recent Java.