> Why aren't you using Unreal?
C++. Sure, we can talk about Verse or even Skookum, but C# is much easier. Still, if any big game engine would have something like JS it would be even better for indie or small studios.
C++. Sure, we can talk about Verse or even Skookum, but C# is much easier. Still, if any big game engine would have something like JS it would be even better for indie or small studios.
The name of the game is iteration speed. (I always think of Paul Grahams story about beating out the competition using Lisp.)
I've been working with UE since 2014, originally started in UE4 C++ and avoided blueprints and kept everything in C++. Was great 'for performance' and code diffs but now 10 years later I'm 99% blueprint and only go down to C++ if the performance requires it for the 1% of hot paths. My iteration time in UE using blueprints makes me shutter to think of all the time I spent waiting for C++ to compile.
I tried using blueprints for awhile, but it just feels so cumbersome and time consuming. I can bang out 10 lines of code basically as fast as I can think, but converting those same 10 lines of code to blueprints often involves much more time. You have to click around a bunch, rearrange the routing wires, make it look readable, abstract a lot of stuff into functions that usually don’t need it just because it helps condense the blueprints. Then the blueprints end up sprawling a large area and are very difficult to keep in my head at once (whereas it would normally take less than a page of C++ code to write it out and you can easily hold that in your head).
Basically, I was wondering if these downsides to blueprints effect you much or if you’ve developed suitable workarounds? I want to like blueprints, but the time it takes to click around and make it readable is painful, in my opinion, more painful than compile times for the C++.
It took me a while to build up enough experience where I could become more expressive with Blueprints than C++. The Lyra example has some good Blueprint hygiene worth reviewing where they organize all variables underneath a function call.. but until you have serious experience with Blueprints they are going to feel like a cumbersome mess.
My advice is to do what you feel most expressive with, doing the thing you enjoy more will lead to more hours of experience. Start with C++ and build up a good understanding/mental model of the engine and then eventually give Blueprints a try in a few more years and you will see them in a new light.
This will work just fine for small indie games and teams where the code is thrown out after a year, but there's no scaling this. I've worked with enough 10 year old Max/MSP patches to know that you will have an unmaintainable mess of wires that is as good as garbage after a while.
Larger teams typically use Blueprints to prototype but then rewrite in C++. This is a perfectly fine use case, but ultimately you still need it "written down" for the maintainability.
tl;dr Blueprints are a tool in the process to writing C++, they aren't a replacement.
It was just about fine if you were doing very small projects but quickly got very hairy, and their compiler was full of bugs.
You do need to be disciplined, however, being able to simply start extending random instances of other types proves remarkably useful when developing.
I'm not sure such a thing would work well on a team.
Has a brief overview in its README if anyone wants to check it out: https://github.com/ldyeax/MazeEngine
I have more expansive ideas for it but for now the main demo is this silly museum. https://jimm.horse/maremuseum
It's a fun experiment in seeing what JS can do, it's cool having it run natively on the web, and annotations get you a lot of the way there, but in a context like Unity I'd never pick it over C#. Typescript might be alright but at that point why bother? C# has anonymous types, tuples, and such today too.