>>As much as we love exciting new features, we also want to see people create games on the full spectrum of devices for everyone to enjoy.
This is one of the main attitudes of the Godot team I really appreciate a lot. It might be easy for people in more developed nations to upgrade their hardware every few years, but there's people still playing games running on computers from 2002 and before. I used to know of a player who used to play (an old MMORPG) games on a computer he aimed a table fan at to keep it cool. The whole casing was open, it was kinna funny to look at it and it had hardware he got as a birthday gift more than 10 years ago. He played that old MMORPG because newer games wouldn't even start on that old thing. But most people who played that MMO were in the same boat, it was one of the very few ones they could run.
The requirements for some of the games coming out these days is sometimes so insane a lot of people from around the world are unable to play them. I always found it funny how we had so much developer time wasted on supporting ie6 because a small percentage of people were unable to upgrade their browsers, but when it comes to gaming, all bets were off and you are now expected to spend a few grand a year on upgrading your computer to play newer games. And don't get me started on the bandwidth costs to play some of the new games.
Low-poly, visually simplistic games like Fortnite, Risk of Rain 2, Valheim, and Deep Rock Galactic barely run on a friend's computer (that was made only 5 years ago). Visually more complex games like League of Legends run buttery smooth on the exact same hardware.
(ironically, he says that Valorant, made by a non-Epic company, apparently runs significantly better than Fortnite, made by Epic - even though both are using the Epic-made Unreal Engine)
Those games are low poly but NOT visually simplistic. Memory tends to play tricks and we remember older games looking better than they actually did, so we imagine lower polygons = 2005 tech game. Those games you've mention run on advanced and heavyweight fragment and vertex shaders to create a specific look (cartoony graphics in Fortnite, there's a million effects on screen a dozen levels in a Risk of Rain game, etc.)
They might have the same poly count of Old School Runescape (but not really, as the models are actually quite complex) yet everything else is 20 years ahead of that game tech and complexity wise.
Also not sure what your friend's PC is like, because a 5 year old PC can play all of those games with ease, though perhaps not at max settings. A 1080 ti from 2017 can run RoR2 at ~190 fps at 1440p. https://youtu.be/TdfE3n8YLYo
On top of that, the fact Fortnite has a destructible world with 100 players means it’s also one of the most computationally demanding games… and yet it can run on four year old mobile phones. It’s a technical masterpiece, and anyone saying otherwise doesn’t know what they’re talking about.
The 2nd Ori game was actually entirely unplayable on my system until I moved it to an SSD due to how it loads assets (don't know the details, but that's my assumption). I couldn't beat the time trials since it'd lock up mid-air due to the amount of map coverage and mess up my flow.
All the games you mentioned in your post have dynamic levels, and must calculate all their lighting on the fly.
Actually, I think basically all of these games should run fine on that sort of hardware, as long as the quality isn't turned up high. Did they just build a really cheap machine or something?
This is one reason I really admired Valheim (~1GB). Though even that game had CPU issues (also its an indie title so...).
That brings me back, I had to do the same to play Starcraft in the early 00s in summer since our house had no air conditioning and CPUs were passively cooled. I was drenched in sweat but I wasn't going to give up my games, dammit! The interesting thing is the symptom was just a crash to desktop, not a full system shutdown like now (for safety reasons I assume).
While Godot fairly established, there are up-and-comers in software development, and one of the few ways I will ever know about these people and their projects are by Show HNs and product update submissions.
It may be dozens of releases or years before I even hear about a project, and this type of comment clearly comes from a place of not knowing at all what it is like to work so hard on something nor knowing at all how to promote a product.
People have an aversion to promoting and advertising, but I want to see "WAYWO?"!
I'd far more* rather see that than political nonsense, bullshit tech opinion articles, and news completely unrelated to the hacker or business space.
Edit: Further, with respect to Godot, the authors continually make more progress on the codebase and there is a lot to talk about. Not just specifically with Godot and their prioritization of software features, but how the developers and contributors are having an impact on the hobbyist and independent developer scene.
I have gripes with the space as it currently is, and I know I'm not the only one. I want to read those opinions here. If you don't like it, don't upvote it.
For example, why have they in the past prioritized their own programming language? Decades old game engine codebases have rich features like material sounds, and fully integrated multiplayer features, but almost no open source game engines feature these things. Instead, they all focus on shallow flashy features like PBR workflows. I want to talk about those things.
Another comment here mentions a custom physics engine that is being introduced. That's interesting! And further discussion is warranted over whether or not that is something that developers care about! What about other features like native split screen support? There's so much in this space to discuss.
https://docs.godotengine.org/en/stable/tutorials/networking/...
* https://github.com/godotengine/godot-proposals/issues/4435 (spatial audio)
* https://github.com/godotengine/godot-proposals/issues/3904 (network interest management)
* I can't find the proposal, but we, V-Sekai, call those physical materials or sound materials. Like a piece of concrete has different friction and a different sound. The worst part is it requires the Godot Engine 4 artists to conform to like 300 materials.
Someone submitted one for a v4 alpha. (That it didn't get traction is irrelevant.)
Here's one for the beta.
When v4 is released, it'll inevitably be posted here, too.
It isn't. It's (yet another) pre-release. There's a story about an upcoming Godot release posted every 1, 2, 3 weeks or so.
For example, Horizon: Forbidden West uses a custom physics engine that started out as one of the core dev's fun side projects: https://github.com/jrouwe/JoltPhysics
Physics engines (at least game quality physics engines) are starting to drift in to "solved problem" territory and there's enough literature now that you can get something reasonable going yourself after doing some weekend reading.
Edit to add: Godot has had its own engine available for a long time, so it's not a totally new effort. It's a heavy refactor and a large improvement but the bones for this were laid years ago so some of that technical debt you're describing has already been paid down.
https://bevyengine.org/assets/#physics
Forgetting about extensions, though, I see your point and almost agree, but Godot has shown that they will put in the work to improve their project, even if that means removing features like they did with visual scripting. Their physics engine will definitely be rough at first, but based on their past work, I believe they are willing and able to maintain it.
It sounds like it's got bugs that need fixing either way, so at least for their own engine they're not reliant on anyone else to get those fixes out (or have to use hacky workarounds as would most likely be the actual fix).
https://web.archive.org/web/20220915181526/https://godotengi...
Unreal uses a different architecture where the codebase allows you to define who owns what, but it’s ultimately the exact same thing, and more confusingly done. Further, they have some actor states which are never actually used.
Unsurprisingly, Unreal’s networking model is unpopular. They also struggle with an architecture that has been unreliable by design since the late 90s, but now I’m digressing.
One codebase, split execution. If you use this traditional model, you can also avoid shipping server binaries to users if you so desire.
For reference, I am the author of Planimeter Game Engine 2D.
Though based on the discord conversation there are still a lot of bumps even in the beta so I would not expect smooth sailing yet, but lets see if it is any good.
For anyone interested, the main documentation on their site is still pointing at 3.x. If you want the docs for 4.0 start here
I may still jump to c# but I wanna give GDScript a fair shake first. Plus the docs/tutorials tend to be more plentiful for GDScript.
I don’t want to derail the thread but I have a link to my GitHub in my profile - I’m working on a few things: 1. the aforementioned Erlang ENet fork 2. My generic Erlang game server called Overworld 3. A client plugin for Godot that generates a lot of the boilerplate code needed to encode/decode messages between Godot and Overworld (protobuf used for serialization) 4. An implementation of a subset of GDScript called Gdminus written in Erlang, including a simple interpreter. The idea being to have a familiar language for Godot programmers to be able to script Overworld someday- or more generally as a toy white space significant language that runs in the BEAM.
Honestly they’re all toys right now but happy to chat more via email!
Basically, binaries of games cannot be "pure" and "simple" ELF64, in other words cannot load with any libc/elf runtime (musl/glibc/bionic?/etc) until there is the right symbol/version because of the static libstdc++ (some libgcc services too).
They would have to fork libstdc++, third-party libs, and fully libdl-ized them (in theory, it is easy brutal work).
c++ ABI is a nightmare, glibc symbol versioning is amok, well the devs of those components seem to ignore carefully that games have been available on elf/linux for 10 years.
Looking forward to the new version.
I shipped games on Godot 3 and the idea of having Vulkan and better culling is really attractive.
When I tried the alpha fairly early on the editor was completely unusable on macOS.
I've been building my game on the Godot 4 alphas and the improvements in networking and rendering have more than made up for any instability or keeping up with changes. That said, more stability will be welcome and a focus on bug fixing instead of feature proposals will be key to a strong 4.0 release.
