How My Unity Framework Began

When I started getting back into programming during COVID in 2020, there were two things I wanted to do: revisit some of my old university projects and start building my own Unity framework.

One thing that had always frustrated me about Unity was how easy it was for projects to become a mess of scripts and dependencies. You can attach scripts to pretty much anything, which is great, but as projects grow and everything needs to communicate with everything else, things can quickly become difficult to manage.

Earlier in my career, I'd worked with developers who had introduced me to a more structured approach.

The idea was to have a shared base class and a central application manager. Objects would be instantiated and passed references through a setup method, giving them access to the systems they needed without having to find everything themselves.

Alongside that was an event system, where events were small classes containing data that could be dispatched and listened to from different parts of the application.

I'd really liked working with this architecture, so I decided to try recreating my own version of it.

It was a fair bit of work, particularly as I was just getting back into programming after spending some time teaching English in Cambodia.

I also managed to get my first-year university visualiser running again, using some of the systems I'd been building.

The architecture wasn't perfect, something I'd discover more clearly over the following years, but it gave me a foundation I could reuse rather than starting from scratch on every project.

That was really the beginning of my Unity framework, which I've continued developing and refining ever since.