No mention of Godot? It seems to be slowly starting to eat their lunch.
No mention of the fragmented rendering backends?
Oh, but they do talk about basketball. Why would a CEO care about the little things… Unity is going to be fine.
https://gamefromscratch.com/battlefield-6-using-godot-game-e...
Planetenverteidigungskanonenkommandant looks neat though.
https://steamdb.info/tech/Engine/Godot/?sort=followers_desc
Battlefield 6 also uses Godot for its modding tools
There's also a free, MIT licensed Switch exporter, but it's in the Nintendo developer forums because of the NDAs.
If you understand how engines and rendering works in general you have an idea on how to implement something - but then you either run into A: a tool that can't quite do what you want but almost, B: an incredibly overengineered API that's somehow way more byzantine than OpenGL C: Some obscure quirk or bug of an existing feature that either works in a strange way, isn't documented, or is buggy.
In all these cases, doing the feature yourself is much easier than relying on the engine.
Particle systems are a good example for this.
* I have 10+ years experience with it.
* C# integration in Godot is not great
* Cant build to webGL with C# in latest version of Godot
* gdscript is not a serious option imo (stupid whitespace language..They need to drop it and focus on C# like Unity did years back with UnityScript.. Seriously XNA and then Unity have cemented C# as the other language of game devs alongside C++. Even KSA's custom new engine is C# for example)
* With Unity I have access to the asset store, which has a massive amount of content, some very high quality stuff also that's much better then Unity's built in features (eg. Rewired)
I feel dirty using Unity vs Godot, but I primarily want to get my game done, and it will be faster with a better result using Unity, its just superior from an engineering point of view right now imo.
Unity doesn't make me feel dirty at all. Quite the opposite actually. I am not going to apologize for using tools that don't suck. I feel like I am on the bridge of an imperial star destroyer when I am observing others get caught up with this "X is better than Y" bullshit, especially when X is definitely not better than Y.
> its just superior from an engineering point of view right now imo.
If you are building a game, this is the only thing that should matter. Imagine deluding yourself into believing that by picking exactly the right OSS hammer from Home Depot that your woodworking project will magically go better. If you have involved other humans in this effort, playing tooling tribalism simulator is a pretty lame thing to do, especially if those other humans are non-technical artists and otherwise trying to simply contribute to some shared creative vision.
I'm going to break this down:
> gdscript is not a serious option imo
Subjective, but fair enough. If this is a general argument against "scripting languages" versus more "advanced" languages, I should remind you that Lua and JS are still very popular languages in game development.
> stupid whitespace language
The only other big "whitespace language," Python, is immensely popular and widespread in server, client, AI, etc. applications. This is a question of taste, and has nothing to do with the objective quality of GDScript.
> They need to drop it and focus on C# like Unity did years back with UnityScript
The irony is that JavaScript (real JS, not a JS-like language) is almost certainly very viable in a game engine nowadays.
> Seriously XNA and then Unity have cemented C# as the other language of game devs alongside C++. Even KSA's custom new engine is C# for example
C# is popular for a variety of reasons (fast, mature ecosystem, etc.); however, "just use C# because others are using it" is by itself not a compelling argument.
Syntax and language aren't that big of a deal for professional developers.
I could do everything in gdscript, but it would be slower, more error prone and less maintainable.
.. Ive done some js recently, I did a web app. and the difference is shocking..
* you can actually make spelling mistakes
* there no find all references
* You cant rename things
* without types autocomplete does very little
* without compiler autocomplete suggest random things based on spelling, not actually viable fields
I could go on.. All these things add up to make the work go slower, and produce more error prone and less maintainable code. I thought the freedom of no types and less boilerplate would make js really fast to write but I found it the opposite in practice.
I can write 1000's of line of game code in C#. Complicated stuff like procedural level generation and I dont even need to run it, usually its perfect 1st time. I couldn't do that in js, the IDE experience is not the same.
Also they aren't still there with being first partner with many industry places, that always release a Unity SDK for their products.