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

For very specific effects like universe turning, you have to do a lot of code work in a niche area, but it's still quicker than building a particle engine from scratch. Sometimes you can cheat the effect in shaders or camera tranform manipulation. Or skip the effect altogether if the volume of custom code is not worth it and you are prioritizing shipping. Ask yourself, does it make or break your game?

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.

But yes, I am dealing with the interface, primarily by ignoring it. I'm still trying to get down the right way to organize my code, but it's making sense.

http://www.walterbright.com/

A lot of language devs want to play with semantics but aren't into the whole "let's do the hard work of actually getting off of C as the baseline" idea so it's nice to have a project that does and has a fairly explicit goal of absorbing and replacing the existing infrastructure step by step.

To the point the Windows UI team does all their graphics demos in C#.

3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects.

3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still many cases where modelling things as objects is the best way to go, especially for things like scene actors and game objects.

4 - No built in threading (core.thread) puts a hamper on any sort of distributed updating or performance optimizations you'd want to do. I'd imagine the workaround is external multi-threaded dlls or something, but it sounds like a pain to manage and deal with in a workflow.

5 - No dynamic arrays. This container is used abundantly in game development. It shows up 5 or more times for every heap/stack/queue. This may not be an issue if you want to write a special memory environment and your own containers, which is common in game development, but not having access to a standard one certainly hurts when it comes to smaller projects or graphics programming experiments.

I may be somewhat off base here since what happened is that I read about those being missing and decided not to try it.

Another note is that a big thing I'm looking for is massively improved compile times, which is one of the biggest things Jai looks to have over C++ in addition to its compiler hooks and #run.

I wish to use instead swift, that hit a sweet spot. Using other lang (like python, that I loved!) make hard to target iOS/Android. This is the main crux of mine. This mean that I need to re-code a lot of stuff across platforms and targets, because nothing is good enough. I also use xamarin/F# and the integration with android/ios is not as good as I imagine (ie: xamarin.forms sucks. And is damm hard to integrate yourself anything (ie: ios/android libraries) outside it).

I also try with nim but is too crude and lack a lot of libraries I will need. I'm also thinking on using pascal, that I also like much, so now is just looking how good could be the use of rust...

As an outside observer it looks like an unnecessary complication.

> The problem here is that the project was made public for others to use/view.

This literally doesn't matter if we're talking about someone's character, because whether it's public or not is irrelevant regarding the " they give up because they are now in the drudge work" point. Either that point is valid or it's not, but the public knowing about it is beside the point.

And I would say the point is not valid. Someone starting a personal project for a language and then discontinuing it is still much better off than someone not starting a project at all. I don't think most engineers share the perspective that this shows them in a bad light or something, this is honestly the first time I've seen this perspective in years.

> 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.

There's nothing good about this, nor anything good about reinforcing it. Godspeed to those who can avoid it.

The author of the language does not owe it to anyone to start, continue, or finishing any projects they have in mind, definitely not to anyone sitting around and judging them for daring to do something at all.

I also don't grasp the logic behind the notion that once a creator shows his work -- or work-in-progress -- to the public that he is somehow bound by duty, honor, respect for his 'followers', or some other compelling consideration, to finish that work.

If Beethoven starts writing a string quartet, and posts the first movement on the internet, but then realizes that the Duke isn't going to commission it and he'd rather be writing a sonata anyway, does it really reflect badly on LvB if he abandons the quartet?

When I look at it from his point of view, I feel quite sorry for him. The language's forum has 9 posts in the last calendar year. 4 of those are him solving a problem using Leaf. Then, I check out the status page and realize that, for all the work he has done, Leaf is still in a very primitive state.

I'd equate it to being like a startup. At some point, it stops making sense. Then, you can either ride the ship down into the depths, or hop out when the going is as good as it will get.

As for his dependability, I've got to tell you that, from my perspective, anyone who can pull this off is more than impressive enough.

I think he should be awfully impressed with what he did. And, I don't think it's even remotely fair to judge him as being undependable. Based on what I've seen, I think he should have pulled the plug last year, when he first wanted to quit.

...to you. You find most parts of your projects boring and tedious.

Many people don't. I definitely don't find any of my work boring, and only very small parts tedious.