11 ms·

Godot 4 Beta 1

350 points by f47il 4y ago

cridenour 4y ago
This is great. 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.
dopu 4y ago
HN hug of death? godotengine.org is offline for me at the moment. Regardless, really looking forward to trying it out! Here it is on the wayback machine: https://web.archive.org/web/20220915181526/https://godotengine.org/article/dev-snapshot-godot-4-0-beta-1 https://web.archive.org/web/20220915181526/https://godotengi...
- cridenour 4y ago
  Their web hosting has been pretty awful the last month or two. Multiple days of downtime for critical pieces. I know they get it free from tuxfamily but this certainly feels like they're getting what they pay for.
- deleted 4y ago
  [deleted]
- runevault 4y ago
  I think this goes beyond just HN. Their discord was also buzzing since last night when the tag got updated on the main branch.
- japhib 4y ago
  In the discord they said it's pretty typical for the website to go down a bit when they @everyone like they did for this post
- moffkalast 4y ago
  What, the whole five of us? Impossible.
  - xdrosenheim 4y ago
    Ah, we are dozens. At least.
cmdrk 4y ago
Fantastic news. I'm really looking forward to Godot 4.0 exposing more of the ENet wrapper into GDScript etc. I've been writing a game server in Erlang and very much looking forward to offering ENet as an option in addition to WebSockets!
- japhib 4y ago
  Whoa, that's interesting -- does ENet have a good integration with Erlang, or something like that? I'm interested in both Elixir/Erlang and Godot, but haven't seen an opportunity to use them together previously. I'd love to hear more details about this project of yours, and how the Godot 4.0 release impacts it.
  - cmdrk 4y ago
    Someone made an effort to do a full protocol port to Erlang and I have a friendly fork I’m maintaining that makes it work better with the C version as used by Godot. Seems to work with unreliable/reliable/unsequenced packets but never tested in anger, much less production! 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!
    - iFire 4y ago
      We're toying around with elixir. We should share notes! I also have a copy of libgodot written for elixir. https://github.com/godotengine/godot/compare/master...V-Sekai:godot:libgodot https://github.com/godotengine/godot/compare/master...V-Seka... https://github.com/V-Sekai/godot/tree/elixir https://github.com/V-Sekai/godot/tree/elixir Join our discord!
Reubend 4y ago
I think writing their own physics engine might be wrong way to go here. I understand that Bullet leaves a lot to be desired, but my instinct is that the complexity from their own engine will leave a lot of edge case bugs that need to be ironed out over time, and that games using their own physics engine will suffer from a lot more quirks in the meantime.
- dljsjr 4y ago
  A few years ago, as someone who has worked on physics engines for robotics simulations, I would have agreed with you. But now a lot of people are doing greenfield physics engines for games and having it work out pretty well. There's a ton of established academic and conference literature in the area now and it's not nearly as scary as it used to be. 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 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.
  - Buttons840 4y ago
    I've briefly looked into physics engines and they seem to require a lot of trade-offs. If a rock meets a hard place, what should happen? Gamers have seen the hilarity that can ensue. Designing your own engine allows you to make those trade-offs with the end goal in mind. You can do things like set global force or speed limits, because you know your game's design and the appropriate limits.
  - Dracophoenix 4y ago
    How complicated were the physics engines you worked on? How exactly did they differ from turnkey solutions like Bullet, Havok, etc.?
deleted 4y ago
[deleted]
ummonk 4y ago
Impressive stuff. Starting to have the table stakes features that would need for a modern game.
pwdisswordfish0 4y ago
It would be nice if we brought the rule back where it's against HN guidelines to post submissions for every new version of some software. Every Godot thread ends up with the same comments posted, none of them particularly interesting or insightful. And in this particular case, it's not even an official release; it's just a beta!
- spookie 4y ago
  What's wrong with posting milestones of a great open source project?
- terafo 4y ago
  Godot 4 entering beta is quite an important thing since that is update that has been in works for a couple of years now and adds lots of new capabilities to Godot.
- andrewmcwatters 4y ago
  I disagree. I want to see more actual software on Hacker News. This is a space for "hackers," is it not? 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.
jokoon 4y ago
I tried the gdnative thing and implemented a few classes, but there doesn't seem to be a lot of difference with gdextension.
- japhib 4y ago
  I think the main difference is that GDNative only had access to Godot's scripting API, so it could only manipulate the same stuff that GDScript or C# already could. So in 3.x, if you wanted to manipulate engine internals, you had to "engine extensions" which had to be compiled with the engine itself. But with GDExtension I think you're supposed to be able to do _everything_ that "engine extensions" could do, but without having to re-compile Godot itself.
