Miscellaneous
This page lists some of the small random projects I wrote.
Unity Password Manager & Android Keychain
These are two little libraries I want to mention together since they are really related one-to-one, meaning I would never have written one, without the other. As part of my LastPass-Unity library I needed to write a module that simulated keychain like behaviour on Android devices. Since Android does not provide such functionality out of the box, I really needed to roll my own.
So I wrote a native Android (Java, why not Kotlin!? Good question! Great opportunity to use Kotlin again… derp.) plugin to provide access to the Android shared preferences from Unity. Together with Androids built-in crypthoragphy functions we should now be able to, in some sense, simulate keychain like behaviour.
Next I created a Unity3D abstraction that exposes easy access to this plugin and published it as a separate package as well since I thought it would be useful to other people.
UniJect
Uniject started as an experiment of how a Dependency Injection (DI) framework should work in Unity3D. I did some research and found several frameworks including of course; Zenject. Reading through Zenject’s massive README file I wondered why it should be this complex.
Yeah I know, Zenject is a large project that does way more than simply injecting dependencies. It also supports mocking during testing for example.
Also, a thing I often scratch my hear for is that DI frameworks depend heavily upon these builder patterns for injecting dependencies. This is a common design in many DI frameworks like Zenject, Dagger(2), Unity. The reason for using the builder patterns is that they are compile-time solutions and not runtime/reflection based solutions. The compile-time builders will definitely have greater performance than the runtime solutions. Also, you get full support of the compiler for DI, which you do not have with the runtime solutions, and support on all target platforms. I do not think the builder patterns at compile time is bad design, but to me it just feels like moving the dependencies to another place and accessing them through the builders. I think, in many cases, a DI framework should not be used if you can reach the same goal by simple constructor/method injection. That being said, DI should be used in a number of strategic places to inject for example; object factories.
Lessons Learned
- For Unity3D field and property injection make the most sense. Writing this library I did not think someone would gain much benefit from method and constructor injection. I hinted at this in the previous section; I think DI must be used in a few strategic places and I think field and property injection will be enough to achieve this.
- You quickly end up with many resolver types and objects which might be confusing.
- The C# compiler does not allow me to add LINQ queries as arguments for Attributes. This is a mayor bummer since it kind of beats the purpose of the component injections. (Now you need to write an entirely new class that creates the query, you could also just run the query in for example the Awake() of the component.)
- Playing around with C# reflection feels like one big hack. Yet it was A LOT of fun and I leared a great deal from it!
Univent-Bus
I started this little project after a discussion I had with an old coleague about how to properly break dependencies between modules in a real-time system. I gave him the classical component based approach but this just didn’t fit his needs and he was totally right. He came up with an alternative himself.
He’s a massive Quake 3 fan and he can really geek out about the game’s architecture. A core piece in the Quake 3 arhcitecture is this event-bus. So he just wanted such component and thus we discussed how to build one in Unity3D. We did not want to pull in the UniRx dependency thus we wanted to create some lightweight variant ourselves.
It sounded like such a nice little thing to write that I also ambarked on a little journey to write such module. When I read the source code right now I would have done lots of things diferently. As a matter of fact, I did, in an event bus module I wrote at work. It’s much more performant, threadsafe, and supports reactive functions and async/await. But, as I see this module as my inspiration for a far better solution I think it deserves being mentioned here.
MaTcheDD & UnityMVC
A long time ago as I started experimenting with TDD in a Unity3D context, I needed some project to practice this new found skill. I started working on a Unity3D based Model-View-Controller architecture library. This library also included some basic logic for persistence and ohter utilities like running update loops or coroutines.
With this library and TDD methodology I wanted to build a simple game and publish that in the AppStore. I wrote a clone of an existing game called match-the-characters. This part of the mini-games of the Nintendo 3DS edition of Super Mario (it’s hard to find a link that describes the game).
But the rules are as follows; 3 characters are shown on the bottom side of the screen. Their heads however are at the top of the screen (brutal, right!?). From their heads to their torso’s, a line is drawn where the heads will slide across and upon reaching they torso the character is whole again. However, the heads are mixed up, so you as a user must draw lines between the torso’s to switch the heads properly. I hopw this makes sense. Maybe from the screenshot’s I added from MaTcheDD you get a sense of what I mean.
Writing this game was a lot of fun (as always). I learned mutch, and mostly that so called “RunTime Tests” in Unity3D are aweful and you are far better off if you can isolate your logic from monobehaviour. Who would have thought huh!? 🙂 Also, I used a lot of reflection in my test cases to test behaviour. I find it pretty interesting looking back now since I would have done that differently now.
You can check out the source code of both MaTcheDD and the UnityMVC library through the GitLab link. You’ll also find the link to the playstore there,