111–120 of 121 posts
Earlier quoted context omitted.
Godot doesn't really export for ARM though, are you sure?
There's absolutely no problem to run Godot on ARM (or other architectures). I can run the whole editor on my phone. It's even in Debian repos.
I suppose you could run Android on the Pi instead though, which might be what they did.
Earlier quoted context omitted.
There's absolutely no problem to run Godot on ARM (or other architectures). I can run the whole editor on my phone. It's even in Debian repos.
Yeah I can find the armv7 and v8 build options under Android APK export, but not under generic Linux. At least none I can find under presets. I suppose you could run Android on the Pi instead though, which might be what they did.
Earlier quoted context omitted.
O3DE requires "40-100 GB of free disk space" and a separate compiler. Godot (3.5) on the other hand requires a paltry 72.6 MB. Even less if you go for older versions or recompile it without certain features. It comes fully featured with it's own scripting language (or C# if you prefer but that requires extra disk space) and pre compiled builds for distribution with the final product. You can still use C++ if you wish…
But I was responding to claims that it will be ubiquitous in the industry, not that it's easy to get started with. > pre-packaged with the majority of features that your average developer will need From my minimal experience with it, I'd disagree. What's the biggest (3D) game built with Godot?
There were certainly teething problems with the Switch version but I definitely think it's a good sign when people contracting for a company as big as SEGA are using it.
In that vein however, I ask this: O3DE is a fork of the Amazon Lumberyard engine. Amazon Lumberyard has not been very successful with only a handful of companies using it, mostly Cloud Imperium and Amazon themselves. How do you forsee O3DE changing this pattern?
Earlier quoted context omitted.
Yeah I can find the armv7 and v8 build options under Android APK export, but not under generic Linux. At least none I can find under presets. I suppose you could run Android on the Pi instead though, which might be what they did.
You can easily build export templates for any platform by yourself. My phone doesn't run Android, but a regular aarch64 GNU/Linux distro.
Earlier quoted context omitted.
You can easily build export templates for any platform by yourself. My phone doesn't run Android, but a regular aarch64 GNU/Linux distro.
Oh I'm sure you can compile your own support for it yourself, it's open source code after all. But there's no way to do it as-is in the shipped editor.
I'm seriously considering trying it out. Is support on C++ development very good? Because I don't want to learn the scripting language.
Earlier quoted context omitted.
> The engine is slow doesn't really seem that slow for me (but of course, i haven't used it in anger yet). > the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language. the editor is enough for small scripts, but you can also choose to use your own native editor, or switch to the C# version (and use visual studio or jetbrain rider). I don't find the scripting language any wo…
>I don't find the scripting language any worse or better than any modern script languages. What are the missing features? lambdas, closures, support for error handling, constructor overloading, list comprehension, packing/unpacking (arguments/lists), varargs
Gdscript is a lightweight language, it wants to be fast. They explain the goal of the language in their doc and why they didn't use something else.
Earlier quoted context omitted.
But I was responding to claims that it will be ubiquitous in the industry, not that it's easy to get started with. > pre-packaged with the majority of features that your average developer will need From my minimal experience with it, I'd disagree. What's the biggest (3D) game built with Godot?
My point is that an engine with easy onboarding and relevant functionality would address most developers' requirements and likely earn it a place in many companies' toolboxes but to address your second point, off the top of my head I believe that game would be the Sonic Colors remake. There were certainly teething problems with the Switch version but I definitely think it's a good sign when people contracting for a c…
Sure, Sonic Colors is a decently sized game, but it's really the only notable one (in commercial terms), and a recent release. This is for an engine that is nearing 8 years old.
O3DE is a fork of Lumberyard, but Lumberyard was itself a fork of CryEngine, which should need no introduction. It actually already has a game using it too, listed on Steam - https://store.steampowered.com/app/1142050/Deadhaus_Sonata/ Lumberyard was used mostly for internal projects, but that's because it wasn't meant to be generally available. Amazon is still backing O3DE with many full time engineers, while having notable partners, some of them big game development studios or tools, suggesting unannounced projects are picking up the engine too.
Now, as to why I believe O3DE will succeed - it's got AAA roots, but it's also being rapidly reinvented, while being steered by ongoing in-house projects. The value of major projects being undertaken in-house can not be understated - Unity praised their first big project for providing immense amounts of feedback (and promptly fired the team later...) Amazon can simply afford to throw money at O3DE till it's competitive, while Godot targets a less lucrative demographic.
Look, if Godot 4 turns out to be amazing and competes with Unity and Unreal while being super user friendly, I will be over the moon. Maybe I'll have to re-learn a bit of game development, but that's no biggie. For now, I've tried Unity, then Godot, and then Unreal, and Unreal was the first one that felt feature complete, at the cost of some user friendliness. If I were to run around implementing basic things like I had to with Godot, I would maybe get a game done in a decade or two. I'm trying to maximise the efficiency of my labours being conscious of the limited earth time we all get.
Earlier quoted context omitted.
The race car analogy can be extended in that UE4 doesn't even give you a competitive F1 car but it's marketed as such. AAA companies outside of Epic using UE4 have spent a kings ransom on customizations to tailor it for console. Much like top F1 teams just getting an engine doesn't put you out front without a bunch more work. Nevertheless, this is only a problem if you think you can take UE4 and a small team and make…
I'm a little surprised you're being downvoted. There might be a bit of hyperbole in your words, but no game engine is entirely off-the-shelf per-game. Or, idiomatic code suited to an engine always requires a bit of elbow grease to be ready for shipping.
I've been part of shipping one of perhaps the largest used Godot projects in production. It's not a game, and you may not even realize it's Godot. Godot is below average in quality compared to Unreal, and probably about on par with various idiosyncrasies that Unity has. Unreal is winning the technical race because they ship projects and games themselves with their engine. Unity does none of that, at least nothing tha…
It's totally bizarre to compare Unreal Engine with Godot. One is a AAA 3D game engine with awful support for 2D games, the other is a superb 2D game engine with modest 3D capabilities. There's just very little overlap in sensible use cases, they barely even count as competitors.
There is a vocal amount of people (can't say whether they're a minority or not) that tout/desire the major open source engines to be a valid replacement to the commercial ones. This is also happening in Rust, where Bevy is extremely hyped.
So, while it's absolutely true that comparisons don't make much sense, practically, there is a lot of talk about such comparison, so it does make much sense to make this very clear, at least in order to inform developers.