runevault 4y ago
I played with Godot back in the early 3.x timeframe (3.1? 3.2?) and then fell away and spent some time with Unity. But between some of Unity's missteps and Godot getting dotnet 6 support it is time to give it another go, plus a bunch of nice changes to gdscript that might make it something I'm okay with using (functions are first class citizens now unlike before where you just passed the name of the function as a string which always felt incredibly gross). 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 https://docs.godotengine.org/en/latest/index.html https://docs.godotengine.org/en/latest/index.html
- prox 4y ago
  Yeah callables are a great addition to 4!
  - runevault 4y ago
    Yeah it is part of why I'm going to start with GDScript instead of jumping straight to dotnet 6 (which is what initially got me thinking about trying the new version). 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.
    - prox 4y ago
      Well GDScript and it’s nodetree is great for early days prototyping, even if you decide to redo it later in another fashion. So getting that under your belt is definitely not a bad idea.
    - worble 4y ago
      >Plus the docs/tutorials tend to be more plentiful for GDScript. I quite like reading tutorials in GDScript and trying to convert them to C#, I feel like it strikes a good mix between being told what to do while also getting to go off and explore the engine myself and reinforcing that same learning.
malikNF 4y ago
from the article, >>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.
- tmpz22 4y ago
  Even seemingly simple games are clocking in at 100GB+ in disk space. I think in terms of performance many games are setting the floor at the Nintendo Switch or the Steam Deck, often ripping out features to get it to run on those platforms (CIV6, 2k etc). This is one reason I really admired Valheim (~1GB). Though even that game had CPU issues (also its an indie title so...).
  - hmcamp 4y ago
    Isn’t this a symptom rather than a cause. Because game manufacturers can create larger games with scant regards for people’s resources… they do.
  - taejavu 4y ago
    I'm aware of large AAA games taking up that much space (Doom Eternal, Red Dead Redemption 2) but they could hardly be considered "simple". Do you have examples of what you're talking about?
sylware 4y ago
For the elf/linux target, I hope the build containers have a really, really old glibc (dunno which version it is) and the "-static-libgcc" and "-static-libstdc++" are defaults.
- 3836293648 4y ago
  Honestly, given the state of linux games, hope they target musl
  - sylware 4y ago
    I would like too. But games needs to load system libs (which are linked to a glibc), and games are not fully libdl-ized (dlopen/dlsym/dlclose). Additionnaly gcc static libstdc++ does not have a "libdl" mode, or even worse: it seems it links to internal glibc symbols. The glibc "should" be libdl clean, minus of few C runtime services I guess. 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.
    - arlcode 4y ago
      I'm not really proficient with games or C/C++ or gcc therefore please forgive me if this question sounds naive: With games already being large downloads wouldn't it make sense to bundle many/most libraries directly instead of relying on system versions? I did some experiments (with rust) and found musl builds and static linked libraries working quite fine.
      - sylware 4y ago
        The part of a game which is "code" is not "large": it is "small", except if a game has really little data, namely it is a small game, and if it is a small game... Then, on elf/linux systems, you have "alternatives" and serious abi instability due mostly, but not only, to gnu symbol versioning (it is pathological in glibc, or it could be a scam). Game binaries cannot expect _their_ alternatives to be there, that's why they have to rely on really only video game core, very video game core libs and the sysv abi(elf). The only way to properly "deal" with abi (modules, symbols, with their versions) stuff on elf/linux, is to dynamically load as much as possible from the system: libdl with only the 3 symbols dlopen/dlsym/dlclose. Ofc, a game should statically link as much as it can (for instance libm), but it requires to dynamically load the video game core libs. Those video game core libs may be linked with musl (hope they have their libdl now), glibc, bionic (if it has a elf loader), etc. If you want full static binaries, you will need a full elf loader into your static binaries. You cannot create such static binaries with the glibc and it is not supported by the set of glibc libs as far as I know (I wonder if it is not done conveniently on purpose to "break" the usage of alternative elf/c runtimes), and if I recall properly you can with musl. The video game core libs on a elf/linux system are: - wayland window system code is static into game binaries, but for key symbols resolution, the game must dynamically load the libxkbcommon library for the xkb client state machine with the user configuration (you may not have the "right" xkb data files for a user). Basically, you feed wayland keycodes to the xkb state machine and based on user specific configuration files, you get out the right key symbol (some games have a mode to bypass key symbol resolution and work directly with keycodes). - x11 system code, the usage is now to dynamically load the client xcb libs and libxkbcommon-x11 (do not use libX11). - android has wayland, but I don't think it's xkb (no libxkbcommon(-x11) lib). - GPU, vulkan by-design does require dynamic loading, and GL fallback will require to dynamically load of the targetted GL libs (some games could be 100% cpu rendering in window systems surfaces using a presentation interface). - sound: you only need to dynamically load the alsa-lib (libasound) as software mixers (dmix/pulseaudio/pipewire/jack/etc) are hidden behind the alsa-lib. (I don't know for android, but alsa has a mobile phone specific configuration interface, don't think it is stable yet though). - for joypad stuff, it is linux specific with the interface of /dev/input/eventN files. In theory, games should be sets of pure and simple ELF64 binaries (with the least amount of relocation types), libdl-ing everything from the system. It means no c runtime main() function, but the sysv ABI entry point, which is a basically a main() anyway. To deal with cross-platform (elf/linux|doz|fruitOS|etc), platform specific fallbacks (on elf/linux platform: wayland->x11, vulkan->gl->cpu, etc), proper compile-time and runtime tables of functions usually will do the trick. Reality check: libstdc++, some libgcc services, and many third-party libs are not libdl-ized. The mitigation is to use "-static-libgcc" and "-static-libstdc++" compiler/linker options and link with an extremely, EXTREMELY old glibc (what godot does). It seems libstdc++ will link with glibc internal symbols if linking happens with a glibc on the build system. NOTES: for i18n games with "full" text input, an input method should be provided by the game itself as you cannot expect a specific input method to be installed on the user system, if any. A GUI toolkit is "above" the window system and related to user alternatives (some may prefere QT, other GTK, or enlightenment or neither of them, then for the same reason than before, a game must package its GUI toolkits. Ofc, if you code in plain and simple C, a lot of those issues can be worked around much more easily.
