About Godot4, Vulkan, GLES3 and GLES2
godotengine.org
godotengine.org
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.
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.
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.
It's a beautiful middle ground between simple game frameworks and big clunky engines. It's precisely what I'd been looking for.
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?
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.
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.
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.
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.
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?
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?
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.
[0]https://docs.godotengine.org/en/stable/classes/class_multipl...
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.
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.
https://docs.godotengine.org/en/stable/tutorials/networking/...
Well, you don't have to care about serialization or sockets:
https://docs.godotengine.org/en/stable/tutorials/networking/...
Just send the events and sync the variables that you care about.
Here is an example: https://docs.godotengine.org/en/stable/tutorials/networking/...
I don't think this is surprising, nor a sensible criticism of Godot.
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.
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.
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.