Sadly, I must say goodbye to Leaf, my programming language

Re the second point did you manage to get around this? Played with it a bit and it felt almost like flash back in the day where you could eschew the timeline and do everything programmatically. In the end ran into a problem where I wanted to move the universe around the player and couldn’t get the particle engine to cope..

The problem here is that the project was made public for others to use/view. If someone wants to do a private project that impacts no-one else, it is then completely up to them as to whether they continue or not as it their choice.

However, when one starts a project and says "look at me and the fabulous stuff I am doing" then it does not show them in a good light when they give up because they are now in the drudge work.

In a public situation, they are essentially saying that they are not worth their hire when the normal drudge work starts. I can understand stepping back from a project for all sorts of reasons, except for the reason that it is hard work to continue because drudgery.

Most of the work that most of us have to do is not exciting, not learning new things, not even interesting. It is just drudgery that needs to be done to get to the eventual goal that we started with. This is life.

The thing is that even drudgery work can be viewed in a very positive light if we continue to see it as essential for the final goal we started with. We will see the need for it and we work willingly towards the completion of it for the purpose of what we will achieve in the end.

The journey is a part of the destination and it is an essential part of the whole process. A journey without a destination and a destination without a journey are both meaningless without the other. Both are the two sides of each other.

Games are still in need of a better language. I have some skepticism and hope for Jai. I really wish D as better C worked better in that realm, but it's missing a few crucial things. Rust asserts too much control over memory. I'm all ears for anything that's somewhere between C and C++ as an alternative to write games in.

Most new languages just don't get the things right that C++ did, which is why despite it having a ton of deficiencies when it comes to game development, it's still what everyone in AAA is using. Companies in AAA spend so much money on software to even just somewhat improve places where C++ has gaping flaws. A better language should have been developed by now and I don't even want to think about how much money C++ has cost the industry as a whole, even just purely on iteration speed.

Only because rust has an unstable ABI. I feel like it'd be nice to have rust provide an explicit "rust-stable" ABI for those kind of things.

I started our my games development career as a low level programmer and moved to a lead programmer in the technology department and then founded a games studio where we wrote our own engine and released several games.

My role meant I had to make the correct business decisions using my technological knowledge and as much as writing engines and technology ran through my blood, the right answer was to switch to Unity. The man cost of constantly writing all the technology we need and then maintain it was too great compared to the ever diminishing wins we got from it.

One scary part of this decision was then hiring Unity programmers and initially having these new hires knowing more about Unity than I did. I needed to make calls about what is possible, time frames, performance, meeting client requirements etc without being an expert of the most important part of our development process. Luckily we made the right hires and it didn't take so long until I had been converted to the Unity mindset. Initially I would always be saying "oh well I would normally tackle this in this way" and wanted to coerce Unity to work in a familiar way. But overtime this disappeared and I became increasingly interested in working out the best way to achieve things in the "Unity way" which ultimately returns much greater dividends.

The first game we released, called Bloody Zombies came out last year on Steam, Oculus, Xbox One, PS4 and Nintendo Switch. It can be played in VR (on supporting platforms) and non VR. It is multiplayer, both in the sense of multiple people on one machine (you can do things like 1 VR player and 3 TV players or 4 TV players) but also online multiplayer (where you can do one player per machine or any combinations say one tv player on one machine playing with 1 VR players and 2 tv players on another machine).

VR meant we had to maintain a constant frame rate (60 or 90 depending on platforms). We used stereoscopic rendering, offloaded graphics work to a special job system. We used custom shaders (the game is like a graphical novel so outline shaded characters) we have spherical fog, lightmaps, FXAA, colour post processing etc.

Online multiplayer meant a packet system, ability to establish connections, matchmake, a system for making parts of the game world communicate, handling so many error cases, etc.

For variety of platforms meant lots of variety on the rendering, controller input etc.

For Switch it meant the ability to play on Switches close to each other on a different protocol to online multiplayer.

I shudder to think how much time and effort this would have been without Unity. I suspect we would have needed several new hires working on platform specific tech, full time network engineers, at least one full time graphics dev, at least one full time audio dev, one full time physics dev, the list goes on. Instead we had 3 programmers (which includes me where my time was heavily comprised being a founder/MD/Tech Director/coffee maker) and whilst the other programmers were very good they had both only graduated a few years prior.

Did Unity solve everything? Absolutely not. We hit loads of huge problems with Unity. Without help of their engineers some problems we would never have been able to solve. We helped Unity fix lots of issues at their end. We found issues that could have been solved trivially without Unity. We felt the strain of waiting days for an answer to a mission critical Unity issue. But in the grand scheme, the pain was less than 10% of what we would have experienced doing it with our own engine.

My big worry was not doing "tech" anymore, but that simply isn't true. But instead of having to write loads of architecture and code to even be able to write the "real" tech, instead you can write the more interesting stuff. For shaders you just write the shaders, not the system for passing in shader constants and setting up vertex streams. Post effects is similar. Coming from a strong engine/Tech background has been massively helpful, whilst unity trained hires are amazing it has been really useful for our studio for me to be able to get into the lower level to add feature, fix stuff, debug stuff, etc.