abledon 4y ago
Logo change in Godot 5 ?
lbotos 4y ago
Early pandemic I was playing around with making a network shooter in godot but I got hung up on a good way to make a shared lib for the client/server "projects". Anyone solve that or have tips? It seemed like I either needed to make a mono repo and toggle the build for client=true but I really wanted to make 3 repos, client, server, and game-core-lib. Would love tips/guides if you have them!
- andrewmcwatters 4y ago
  In my experience, you’re better off having a single codebase with client/server/shared code and using either the equivalent of ifdefs or conditional blocks gating execution for these states. 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.
  - lbotos 4y ago
    Thanks! I think it makes sense, as a non-game programmer it felt "weird" so appreciate the confirmation from your angle.
    - deleted 4y ago
      [deleted]
    - sedatesteak 4y ago
      I also was doing the same but ultimately put it down to wait for Godot 4 (and its niceties such as occlusion culling - I had performance issues with quake 1 maps loaded up through godot). Do you have a repo? I had networking etc running fine with client/server architecture but I would like to see how others have achieved this.
deleted 4y ago
[deleted]
intelVISA 4y ago
Been meaning to pick up Godot one of these days, how does it fare on the wasm/webGPU front?
- astlouis44 4y ago
  No WebGPU support yet in the engine
  - intelVISA 4y ago
    That's a shame, first-class support for the web in any of the major engines would be a killer feature imo.
    - pjmlp 4y ago
      Not really, we are yet to see any WebGL game with the same quality as Infinity Blade. https://www.youtube.com/watch?v=JDvPIhCd8N4 https://www.youtube.com/watch?v=JDvPIhCd8N4
  - s-lambert 4y ago
    Why would it have WebGPU support, it's not even supported by any browser[0] at the moment. [0] - https://caniuse.com/webgpu https://caniuse.com/webgpu
- mkl95 4y ago
  WebGPU's Chrome trial ends in February so we will have to wait until Godot 4.1 most likely.
keyle 4y ago
I'm very excited for Godot 4 beta. 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.
adamrezich 4y ago
haven't used Godot in a couple years but it's good to see the progress on their tile system for 2D games! it was terrible last I checked, yet pretty crucial for making many kinds of simple 2D games
- Aeolun 4y ago
  It wasn’t ‘terrible’, but it always left me feeling that someone just stopped in the middle of their prototype and said ‘this is good enough’. Looking forward to the new version.
taejavu 4y ago
Does anyone know if there's a build for MacOS yet?
devd00d 4y ago
I love everything Godot. My first experience with 3d was with Opengl 15 years ago and seeing what is now possible (for free) is mindblowing.

