At the start of every term, we try to get new students who are working at the DALI Lab onboarded. There's a lot to learn: the DALI Lab project process, design skills, development skills, team skills, and how to collaborate properly using git, slack, etc.
Usually we have a new member orientation which consists of an overview of the lab process and a team building hacktivity (which I'll write about later). However, last term in addition to the orientation we also introduced specific workshops to help with this onboarding.
The goal for this specific workshop was to get both designers and developers up to speed with coding collaboratively. CS classes at Dartmouth by and large don't teach any git flow or much about code version control, so I had to think about how to go through a lot of material quickly, yet enable everyone to feel comfortable with working together on some basic coding.
Coroutines are awesome. If you aren't familiar with them (particularly in the context of Unity3d) then you should be. In short, coroutines are methods that can suspend and resume execution. In the context of Unity what this means is that you can have methods that appear to run concurrently. Coroutines are **the** way to script a lot of things in Unity, however there are a few problems that you may run into if you use them heavily: exception handling, return values, and locking. Especially if you use nested coroutines! Here are some ways to extend coroutines to fix some of these issues.
I had a previous post about singletons in Unity3D and have since added a useful functionality to that class. One of the useful features of a singleton is that it is self instantiating. But what if you want to use the Unity editor to expose some public variables and have some other assets hooked into your singleton? So since you are probably using prefabs to manage game components in your scenes anyway, seems like it might be useful to have a self-loading prefab for components such as the player or a gui controller.
In Unity3D having a singleton class is very useful, whether for "global" state or simply for the convenience of having a static accessor so you don't have to have lots of: <code>FindObjectOfType(typeof(Builder)) as Builder;</code>
So you code up a C# singleton and then realize that you actually need it to be a MonoBehavior, not just a ScriptableObject -- say you want the singleton to run coroutines, or have a transform, or any other MonoBehavior feature. But monobehaviors can't be initialized with a constructor. So what you want is a monobehavior pseudo singleton pattern.
