Making GLES3 the baseline and dropping GLES2 is the right thing. I'm glad that Godot was able to make that decision now that Safari is getting WebGL 2 (GLES3) support. I spent a lot of time on the implementation of WebGL 2 in WebKit and it's good to see it helping people.
Is Safari actually getting WebGL2 support? I looked into this around 6 months ago, and what I gathered was the WebGL2 support was based on rumours from a Twitter post, and the supposed checkbox to enable WebGL2 on iOS actually does not enable it. I still can't find any solid info about WebGL2 coming?
Test it now in the iOS betas or in Safari Technology Preview. Note that there is a bug in the current iOS beta (which I expect will be fixed before release) that prevents WebGL 2 from being enabled on older A-series processors.
Apple has switched their renderer to using ANGLE, and the iOS 15 Beta shows it in action. I've even reported bugs to the WebKit team and see them fixing it.
Unrelated but having played with it recently what I really like about Godot is its 35MB or something to download and start playing with. Meanwhile every other engine is 7 zillion petabytes or whatever.
For getting kids into programming, its a beautiful thing.
It also compiles from scratch pretty fast, and the code isn't hard to read. I was able to find and fix a minor bug I'd been experiencing within a couple hours.
It's a beautiful middle ground between simple game frameworks and big clunky engines. It's precisely what I'd been looking for.
There's a reason for the large size of other engines though (they're still only ~10GB if you don't plan to release on every platform). You have to implement pretty much everything yourself in Godot, so if you're going to do anything non-trivial, there's going to be a lot of work to implement things that are already included in the other engines. There was a post on the Godot subreddit recently by a team making a 3D ARPG, and they said that if they had to do things over again, they'd use Unreal Engine due to the amount of work and engine customisation they've had to do just to get standard features that are included in Unreal.
Godot is definitely a good introduction to game dev, it's the first engine I used and it's very beginner friendly, but you quickly end up hitting roadblocks once you move past anything more complicated than a 2D platformer.
It's absolutely wild to compare Godot with UE4, they're just serving totally different purposes. If somebody chose the wrong option for their project, yeah that's a huge mistake.
2D games are hardly some sad niche for beginners though, it's an enormous fraction of non-AAA development, and there really aren't a ton of good 2D engines out there.
As a non-contributor but past user of Godot, the different rewrites of the renderer is what turned me off from committing to the engine long term. I have no issue with Godot staying modern (I.E adopting Vulkan) but my perspective is that this decision was made to maximize graphic fidelity rather than to maximize usability of the engine for the users. For me the biggest appeal of Godot was it was approachable and usable. I don’t care if it can compete with unreal or unity on a visual level because there is more work needed in other areas of the engine first. Perhaps the devs felt that the rest of Godot was “good enough” and the renderer was a higher priority but I did not feel that was the case. In the end this was a decision I did not agree with but I am sincerely happy they are making good progress and I’m looking forward to trying out Godot 4.0 once it hits alpha!
I think graphical fidelity can also be part of usability. Artists always seem to complain about things like waiting for baking lights to finish, shadows having weird artifacts, lighting not appearing naturally and have to resort to using hacks, performance problems preventing the use of certain assets and effects, etc. An overall better renderer would remove lot of the pain from tweaking your art to fit the quirks of the engine. For example, things like SDF-based global illumination would be a godsend to those making outdoor scenes.
Refreshing to see that the GPU stack might be converging on GLES3+ at a high level and Vulkan at the low-level. Of course Apple is left out of this, but getting some translation over to Metal is the best we can do.
Regarding macOS they write "On MacOS, as OpenGL is being deprecated, we will also supply builds based on ANGLE (over Metal this time) so the editor and exported games using GLES3 continues to run." but the ANGLE Readme says that GLES3.0 support is "in progress": https://chromium.googlesource.com/angle/angle/+/main/README.... with no status for all the following .X versions.
Is the ANGLE Readme just outdated in regards to Metal support or am I missing something?
This would also mean that Vulkan won't be an option when developing on macOS, right? Or will something like MoltenVK be shipped as well?
Apple is implementing Metal support for ANGLE directly in the WebKit repo. The work is being upstreamed. The upstreaming process is not yet finished but Apple's implementation is fairly complete as it is the basis for the new WebGL 2 support in Safari. WebGL 2 is based on GLES3.0, so 3.1 or 3.2 features may not be supported (compute shaders being the most important feature there).
I find their prioritization of features also very weird.
I can't start an empty project and get multiplayer out of the box, but my team's 7 year old (?) 2D game engine[1] can do this and have client-side prediction set up for you before you even insert your own game code.
We're months away from shipping a next major release, and for as many collaborators work on Godot, they've basically been years behind any of the features I or anyone on my team actually cared about.
We have lag compensation that works over 3G, but if you asked anyone in the Godot community how you'd pull that off, it'd be some random guy not associated with the project, on their forums, with some code snippet he shared with you that is a far cry from first-class support.
Why focus so much on rendering functionality? If you have a team that's actually remotely capable of generating assets at the labor velocity you would need to actually release a game, that team would almost be guaranteed to use Unreal anyway.
It's really incredible how much game software lags in progress because of where development teams choose to put their efforts.
Is your sentiment not a little unreasonable? You seem to disagree with the godot maintainers on where the effort should be placed, but, this is as open source a project as they get. Improving one aspect doesn't belittle all others, nor does it really hinder it.
As unsurprising as it might be, they are improving godot in the ways that they can, because they want it to be better. This is unrelated to the existence of UE.
I'm sure the godot community wouldn't mind if you shared your experience on game networking, and possibly contributed in that regard. I myself would appreciate it, as with you, I've found it to be limited. The underlying components and language features are there, but how to tie it together with redundancy and prediction, and a bunch of other tricks of the trade, is not trivial.
Nope, this team makes 5 figures in donations a month, and they actually spent time writing their own programming language. Total waste of labor. 100%.
Let's put it this way, say I gave you $250,000 and said in a year I want a game engine. What would you spend your labor on? It would not be writing a programming language.
Now I'm really confused here. Your objections were that focus for godot 4 was too much on graphics fidelity, and that they had little support for advanced networking features. And, now you are expressing that they have wasted their time with making their own programming language. I don't like your attitude one bit. It's of course OK to criticise decisions, but, you aren't being consistent in your arguments, and it makes it hard to have a discussion. Is your point that the work a group of people made, and then shared to the world, which then gathered attention, support and contributions, should have been done differently? I can only suggest that you look into the history of godot, and the reasons for why it is the way it is. I'm sure the maintainers will have wanted to do certain things differently in hindsight, but that doesn't make it a good criticism.
Do you have other annoyances to vent over godot development? Something you would have done different, but yet not made any effort other than to say others have wasted their time on? Or is your point something else entirely, like that godot is not as deserving of praise as grid-sdk?
I was being polite. In more earnest phrasing, you are coming across as a bit of an ass, and entitled attitude, which, has little to no effect on anything. I was only trying to see if you had a worth while argument, to which I failed. Whether or not you should care how you are perceived is, I suppose, entirely up to your discretion. You do you.
No you weren't. I'm making an opinion statement. There's nothing entitled about it. What am I entitled to? Nothing. It's only how I feel about the labor usage the Godot team utilizes.
If I said apples are a terrible purchase because I think oranges do a better job satiating you, does that mean I'm entitled? An ass?
Maybe think more carefully about how you speak to people. "I don't like your attitude one bit," is a statement you make to someone when they are subject to your approval; and I'm certainly not subject to yours, nor are you mine.
Iirc, Gdscript preceded the engine's open sourcing, and the team put significant effort into making the engine easy to bind to other languages after the fact.
You can look at it the other way too. They spent time writing their language and produced something that still makes them 5 figures in donations. They may not meet your priorities, but there's a few people they do make happy.
This has been repeatedly said throughout Godot’s development history, but there are several crucial reasons as why the team was motivated to create their own scripting language. From the FAQ (https://docs.godotengine.org/en/stable/about/faq.html#what-w...):
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The main reasons for creating a custom scripting language for Godot were:
- Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
- Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
- Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.
- No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
- Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).
- Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.
Godot's FAQ makes some very good points, especially about GC, poor interop and inefficiencies language runtimes. But it feels like that reasoning focuses too much on the top interpreted languages (Javascript, Python, Lua etc).
Did Godot team considered using a compiled language like D with a bit of custom harness? Wouldn't customizing an existing object-oriented language be easier than designing a completely new one from scratch?
If you've spent 7 years working on an engine for the specific projects you're building it's going to have exactly the feature set you need for those specific projects.
I don't think this is surprising, nor a sensible criticism of Godot.
No idea why they bother with this, not sure what it provides me over something like enet. That's my point. If your game engine is just saying, "Well, here are some sockets, have fun!" then it's not doing multiplayer networking.
Maybe we have different definitions of out-of-the-box multiplayer, but Grid allows you to `git clone` and run `map <map name>` and you've got a multiplayer server and your friend can `connect <IP address>`.
If you want to do a top-down game, great. If you want to do a side-scroller, sure. If you wanted to do a board game, you're set.
Out-of-the-box multiplayer doesn't mean 1,000 lines of code later I can move something on my screen and some other guy finally sees it move, but it's not predicted, doesn't respond to field changes, etc.
Out-of-the-box multiplayer to me means without writing a line of code, I can start a server and do everything a published video game can and I can do what I actually care about, which isn't serializing data, or figuring out when I should network something because it's not visible anymore.
They also use Enet[1]. The fact that you didn't even know that before you went off on a rant about your engine being superior makes me think you are just mad that their engine is much more popular than yours.
I would venture to guess the low level api is useful if you want to get Havok or some other non-built in physics engine working. Not every game fits into the same 2d pixel phsyics mold. You can't ship such a one size fits all solution with a general purpose game engine like Godot.
There's no requirement to use physics in Grid, just as there's no requirement to use physics in LÖVE, which is what the engine is built on.
We build the game engine from this approach because most games want "maps," and "entities."
We use a Quake-style architecture because even if you're rebuilding a 2D version of Tabletop Simulator, you're going to want a map and entities.
We'd rather have a one-size fits all solution (worked for Quake and Source pretty well) versus a Unity/Unreal style flashy game engine where you're suckered into still doing all the work yourself, but hey PBR looks good.
>Out-of-the-box multiplayer to me means without writing a line of code, I can start a server and do everything a published video game can and I can do what I actually care about, which isn't serializing data, or figuring out when I should network something because it's not visible anymore.
Well, you don't have to care about serialization or sockets:
Y’all built an engine to fill your needs, the Godot folks built one to satisfy their needs. Which given everything they showcase seems to be much more targeted to single player experiences, and ease of use by non-programmers. You’ve just got an SDK, they’ve got a vast sprawling Game Editor System that includes map editors, 2d animation, and all kinds of stuff.
Revamp Grid’s page to focus more on “hey you can start a new project and instantly have super solid net code, unlike every other game engine out there” and you’ve probably got a decent Show HN post to make, most “check out my game engine” posts have no unique selling points but “built from the ground up for multiplayer” is definitely one.
Why build all of that though? Why build a map editor? Why build a 2D animation suite? Those aren't game engine features. They're workflow features. You say sprawling, and I say lame FOSS competitor to Blender.
That's my point: all of those features are pointless to spend labor on. Go spend some time in the game development FOSS ecosystem, there are plenty of people already building those tools.
A game engine team does not need to reinvent programming, map making, animating, and so much more.
Go take existing standards and defacto gamedev file formats and build momentum on things that actually matter.
I can assure you that effort will be placed on fun stuff and things that are critically needed (subjectively) by the developers.
If you wanna change that then go ahead and do it yourself, or fund it ... Otherwise Open Source is Open Source, and always have been. It is what it is, not what you would wish it to be. Why not send a letter to the "ceo" or equivalent and voice your opinion?
When I helped out with Warzone 2100, I strictly did stuff I think was giving value to me personally. That included helping out with features people needed, but certainly not always.