350 points by f47il 4y ago

This is great. 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.

dopu 4y ago

HN hug of death? godotengine.org is offline for me at the moment. Regardless, really looking forward to trying it out! Here it is on the wayback machine: https://web.archive.org/web/20220915181526/https://godotengine.org/article/dev-snapshot-godot-4-0-beta-1 https://web.archive.org/web/20220915181526/https://godotengi...

cridenour 4y ago
Their web hosting has been pretty awful the last month or two. Multiple days of downtime for critical pieces. I know they get it free from tuxfamily but this certainly feels like they're getting what they pay for.
deleted 4y ago
[deleted]
runevault 4y ago
I think this goes beyond just HN. Their discord was also buzzing since last night when the tag got updated on the main branch.
japhib 4y ago
In the discord they said it's pretty typical for the website to go down a bit when they @everyone like they did for this post
moffkalast 4y ago
What, the whole five of us? Impossible.
- xdrosenheim 4y ago
  Ah, we are dozens. At least.

cmdrk 4y ago

Fantastic news. I'm really looking forward to Godot 4.0 exposing more of the ENet wrapper into GDScript etc. I've been writing a game server in Erlang and very much looking forward to offering ENet as an option in addition to WebSockets!

japhib 4y ago
Whoa, that's interesting -- does ENet have a good integration with Erlang, or something like that? I'm interested in both Elixir/Erlang and Godot, but haven't seen an opportunity to use them together previously. I'd love to hear more details about this project of yours, and how the Godot 4.0 release impacts it.
- cmdrk 4y ago
  Someone made an effort to do a full protocol port to Erlang and I have a friendly fork I’m maintaining that makes it work better with the C version as used by Godot. Seems to work with unreliable/reliable/unsequenced packets but never tested in anger, much less production! 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!
  - iFire 4y ago
    We're toying around with elixir. We should share notes! I also have a copy of libgodot written for elixir. https://github.com/godotengine/godot/compare/master...V-Sekai:godot:libgodot https://github.com/godotengine/godot/compare/master...V-Seka... https://github.com/V-Sekai/godot/tree/elixir https://github.com/V-Sekai/godot/tree/elixir Join our discord!

Reubend 4y ago

I think writing their own physics engine might be wrong way to go here. I understand that Bullet leaves a lot to be desired, but my instinct is that the complexity from their own engine will leave a lot of edge case bugs that need to be ironed out over time, and that games using their own physics engine will suffer from a lot more quirks in the meantime.

dljsjr 4y ago
A few years ago, as someone who has worked on physics engines for robotics simulations, I would have agreed with you. But now a lot of people are doing greenfield physics engines for games and having it work out pretty well. There's a ton of established academic and conference literature in the area now and it's not nearly as scary as it used to be. 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 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.
- Buttons840 4y ago
  I've briefly looked into physics engines and they seem to require a lot of trade-offs. If a rock meets a hard place, what should happen? Gamers have seen the hilarity that can ensue. Designing your own engine allows you to make those trade-offs with the end goal in mind. You can do things like set global force or speed limits, because you know your game's design and the appropriate limits.
- Dracophoenix 4y ago
  How complicated were the physics engines you worked on? How exactly did they differ from turnkey solutions like Bullet, Havok, etc.?

deleted 4y ago

[deleted]

ummonk 4y ago

Impressive stuff. Starting to have the table stakes features that would need for a modern game.

pwdisswordfish0 4y ago

It would be nice if we brought the rule back where it's against HN guidelines to post submissions for every new version of some software. Every Godot thread ends up with the same comments posted, none of them particularly interesting or insightful. And in this particular case, it's not even an official release; it's just a beta!

spookie 4y ago
What's wrong with posting milestones of a great open source project?
terafo 4y ago
Godot 4 entering beta is quite an important thing since that is update that has been in works for a couple of years now and adds lots of new capabilities to Godot.
andrewmcwatters 4y ago
I disagree. I want to see more actual software on Hacker News. This is a space for "hackers," is it not? 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.

jokoon 4y ago

I tried the gdnative thing and implemented a few classes, but there doesn't seem to be a lot of difference with gdextension.

japhib 4y ago
I think the main difference is that GDNative only had access to Godot's scripting API, so it could only manipulate the same stuff that GDScript or C# already could. So in 3.x, if you wanted to manipulate engine internals, you had to "engine extensions" which had to be compiled with the engine itself. But with GDExtension I think you're supposed to be able to do _everything_ that "engine extensions" could do, but without having to re-compile Godot itself.

