How is the support nowadays to export your game to mobile, anyone knows?
Godot 3.5
71–80 of 121 posts
Re: Godot 3.5
#72TLDR: The problem with Godot is that it tries to be everything to everyone.
They made an engine, an editor (a text editor, resource editor, debugger ...), invented a new language. They "support" export to almost all popular OS platforms. But in my opinion it's lacking in quality. The engine is slow (old style based on OOP), the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.
But it's certainly good for rapid prototyping and learning.
Re: Godot 3.5
#73I'm seriously considering trying it out. Is support on C++ development very good? Because I don't want to learn the scripting language.
Re: Godot 3.5
#74I'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.
Re: Godot 3.5
#75Earlier quoted context omitted.
It's small enough of a code base that you can change things to suit your needs, too. Godot is definitely going to win the race long term, just like blender. People can use whatever they like, of course, but if you want future developer talent, youre going to need to use Godot.
That's a very bold statement, what has Godot done to warrant it? It's not even the most advanced open source 3D engine right now, considering O3DE (a fork of CryEngine) is open and backed by a fair few big players.
Usability. For artists and non professional programmers, those options are fairly inaccessible.
Re: Godot 3.5
#76> Physics interpolation in 3D This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing! EDIT:…
Why couldn't you just run physics at the graphics frame rate (or double it if the graphics becomes too slow)? I don't think many games need fully deterministic physics do they?
Like
x += v * dt
draw(x)
Re: Godot 3.5
#77Earlier quoted context omitted.
Unreal is ahead for a couple of reasons (mainly historical + money) and they target industries outside of games as well now - namely film productions. With that said most big AAA companies still use their proprietary game engines and I don't see that changing. General purpose engines like Unreal/Unity/Godot have their place of course, but to use the full set of features of Unreal you need a big team anyways, so compa…
I am not sure about the "I don't see that changing". CD projekt red has adopted unreal engine leaving behind the engine they built AAA games such as The Witcher 3. I can see a future where more gaming houses adopt the engine as well.
There are good arguments from both sides of the fence in the “generic solution” VS “custom solution” debate. I think the decision should be made on a case by case basis after sufficient analysis has been conducted. For example, I wouldn’t do an RTS/Total War type game in either of the 3 aforementioned engines. Also it should be noted that sign of the times is that we’ll be getting less AAA games, not more. It’s clear that those huge budget games carry substantial risk if not successful (hence early incremental updates, DLC, mico-transactions etc.) and studios are weary of that.
For CD Project the move to Unreal might make sense just from labour market perspective - it’s easier to hire programmers for Unreal than to train programmers to learn and develop your own in-house engine. Larger community and support already exists for Unreal etc. That move will affect their bottom line on their next games though. 5% is nothing to scoff at for a big product from a big company.
In any case, I’d advise caution to companies relying entirely on a single platform for their business. To echo my previous statement choosing only between Android and iOS for mobile is an illusion of choice. If you’re a mobile game dev your entire business relies on two relatively hostile companies.
Re: Godot 3.5
#78I'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.
It's not a direct comparison, but there are definitely many games that could be feasibly built in any one of Godot, Unity, or Unreal. There's a lot more to consider beyond just the engine features, such as the asset pipeline, the tooling ecosystem, and the availability of third-party assets and scripts.
Re: Godot 3.5
#79In 3.4 I could not get in-app purchases working for iOS apps. Is it fixed now?
Re: Godot 3.5
#80> Physics interpolation in 3D This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing! EDIT:…
Why couldn't you just run physics at the graphics frame rate (or double it if the graphics becomes too slow)? I don't think many games need fully deterministic physics do they? Like x += v * dt draw(x) Or is that what this does?
Collision detection is a major reason. If you only sample positions at the frame rate, you're going to have bullets go through walls without hitting anything.
Also, physics is costly to run, so usually it's not run on every frame.