runevault 4y ago

I played with Godot back in the early 3.x timeframe (3.1? 3.2?) and then fell away and spent some time with Unity. But between some of Unity's missteps and Godot getting dotnet 6 support it is time to give it another go, plus a bunch of nice changes to gdscript that might make it something I'm okay with using (functions are first class citizens now unlike before where you just passed the name of the function as a string which always felt incredibly gross). 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 https://docs.godotengine.org/en/latest/index.html https://docs.godotengine.org/en/latest/index.html

prox 4y ago
Yeah callables are a great addition to 4!
- runevault 4y ago
  Yeah it is part of why I'm going to start with GDScript instead of jumping straight to dotnet 6 (which is what initially got me thinking about trying the new version). 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.
  - prox 4y ago
    Well GDScript and it’s nodetree is great for early days prototyping, even if you decide to redo it later in another fashion. So getting that under your belt is definitely not a bad idea.
  - worble 4y ago
    >Plus the docs/tutorials tend to be more plentiful for GDScript. I quite like reading tutorials in GDScript and trying to convert them to C#, I feel like it strikes a good mix between being told what to do while also getting to go off and explore the engine myself and reinforcing that same learning.

malikNF 4y ago

from the article, >>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.

tmpz22 4y ago
Even seemingly simple games are clocking in at 100GB+ in disk space. I think in terms of performance many games are setting the floor at the Nintendo Switch or the Steam Deck, often ripping out features to get it to run on those platforms (CIV6, 2k etc). This is one reason I really admired Valheim (~1GB). Though even that game had CPU issues (also its an indie title so...).
- hmcamp 4y ago
  Isn’t this a symptom rather than a cause. Because game manufacturers can create larger games with scant regards for people’s resources… they do.
- taejavu 4y ago
  I'm aware of large AAA games taking up that much space (Doom Eternal, Red Dead Redemption 2) but they could hardly be considered "simple". Do you have examples of what you're talking about?

sylware 4y ago

For the elf/linux target, I hope the build containers have a really, really old glibc (dunno which version it is) and the "-static-libgcc" and "-static-libstdc++" are defaults.

3836293648 4y ago
Honestly, given the state of linux games, hope they target musl
- sylware 4y ago
  I would like too. But games needs to load system libs (which are linked to a glibc), and games are not fully libdl-ized (dlopen/dlsym/dlclose). Additionnaly gcc static libstdc++ does not have a "libdl" mode, or even worse: it seems it links to internal glibc symbols. The glibc "should" be libdl clean, minus of few C runtime services I guess. 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.
  - arlcode 4y ago
    I'm not really proficient with games or C/C++ or gcc therefore please forgive me if this question sounds naive: With games already being large downloads wouldn't it make sense to bundle many/most libraries directly instead of relying on system versions? I did some experiments (with rust) and found musl builds and static linked libraries working quite fine.
    - sylware 4y ago
      The part of a game which is "code" is not "large": it is "small", except if a game has really little data, namely it is a small game, and if it is a small game... Then, on elf/linux systems, you have "alternatives" and serious abi instability due mostly, but not only, to gnu symbol versioning (it is pathological in glibc, or it could be a scam). Game binaries cannot expect _their_ alternatives to be there, that's why they have to rely on really only video game core, very video game core libs and the sysv abi(elf). The only way to properly "deal" with abi (modules, symbols, with their versions) stuff on elf/linux, is to dynamically load as much as possible from the system: libdl with only the 3 symbols dlopen/dlsym/dlclose. Ofc, a game should statically link as much as it can (for instance libm), but it requires to dynamically load the video game core libs. Those video game core libs may be linked with musl (hope they have their libdl now), glibc, bionic (if it has a elf loader), etc. If you want full static binaries, you will need a full elf loader into your static binaries. You cannot create such static binaries with the glibc and it is not supported by the set of glibc libs as far as I know (I wonder if it is not done conveniently on purpose to "break" the usage of alternative elf/c runtimes), and if I recall properly you can with musl. The video game core libs on a elf/linux system are: - wayland window system code is static into game binaries, but for key symbols resolution, the game must dynamically load the libxkbcommon library for the xkb client state machine with the user configuration (you may not have the "right" xkb data files for a user). Basically, you feed wayland keycodes to the xkb state machine and based on user specific configuration files, you get out the right key symbol (some games have a mode to bypass key symbol resolution and work directly with keycodes). - x11 system code, the usage is now to dynamically load the client xcb libs and libxkbcommon-x11 (do not use libX11). - android has wayland, but I don't think it's xkb (no libxkbcommon(-x11) lib). - GPU, vulkan by-design does require dynamic loading, and GL fallback will require to dynamically load of the targetted GL libs (some games could be 100% cpu rendering in window systems surfaces using a presentation interface). - sound: you only need to dynamically load the alsa-lib (libasound) as software mixers (dmix/pulseaudio/pipewire/jack/etc) are hidden behind the alsa-lib. (I don't know for android, but alsa has a mobile phone specific configuration interface, don't think it is stable yet though). - for joypad stuff, it is linux specific with the interface of /dev/input/eventN files. In theory, games should be sets of pure and simple ELF64 binaries (with the least amount of relocation types), libdl-ing everything from the system. It means no c runtime main() function, but the sysv ABI entry point, which is a basically a main() anyway. To deal with cross-platform (elf/linux|doz|fruitOS|etc), platform specific fallbacks (on elf/linux platform: wayland->x11, vulkan->gl->cpu, etc), proper compile-time and runtime tables of functions usually will do the trick. Reality check: libstdc++, some libgcc services, and many third-party libs are not libdl-ized. The mitigation is to use "-static-libgcc" and "-static-libstdc++" compiler/linker options and link with an extremely, EXTREMELY old glibc (what godot does). It seems libstdc++ will link with glibc internal symbols if linking happens with a glibc on the build system. NOTES: for i18n games with "full" text input, an input method should be provided by the game itself as you cannot expect a specific input method to be installed on the user system, if any. A GUI toolkit is "above" the window system and related to user alternatives (some may prefere QT, other GTK, or enlightenment or neither of them, then for the same reason than before, a game must package its GUI toolkits. Ofc, if you code in plain and simple C, a lot of those issues can be worked around much more easily.

abledon 4y ago

Logo change in Godot 5 ?

lbotos 4y ago

Early pandemic I was playing around with making a network shooter in godot but I got hung up on a good way to make a shared lib for the client/server "projects". Anyone solve that or have tips? It seemed like I either needed to make a mono repo and toggle the build for client=true but I really wanted to make 3 repos, client, server, and game-core-lib. Would love tips/guides if you have them!

andrewmcwatters 4y ago
In my experience, you’re better off having a single codebase with client/server/shared code and using either the equivalent of ifdefs or conditional blocks gating execution for these states. 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.
- lbotos 4y ago
  Thanks! I think it makes sense, as a non-game programmer it felt "weird" so appreciate the confirmation from your angle.
  - deleted 4y ago
    [deleted]
  - sedatesteak 4y ago
    I also was doing the same but ultimately put it down to wait for Godot 4 (and its niceties such as occlusion culling - I had performance issues with quake 1 maps loaded up through godot). Do you have a repo? I had networking etc running fine with client/server architecture but I would like to see how others have achieved this.

deleted 4y ago

[deleted]

intelVISA 4y ago

Been meaning to pick up Godot one of these days, how does it fare on the wasm/webGPU front?

astlouis44 4y ago
No WebGPU support yet in the engine
- intelVISA 4y ago
  That's a shame, first-class support for the web in any of the major engines would be a killer feature imo.
  - pjmlp 4y ago
    Not really, we are yet to see any WebGL game with the same quality as Infinity Blade. https://www.youtube.com/watch?v=JDvPIhCd8N4 https://www.youtube.com/watch?v=JDvPIhCd8N4
- s-lambert 4y ago
  Why would it have WebGPU support, it's not even supported by any browser[0] at the moment. [0] - https://caniuse.com/webgpu https://caniuse.com/webgpu
mkl95 4y ago
WebGPU's Chrome trial ends in February so we will have to wait until Godot 4.1 most likely.

keyle 4y ago

I'm very excited for Godot 4 beta. 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.

adamrezich 4y ago

haven't used Godot in a couple years but it's good to see the progress on their tile system for 2D games! it was terrible last I checked, yet pretty crucial for making many kinds of simple 2D games

Aeolun 4y ago
It wasn’t ‘terrible’, but it always left me feeling that someone just stopped in the middle of their prototype and said ‘this is good enough’. Looking forward to the new version.

taejavu 4y ago

Does anyone know if there's a build for MacOS yet?

devd00d 4y ago

I love everything Godot. My first experience with 3d was with Opengl 15 years ago and seeing what is now possible (for free) is mindblowing.