25 ms·

Godot for AA/AAA game development – What's missing?

276 points by milliams 4y ago

iFire 4y ago
I'm curious to know anecdotal artist impressions of the 4.0 Godot Engine 3D pipeline, since all the bugs that were too hard earlier are now being looked at and there's momentum to deliver a release. Post Scriptum. I work on the 3d importer pipeline.
mkl95 4y ago
> After an unsatisfactory attempt at using Bullet, Godot 4.0 returns to its own physics engine which, despite not being a high end physics engine like PhysX, aims to offer a lot more flexibility and “just works” capabilities to users. This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.
- teawrecks 4y ago
  Care to elaborate?
  - Supermancho 4y ago
    Godot is still experimenting with Physics engines, rolling back to more primitive homebrew solution. The original statement was straightforward. Ofc, that's just 1 aspect of the engine. There are numerous bugs in the IDE for 2d, which I have encountered. Also, the asynchronous event system quickly becomes cumbersome as a project grows. Ordering becomes important, for which there is no amount of control in Godot (dealing with mouse events, for example). This leaves every developer to implement a stateful dashboard, of sorts, to ensure events are handled in the correct order. This then leads to nondeterministic delays, etc.
  - Zealotux 4y ago
    I will assume a high-end, state of the art physics engine is a must have for any AAA game.
    - tpxl 4y ago
      Not really. There are whole genres where physics isn't really a thing (RTS, card games, turn based strategies). Even where there are physics, they don't need to be complex, just fast. Most fps games, for example Fortnite, don't really use complex physics stuff like joints, and most don't even have fast moving objects.
    - avx56 4y ago
      Most games basically just have rigidbodies. Some cinematic-ish AAAs have fancy cloth simulation or something, but even that is usually prebaked I think.
- seanw444 4y ago
  I was about to say "they can't, the project is supposed to be fully open-source." Because, you know, Nvidia. But I looked it up just to double-check, and wow, that's like one of the only open-source projects Nvidia has ever published. At least that I've seen.
  - sho_hn 4y ago
    I believe you misread the quote; they're not using PhysX.
    - seanw444 4y ago
      No, I read it right. I was saying that I was about to explain why, but my explanation turned out to be incorrect, to my surprise. However, they say: > That said, Godot 4.0 introduces the ability to bind custom physics engines at runtime (without recompiling Godot) via GDExtension, so it’s perfectly possible for the community to integrate other engines such as PhysX, Jolt, or Box2D if need to be. I'm liking this work on GDExtension. It'll make Godot a lot more capable just on its own.
      - croes 4y ago
        But they are only mentioning PhysX as a reference for a high quality phsyics engine. The only tried to integrate Bullet.
      - shmerl 4y ago
        Isn't PhysX hardware accelerated only with CUDA? In that case it would make sense for Godot to avoid it even if it's open source, becasue it's targeted for Nvidia.
  - teawrecks 4y ago
    ianal but it could be a licensing thing. PhysX is BSD3 and Godot is MIT.
- deleted 4y ago
  [deleted]
- Mikeb85 4y ago
  Why? What commercial game is physics-heavy? Most commercial games have scripted character movement (every FPS, RPG, strategy games, basically almost every genre) and the only physics objects are random falling objects that don't affect gameplay... Cloth simulation, cool but can be faked and doesn't affect gameplay. Ragdolls, only really used when characters die and again, can be faked. So name a single AAA game that actually uses proper physics for anything gameplay related?
  - ninepoints 4y ago
    Zelda: Breath of the Wild? HZD? Anything with vehicles? This is a pretty unhinged take
  - ohgodplsno 4y ago
    Most AAA game engines have both ways to bake in physics _and_ to use the exact same system, real time. If you work with Unreal Engine, you use the same tool to get your cloth physics and you can just click a button to bake it and replay it. And this applies to... everything in the engine. Moving outside of your editor absolutely blows, and the less you do it, the better it is. Unless the alternatives are thousands of times better (nothing comes close to Substance Painter, and tools like Houdini still do some things better than internal tools for example. And of course, well, 3D modeling is still a hellscape of zbrush and Maya.), you just stay in with your tools. Nothing sucks more than having yet another editor and needing to have a pipeline to keep everything in sync. It's not about needing crazy physics calculations directly in your engine (although your particle system being affected by it can do cool things), it's about not having to deal with yet another tool that fixes one problem and brings in 20 more. Also, as said, the days of fully scripted movement are pretty much gone. There's physics interactions any time you have vehicles involved unless you want to feel it slide around and feel like crap, for example.
  - enragedcacti 4y ago
    KSP2, Breath of the Wild, Portal/Portal 2, Red Faction, basically every VR game (HL: Alyx definitely qualifies as AAA). I agree it's not all that common but they are definitely out there. As for whether you could build those with Godot's engine I have no idea.
- light_hue_1 4y ago
  > This is a bit of a red flag if one of their goals is for the engine to be used on AAA games. As much of a red flag as say Unreal? Who also dumped both Bullet and PhysX. The solution where you can plug your own engine in is perfect. None of the physics engines are good enough for all games as all engines have discovered. Better to have something simple and in house for 80% of games who need only the basics and then let you bring your own engine. Unreal by the way doesn't even let you do that anymore. PhysX support is being removed entirely in 5.
donmcronald 4y ago
Would Godot be a decent engine for kids around 12-14 years old? I don't know a lot about it, but would like to suggest something for a person I know. I'd also be curious what the Godot support is like in terms of maintaining older releases. I think it would be a mistake to tell a young person to use a beta version since they could hit a lot of bugs and get discouraged, but having them use an existing version that doesn't get a lot of new support might also be discouraging. Does anyone have any thoughts on what they'd suggest for building a simple side scroller?
- Waterluvian 4y ago
  Maybe check out PhaserJS. By using a web engine, it can be easier for them to share their games. It’s also a more forgiving language and environment. PyGame is also a good starting place. If these two seem too elementary for their needs, consider Unity and Godot.
  - tpxl 4y ago
    > By using a web engine, it can be easier for them to share their games Godot and Unity allow exporting into web projects.
    - bcrosby95 4y ago
      At least in Unity, there's lots of sharp edges around webgl.
    - Waterluvian 4y ago
      On paper or to an engineer it might feel comparable but it just is not. WebGL introduces a lot of complexities.
      - johnyzee 4y ago
        Question for you and the sibling comment: What are the issues with WebGL, in your experience? It has been around for over a decade at this point, and I often wonder if it has yet to become a viable target.
lazypenguin 4y ago
Godot is a nice engine. I did a 3D project in it during the 3.0.x era and it was by far the friendliest and easiest engine I have used to-date. I think it gets a lot of love from people (myself included) because of that. The node system is absolutely wonderful to work with and GDScript is not bad as well. It's the most productive I've been in a game engine and I regularly contemplate going all-in on Godot for the future. However, ultimately I abandoned that project because there were too many papercuts in Godot for me to be satisfied. Godot felt like it was a sort of "jack of all trades master of none". Everything worked pretty well but not one thing was fully polished for real world usage. There were ultimately at least one or two shortcomings in every system that just made the experience frustrating when trying to deliver a real project. For example, the asset import system is great but it fell down once I imported by 40,000+ assets or there were limited controls for navigating around the 3D viewport or odd behavior in physics functionality like slide and move that basically meant I needed to write my own equivalent. I am more than willing and able to work around limited features or fix bugs but there's something about "almost does what I need but it's not done yet" that is a real motivation drain. Maybe it's unfair of me, the retort is always "it's open source, contribute back!" but alas that is how I felt as a USER before I considered being a CONTRIBUTOR. I've been tracking Godot since then and there have been HUGE amounts of work in lots of different systems, it's been quite amazing to watch. However, these decisions were quite ambitious as outlined in this blog (rewrite physics, rewrite renderer, massive upgrades to scripting language, etc.) that now the "polished" experience I've been waiting for has been postponed again. I'm optimistic the day will come where Godot becomes "good ole reliable" but until then I will keep waiting and begrudgingly use something else.
- whaaswijk 4y ago
  What’s the “something else” you’re currently using?
- rstupek 4y ago
  That's one of the issues with open source, polishing isn't "fun", where massive rewrites to a new thing are.
  - 4y ago
Rhedox 4y ago
I really don't like the RenderingDevice abstraction they've ended up with. It's strongly reminiscent of OpenGL, doesn't expose command buffers or queues (no async compute). Barriers are too coarse. There's also no support for a bindless approach, no GPU driven rendering or even just GPU culling.
- koolala 4y ago
  What's an example of something that does blindless fully GPU driven rendering? Would it mean CPU lag wouldn't slow your game because the camera could be fully controlled by the GPU?
  - ninepoints 4y ago
    On the contrary, bindless means less work for the CPU. Bindless basically means the GPU is responsible for querying image and buffer resources from a global heap or descriptor table.
  - vblanco 4y ago
    I wrote extensively about that as part of my vulkan guide. https://vkguide.dev/docs/gpudriven https://vkguide.dev/docs/gpudriven . The TLDR of it is that you have the cpu upload scene information to the GPU, and then the GPU performs culling and batching by itself in a series of compute shaders. In most games the scene is 99% static, so you can upload the scene at the beggining and never touch it again. this decreases CPU-GPU traffic by orders of magnitude, and if used right, gives you 10x or more performance improvements. Unreal 5 Nanite tech is based on this concept.
    - Rhedox 4y ago
      Love your site btw!
- MikusR 4y ago
  https://news.ycombinator.com/item?id=15338055 https://news.ycombinator.com/item?id=15338055
mattgreenrocks 4y ago
Do you prefer Godot or Unity for 2D games these days? I did a simple game in Unity and it went pretty well. I'd prefer to use C# if possible. Unity is a very nice environment but IIRC it really seems to chug when reloading user scripts from disk after updates.
- tpxl 4y ago
  C# is pretty well supported in Godot.
- Jensson 4y ago
  You can make unity much faster by disabling "version control" in the package manager, you don't need it but it makes code reload time much much longer. Another huge thing to make things faster is to check the "enable playmode run settings" box and ensure that you don't reload the entire code base every time you press the play button. If a "waiting" box pops up every time you press play then the settings aren't right, you can remove that so entering and exiting play happens instantly.
  - mattgreenrocks 4y ago
    Thank you for the tips, I will give them a shot.
avx56 4y ago
Godot felt frustrating to use every time I've tried it, on both 4.x and 3.x versions. Compared to Unity, it was a massive improvement, the editor was much faster without crashing, and it had a reasonable node-graph design. However, I think some of the "elegant" designs pursued in Godot and some up-and-coming Rust game engines often end up feeling very time-consuming to fit your code in their abstraction (whether it be ECS or nodes), and honestly sometimes it's nice to just sit down, write some terrible macro-ridden C++ that subclasses from 15 different classes in a hierarchy that would make Alan Kay cry, and get an object that can be scripted from your level editor seamlessly. It's janky, but nonetheless it works.
- logicprog 4y ago
  This is why I prefer using libraries to abstract away the complicated parts of doing low level graphics, sound, etc over game engines/frameworks. Engines call me, instead of being called BY me, and that forces me to use their whole environment instead of picking just what I need, as well as forcing me to distort the concepts and abstractions that are most natural for how I think about a problem to fit into the existing way they want things to work. I prefer being able to make my own architectural decisions.
  - karpierz 4y ago
    Is there a set of libraries you'd recommend in this vein?
    - logicprog 4y ago
      Unfortunately, not really. I don't actually have a ton of experience with gamedev outside of engines, I just know what the failings of engines are from using them for a few projects over the years. The one library I might've recommended is a Rust one that's now defunct.
    - IshKebab 4y ago
      I imagine he is thinking of things like SDL, SFML, Macroquad and so on.
sylware 4y ago
On elf/linux, it is missing a static libstdc++ which has the decency to libdl(dlopen/dlsym/dlclose) all its (module/version)s&(symbol/version)s from the system. But the culprit are c++ gcc devs, not godot devs.
- alex7o 4y ago
  Have not tested this but can you not build with llvm's libc++.
  - sylware 4y ago
    I don't think llvm libc++ has a libdl mode, because that would mean that all games coded with c++ should switch to clang.
88stacks 4y ago
I think building a custom physics engine might not be the best way to go. Its a lot of work and super complicated to get right. I'd be worried that focusing on the physics will send them down the wrong path. That given I really do want to see an open source and widely adopted physics engine. I too have used bullet quiet a bit and it worked for my smallish experiments.
- capableweb 4y ago
  Seems like they accommodate using custom/third party physics engines as well, according to the post. The built in one is probably just gonna end up "easy to use, get started and just works", but if you need something better, integrate PhysX yourself.
seanw444 4y ago
Does anyone know where the Godot 4.0 source is? I don't see any branches or tags for it on the main repo on GitHub. I've only seen the pre-compiled dev snapshots. It would seem weird for them to develop an open-source project behind closed doors. I must just be blind?
- throwawayben 4y ago
  I believe it's being developed on the master branch at https://github.com/godotengine/godot https://github.com/godotengine/godot
  - remram 4y ago
    It is weird that the numerous alpha/beta releases [1] are not getting tagged though. [1] https://godotengine.org/article/dev-snapshot-godot-4-0-beta-12/ https://godotengine.org/article/dev-snapshot-godot-4-0-beta-...
    - s-lambert 4y ago
      The organization with the 4.0 changes seems pretty haphazard overall, there's no conclusive list of everything that's changed without going through multiple changelogs for each individual release, or even more cumbersome ways like using git log. For example lots of stuff was renamed but I can't find any good list outside of going into the C++ converter at https://github.com/godotengine/godot/blob/master/editor/project_converter_3_to_4.cpp https://github.com/godotengine/godot/blob/master/editor/proj....
fckgnad 4y ago
I like how they address their own short comings. This is markedly different to a lot of Linux fanatics in the past. (Though I will say for Linux the ux is truly becoming more and more on par with a closed source a os)
- djmips 4y ago
  But they address what they think are their shortcomings which I feel is likely not the actual shortcomings.
bufferoverflow 4y ago
Godot does not have an equivalent for Nanite or Lumen. Real time GI makes such a radical difference in a way games look.
- BudaDude 4y ago
  They are working on it. The streaming section in the article mentions it.
- Mikeb85 4y ago
  Godot has realtime GI... And while it doesn't have streaming as mentioned it does have automatic LOD reduction and occlusion culling which are both a part of what Nanite does.
  - nomel 4y ago
    > it does have automatic LOD reduction Sure, Roblox does too, to some extent. Nanite allows all of this to be taken to the extreme, allowing you to do things that are practically impossible with other engines, including Godot. I think the next gen of games, that use Nanite, are going to stand out in a ridiculous way, which is often appealing for AA/AAA studios.
    - seanclayton 4y ago
      They'll stand out because they'll be 200GB+ on disk and you can only have one or two of them on your console and can't install any others.
      - nomel 4y ago
        I would say that pushing the limits of the hardware has been a constant of gaming, since pong.
      - bufferoverflow 4y ago
        Who cares? Storage is cheap and is getting cheaper. Huge games are inevitable. (unless we come up with some sort of an AI that generates all the objects and textures close enough to the real ones)
jokethrowaway 4y ago
Godot is pretty amazing and certainly a Unity killer for me. It's just that I don't need Unity either. The problem is that Unreal exists and that's so far ahead it's hard to imagine how the OSS world can catch up. Glad to see that Godot is already thinking about streaming assets. The licensing model of Unreal for small businesses is pretty attractive as well as they don't charge until you made 1M. If I made 1M with my game I certainly wouldn't mind paying 50k to Unreal on my next million. On the other side, if I'm doing something for fun (read hacking on unfinished code) and I want to have the perfect abstractions, Unity and Godot are certainly not what I envision. I'd probably just work on something like Bevy.
Avamander 4y ago
HDR and proper VRR/G-Sync/FreeSync support.
Daunk 4y ago
I don't make a lot of "games", but I do make a lot of tools these days (native OS GUI/console-cli etc.). And I feel like Godot wouldn't really be a good fit for such things, or am I wrong?
- tpxl 4y ago
  IIRC Godot is made in Godot, so if you're looking to build a tool like Godot, it's a good fit. For a CLI application? Not so much.
- EamonnMR 4y ago
  It's not going to do much for you in a CLI tool, but it's got a wyswyg GUI editor which is nothing to sneeze at.
frompdx 4y ago
I really enjoy creating in Godot. However, I am far from a AA/AAA game dev. Godot is a great tool for creating games independently. Creating 2D tilemaps is significantly improved in Godot 4. For me, the most exciting thing to happen to Godot is the Steam Deck. The question of how to run Godot on the Nintendo Switch came up frequently on r/godot. There was no practical avenue for small time devs. I'm excited to see what doors the Steam Deck will open as an alternative handheld gaming device.
- Buttons840 4y ago
  I think people are interested in consoles because they want access to those communities. There's a lot of people that wont deal with PC gaming, and those people wont use a Steam Deck either. I would want my game to be available to console gamers, for profit and to share my with with as many as possible. As good as the Steam Deck may be, I don't think it will lessen interest in the video game consoles.
  - Mikeb85 4y ago
    You can't just become a console developer though... You need to have proven releases on desktop or mobile before any console maker will even let you touch their devkit...
- singingboyo 4y ago
  I think 2D tilemaps is a great example of how quickly Godot can fall over terribly, though. And that's (as has been mentioned elsewhere) mostly an issue of polish. Godot can do the basic version of a lot of things, but if you need more you often get very deep into the weeds, very quickly. With Godot 4, 2D tilemaps are incredibly awkward to use alongside random generation. You have (had?) to reset neighbor tiles yourself to get it to pick the correct sprite. Setting large numbers of tiles at once is/was terribly slow. The APIs are just a bit awkward, too. Godot 3 didn't have any of these issues. Basically, once you get off the beaten path, things become noticeably janky in a lot of places. I'm sure some of the obvious bugs will or have already been fixed for the beta, but some, like tilemaps, seemed to simply have a response of "it's working as intended", and others (like GDScript scalability or native DLL hot reload) are simply not fixable without another redesign.
Thaxll 4y ago
What's missing and not in the article is a showcase game, a proof that this engine can deliver a real AA/AAA on the market.
- gamblor956 4y ago
  Godot's showcase game was supposed to be the poorly-reviewed remaster of Sonic Colors Ultimate that came out 2 years ago. Unfortunately, the remaster was extremely buggy to the point of being unplayable on a PC. And Godot has pretty much been DOA for AA/AAA development since then. It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement and now promise to make an "engine agnostic" interface for physics engines, which is significantly more more work than just figuring out how to implement a single physics engine (and extending that implementation to be engine agnostic). Godot is the anti-Blender; it's perpetually 70% of the way "there" but they are always abandoning that last 30% because it's too hard, or too boring, to finish. (For comparison, at this point in its lifecycle, i.e., 9 years old, Unity was well-polished and had already been the choice for indie and mobile game development for several years. In the past week alone, multiple one-developer games made in Unity have made it to the front page of HN.)
  - light_hue_1 4y ago
    > It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement If it's "too hard" for Unreal, why wouldn't it be too hard for Godot? I think this is really an unfair criticism when you look at other game engines. Unreal had Bullet support in version 3 and dumped it. And they had PhysX in version 4 and dumped it in 5. > now promise to make an "engine agnostic" interface for physics engines Which is exactly what Unity did. It seems like you have a problem with what Godot does no matter what they do, even when they just follow what Unity and Unreal are doing.
    - gamblor956 4y ago
      The difference is that you can, and could, make fully functional physics-based games in Unity and Unreal because their in-house engines were accurate and performant enough. The point of integrating Bullet/physX was to provide the option for even more accurate physics engines. Godot's in-house engine is neither performant, nor accurate, and it boggles the mind to think that having abandoned the relatively easy task of implementing a single physics engine written in the same language as their game engine (and that their competitors were able to integrate and support) that they would be able to accomplish the far more difficult task of implementing an engine-agnostic interface supporting multiple physics engines, as accomplishing the latter would require them to first accomplish the former...
bdickason 4y ago
I've been using Godot off and on for the past month prototyping a mobile game. The editor loads/refreshes very quickly on a macbook air m1 (which hasn't been the case w/ Unity of late). The workflow is intuitive and for reasonably scoped games, it's a great fit. I was surprised to not feel limited by gdscript (having no python background and doing most work in JS for the past decade). I picked it up quickly and it's well documented and integrated into vscode. Not sure if it would be my choice for a large game with millions of entities (e.g. an online RPG that needs an ECS system) but for small 2d games it is a delight to work with. I may be the minority here, but I hope Godot doesn't try to cater to AA/AAA devs and keeps small indies front and center as the focus.
qwery 4y ago
Whether it's the scripting language or the physics engine, Godot's in-house solutions (and general differences to other game engines) always draw a bit of criticism. The article mentions the 'considerable amount of issues' for the in-house physics solution, but it doesn't make a direct statement about the quantity or severity of issues to do with including bullet over the years. Hugely powerful and complex physics engines have become the default solution to practically everything motion or collision related in games. But most games don't need most of what the big/serious physics engines provide. Unfortunately, there is an expectation that game engines come with one of these included and so they are, usually as the only built-in way to perform collision detection. If you're making a game that has modest 'physics' requirements, you're stuck trying to break the big physics engine to get it to do less. If you're making a game that does have a need for a high-end solution (e.g. PhysX), it becomes increasingly painful as you are forced to access the physics engine via the APIs that the game engine provided.
tekni5 4y ago
Has 3D performance improved in Godot 4? I remember messing with 3 and the overall performance was pretty terrible compared just about any other 3D engine as soon as you started adding any complexity.
caniszczyk 4y ago
If you are looking for a AAA open source engine today with an open community, check out https://www.o3de.org https://www.o3de.org I hope Godot continues to improve and competition increases in the open source AAA gaming engine space as this space is well overdue for fully open source options.
- remram 4y ago
  Seems to be a "developer preview" with no released games.
  - m0guz 4y ago
    It is actually Amazon's Lumberyard, which was also CryEngine fork.
    - remram 4y ago
      Are there any released games built with Lumberyard?
- 41209 4y ago
  I wouldn't attach myself to it, the community( Amazon employees mostly) are friendly, they'll even offer to help you with any issues you run into. But seriously, no games exist, no real demo projects with it exist. For some reason it uses Lua instead of strongly typed language like C#. Seriously, games NEED types. At scale projects get really messy without them. Oh wait, O3de pushes script canvas on you. At the end of the day , I find myself getting sucked back into Unity. Unity could be better, but it's still the best engine for most people. Much of that is just due to documentation. For some reason Amazon decided effectively hide all of it's old Lumberyard docs and examples when they rebranded as O3de. No one will ever know why.
malkia 4y ago
Your users at an AAA studio (artists, scripters, builders, audio designers, etc.) constantly require support: features, bug fixes, band-aids. An engine does not give you that, ultimately you need people.
EamonnMR 4y ago
I love Godot to pieces, have used it for several games and will continue to do so. Here's what's missing: * Sane animation import toolchain. The current one from blender is enormously finicky. * Good enough pathfinding (supposed to be fixed in GD4) * Better native map support (heighmap or some sort of interior) * Fix the 2d tileset editor, doing anything interesting in it is way too labor intensive because it lacks copy paste for tile parameters. A better system would let you set up a small number of tile templates and just map tiles to templates to quickly rig up huge tilesets.
- sli 4y ago
  The new tile editor works much in the way you describe and people overall seem to hate it. I quite like it. I'll grant them that it's a bit weird and needs some cleanup (there's a tab that's in two places for two subtly different purposes, for example), but I still prefer it to the old version. But the workflow of designing e.g. a tile hitbox and then applying it quickly to multiple tiles is exactly how it works now.
  - EamonnMR 4y ago
    Awesome. I built a decent little top down tile shooter with free graphics but realized making more levels would be mostly an exercise in editing tiny tile squares so I decided to do other things.
jarsin 4y ago
Does godot have multiplayer options? I know Unity abandoned their old networking and is working on a new one, but at least there are open source options like mirror, and paid options like photon fusion.
- suby 4y ago
  They have multiplayer in the form of a wrapper around ENet.
- andrewmcwatters 4y ago
  The answer is no, you have to write your own networking. They provide enough to say, “Yes, we have multiplayer support,” but the real answer is “No,” because you still have to do it yourself. It’s a farce. It’s like including fmod bindings and saying yes we support fmod, but having zero integration. There’s no serialization, deserialization, no prediction, no reconciliation, no interpolation, nothing.
liamkf 4y ago
I think Godot is making good steady progress. I also think it's a sign of where Godot is in development that the scripting and artist interfaces are mentioned at the tail end. There's a vast graveyard of unused "programmer-led" features on big game engines, ignored by the artists or designers who make up 90% of the production team because of a lack of editor polish or discoverability. Between that and... no Perforce support (what... 95% of AA+ game studios use), I would bet that Godot's first usage for AA/AAA will come from a new team that grows an indie success and with a plucky engine team that can keep bolting on exactly what they need for their game to grow. I'll be interested to see what it is! :)
ydnaclementine 4y ago
I don't do game programming, but want to learn. I'm very keen on finding a nice project based book to learn 4.0 once it's released
- sprkwd 4y ago
  I’m exactly the same. Looking forward to it.
tete 4y ago
Super subjective. Not a Godot developer/user/..., just a gamer who played games that were developed with Godot. Not much I'd say, given that there's quite a few "successful" (eg. enough buyers for many positive reviews) games on Steam. Also based on those games typically being very small studios I'd assume that if a company that repeatedly throws out AAA games (that aren't just some small improvements of an existing codebase) would use Godot to do so it would be a AAA game.
everyone 4y ago
I wonder will Godot be the next Unity? Everyone I know who has seriously gotten into it complains about bugs in fundamental things (like floating point operations in one case) Thinking back, early Unity was rock solid. The core stuff was great, it's all the newer stuff in Unity that sucks. I guess if people keep patching Godot then it will be fine.
djmips 4y ago
A red flag for me is all the talk about optimizing which focuses on making things multi-threaded as if that was a silver bullet. Recently we took multi-threading out of a portion of a renderer and then fixed what actually was slow and it's now running single-threaded and much faster than the previous multi-threaded version. Learning to understand what your real bottlenecks comes from experience in how to profile. Saying your are going to fix things by going multi-threaded is great and all but first understand why your single threaded performance is poor. Not all systems are going to respond simply by going multi-threaded.
JakeAl 4y ago
Keep it away from AAA. AAA means bloatware. Keep it lean and clean and modular. Focus on ease of use, not making millions off the engine.
nosvince 4y ago
Can someone ask why does it needs to cater to AA and AAA studios? Unreal is already great for this, with Unity trying it's best to get there. We need an engine focused on the problems of smaller developers, especially on mobile. Defold is another open source engine that seems focused on this, which makes more sense to me.
SXX 4y ago
Okay I'm little late to the party, but our company actually released commercial game on Steam and GOG. It called Dwarven Skykeep and it built in Godot. Now I'll list a few things that for some reason are not mentioned in article, but crucial for Godot success in commercial game development. 1. Official console support and partnership with platform owners. Yes this code will be closed source, but without this there can't be many AA/AAA games. I'm aware that Godot Foundation is a step to solve this, but it's not yet here and unfortunately 3rd-party companies selling porting services are not sufficient. 2. Once console support is here there will be dire need for game publishers who have pipeline to fund and do marketing for games using Godot. Unfortunately it's very hard to find a publisher for game that built with Godot. 3. Godot need more stable and official support for pesky closed source ecosystems like Steamworks, GOG, etc. There are plugins for that, but they are not as easy to use as in proprietary competitors and not easy to find. 4. There need to be much better tooling for debugging and performance profiling. I've already had some lengthy discussion about it in previous Godot topics so I'm not gonna elaborate much. Its slowly being worked on and improved, but it still inferior than competition. I love open source and love working with Godot, but unfortunately it's difficult to make commercial games when ecosystem is not there. Game development is hard enough on it's own and sometimes you have to make a choice of whatever you want to support FOSS or you want to make a great games.
- georgeecollins 4y ago
  That game looks cool. Good job!
  - aiqq 4y ago
    Yeah but it doesnt seem to be selling and looks like thousands of other games released daily.
    - SXX 4y ago
      Making games is hard and marketing them for the right audience is even harder. Anyone who want ot make make game development their primary job have to take a risk of their game not becoming bestseller. Though in reality 90% of games simply never getting to release at all. At the same time I think 2 years working with Godot full time is enough to talk about it's strong and weak sides including ecosystem problems that make commercial game development even harder.
m4nu3l 4y ago
I have been using Godot since it was open-sourced in 2014. I'm also familiar with the source code and I have made some contribution. I mostly created prototypes until two years ago when I started working my first commercial project, it's called Outer Space: War Gears and it's a six-degrees-of freedom space shooter. I chose Godot mostly because of the familiarity and hackability. However I spent a lot (too much) time working around/fixing obscure bugs in the engine. I figured I was definitely the first one to use some features (given they really didn't work), like using GDNative in a MT fashion. Another issue (for Godot 3.x, Godot 4 is much better in this regard) is that GDScript is really slow. I got to a point where it took longer to run all the script than to run the physics step (and my game is physics-based, all actors are rigid bodies!). Luckily GDScript is fully parallelizable as it doesn't have a GIL. So now I run a lot of code in thread pools and do a lot of sub-step optimizations. If you do use it with MT, though, you won't be able to debug GDScript and profile on any other thread than the main one - for better profiling I just use perf. However I'm reluctant to use Unity and UE because even just loading the project in the editor is much faster in Godot. I like it being so lightweight. I also like how you can easily write native modules for it. Recompiling the Engine is quite fast. I hope Godot 4, with more support from companies and the community will get much better.
- krapp 4y ago
  At the very least, language support should be better thanks to GDExtension. I'm not a fan of GDScript either and C# is too heavy for my tastes, so I'm waiting to see which alternate language implementation matures enough for someone to actually publish a game with it.

276 points by milliams 4y ago

I'm curious to know anecdotal artist impressions of the 4.0 Godot Engine 3D pipeline, since all the bugs that were too hard earlier are now being looked at and there's momentum to deliver a release. Post Scriptum. I work on the 3d importer pipeline.

mkl95 4y ago

> After an unsatisfactory attempt at using Bullet, Godot 4.0 returns to its own physics engine which, despite not being a high end physics engine like PhysX, aims to offer a lot more flexibility and “just works” capabilities to users. This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.

teawrecks 4y ago
Care to elaborate?
- Supermancho 4y ago
  Godot is still experimenting with Physics engines, rolling back to more primitive homebrew solution. The original statement was straightforward. Ofc, that's just 1 aspect of the engine. There are numerous bugs in the IDE for 2d, which I have encountered. Also, the asynchronous event system quickly becomes cumbersome as a project grows. Ordering becomes important, for which there is no amount of control in Godot (dealing with mouse events, for example). This leaves every developer to implement a stateful dashboard, of sorts, to ensure events are handled in the correct order. This then leads to nondeterministic delays, etc.
- Zealotux 4y ago
  I will assume a high-end, state of the art physics engine is a must have for any AAA game.
  - tpxl 4y ago
    Not really. There are whole genres where physics isn't really a thing (RTS, card games, turn based strategies). Even where there are physics, they don't need to be complex, just fast. Most fps games, for example Fortnite, don't really use complex physics stuff like joints, and most don't even have fast moving objects.
  - avx56 4y ago
    Most games basically just have rigidbodies. Some cinematic-ish AAAs have fancy cloth simulation or something, but even that is usually prebaked I think.
seanw444 4y ago
I was about to say "they can't, the project is supposed to be fully open-source." Because, you know, Nvidia. But I looked it up just to double-check, and wow, that's like one of the only open-source projects Nvidia has ever published. At least that I've seen.
- sho_hn 4y ago
  I believe you misread the quote; they're not using PhysX.
  - seanw444 4y ago
    No, I read it right. I was saying that I was about to explain why, but my explanation turned out to be incorrect, to my surprise. However, they say: > That said, Godot 4.0 introduces the ability to bind custom physics engines at runtime (without recompiling Godot) via GDExtension, so it’s perfectly possible for the community to integrate other engines such as PhysX, Jolt, or Box2D if need to be. I'm liking this work on GDExtension. It'll make Godot a lot more capable just on its own.
    - croes 4y ago
      But they are only mentioning PhysX as a reference for a high quality phsyics engine. The only tried to integrate Bullet.
    - shmerl 4y ago
      Isn't PhysX hardware accelerated only with CUDA? In that case it would make sense for Godot to avoid it even if it's open source, becasue it's targeted for Nvidia.
- teawrecks 4y ago
  ianal but it could be a licensing thing. PhysX is BSD3 and Godot is MIT.
deleted 4y ago
[deleted]
Mikeb85 4y ago
Why? What commercial game is physics-heavy? Most commercial games have scripted character movement (every FPS, RPG, strategy games, basically almost every genre) and the only physics objects are random falling objects that don't affect gameplay... Cloth simulation, cool but can be faked and doesn't affect gameplay. Ragdolls, only really used when characters die and again, can be faked. So name a single AAA game that actually uses proper physics for anything gameplay related?
- ninepoints 4y ago
  Zelda: Breath of the Wild? HZD? Anything with vehicles? This is a pretty unhinged take
- ohgodplsno 4y ago
  Most AAA game engines have both ways to bake in physics _and_ to use the exact same system, real time. If you work with Unreal Engine, you use the same tool to get your cloth physics and you can just click a button to bake it and replay it. And this applies to... everything in the engine. Moving outside of your editor absolutely blows, and the less you do it, the better it is. Unless the alternatives are thousands of times better (nothing comes close to Substance Painter, and tools like Houdini still do some things better than internal tools for example. And of course, well, 3D modeling is still a hellscape of zbrush and Maya.), you just stay in with your tools. Nothing sucks more than having yet another editor and needing to have a pipeline to keep everything in sync. It's not about needing crazy physics calculations directly in your engine (although your particle system being affected by it can do cool things), it's about not having to deal with yet another tool that fixes one problem and brings in 20 more. Also, as said, the days of fully scripted movement are pretty much gone. There's physics interactions any time you have vehicles involved unless you want to feel it slide around and feel like crap, for example.
- enragedcacti 4y ago
  KSP2, Breath of the Wild, Portal/Portal 2, Red Faction, basically every VR game (HL: Alyx definitely qualifies as AAA). I agree it's not all that common but they are definitely out there. As for whether you could build those with Godot's engine I have no idea.
light_hue_1 4y ago
> This is a bit of a red flag if one of their goals is for the engine to be used on AAA games. As much of a red flag as say Unreal? Who also dumped both Bullet and PhysX. The solution where you can plug your own engine in is perfect. None of the physics engines are good enough for all games as all engines have discovered. Better to have something simple and in house for 80% of games who need only the basics and then let you bring your own engine. Unreal by the way doesn't even let you do that anymore. PhysX support is being removed entirely in 5.

donmcronald 4y ago

Would Godot be a decent engine for kids around 12-14 years old? I don't know a lot about it, but would like to suggest something for a person I know. I'd also be curious what the Godot support is like in terms of maintaining older releases. I think it would be a mistake to tell a young person to use a beta version since they could hit a lot of bugs and get discouraged, but having them use an existing version that doesn't get a lot of new support might also be discouraging. Does anyone have any thoughts on what they'd suggest for building a simple side scroller?

Waterluvian 4y ago
Maybe check out PhaserJS. By using a web engine, it can be easier for them to share their games. It’s also a more forgiving language and environment. PyGame is also a good starting place. If these two seem too elementary for their needs, consider Unity and Godot.
- tpxl 4y ago
  > By using a web engine, it can be easier for them to share their games Godot and Unity allow exporting into web projects.
  - bcrosby95 4y ago
    At least in Unity, there's lots of sharp edges around webgl.
  - Waterluvian 4y ago
    On paper or to an engineer it might feel comparable but it just is not. WebGL introduces a lot of complexities.
    - johnyzee 4y ago
      Question for you and the sibling comment: What are the issues with WebGL, in your experience? It has been around for over a decade at this point, and I often wonder if it has yet to become a viable target.

lazypenguin 4y ago

Godot is a nice engine. I did a 3D project in it during the 3.0.x era and it was by far the friendliest and easiest engine I have used to-date. I think it gets a lot of love from people (myself included) because of that. The node system is absolutely wonderful to work with and GDScript is not bad as well. It's the most productive I've been in a game engine and I regularly contemplate going all-in on Godot for the future. However, ultimately I abandoned that project because there were too many papercuts in Godot for me to be satisfied. Godot felt like it was a sort of "jack of all trades master of none". Everything worked pretty well but not one thing was fully polished for real world usage. There were ultimately at least one or two shortcomings in every system that just made the experience frustrating when trying to deliver a real project. For example, the asset import system is great but it fell down once I imported by 40,000+ assets or there were limited controls for navigating around the 3D viewport or odd behavior in physics functionality like slide and move that basically meant I needed to write my own equivalent. I am more than willing and able to work around limited features or fix bugs but there's something about "almost does what I need but it's not done yet" that is a real motivation drain. Maybe it's unfair of me, the retort is always "it's open source, contribute back!" but alas that is how I felt as a USER before I considered being a CONTRIBUTOR. I've been tracking Godot since then and there have been HUGE amounts of work in lots of different systems, it's been quite amazing to watch. However, these decisions were quite ambitious as outlined in this blog (rewrite physics, rewrite renderer, massive upgrades to scripting language, etc.) that now the "polished" experience I've been waiting for has been postponed again. I'm optimistic the day will come where Godot becomes "good ole reliable" but until then I will keep waiting and begrudgingly use something else.

whaaswijk 4y ago
What’s the “something else” you’re currently using?
rstupek 4y ago
That's one of the issues with open source, polishing isn't "fun", where massive rewrites to a new thing are.
- 4y ago

Rhedox 4y ago

I really don't like the RenderingDevice abstraction they've ended up with. It's strongly reminiscent of OpenGL, doesn't expose command buffers or queues (no async compute). Barriers are too coarse. There's also no support for a bindless approach, no GPU driven rendering or even just GPU culling.

koolala 4y ago
What's an example of something that does blindless fully GPU driven rendering? Would it mean CPU lag wouldn't slow your game because the camera could be fully controlled by the GPU?
- ninepoints 4y ago
  On the contrary, bindless means less work for the CPU. Bindless basically means the GPU is responsible for querying image and buffer resources from a global heap or descriptor table.
- vblanco 4y ago
  I wrote extensively about that as part of my vulkan guide. https://vkguide.dev/docs/gpudriven https://vkguide.dev/docs/gpudriven . The TLDR of it is that you have the cpu upload scene information to the GPU, and then the GPU performs culling and batching by itself in a series of compute shaders. In most games the scene is 99% static, so you can upload the scene at the beggining and never touch it again. this decreases CPU-GPU traffic by orders of magnitude, and if used right, gives you 10x or more performance improvements. Unreal 5 Nanite tech is based on this concept.
  - Rhedox 4y ago
    Love your site btw!
MikusR 4y ago
https://news.ycombinator.com/item?id=15338055 https://news.ycombinator.com/item?id=15338055

mattgreenrocks 4y ago

Do you prefer Godot or Unity for 2D games these days? I did a simple game in Unity and it went pretty well. I'd prefer to use C# if possible. Unity is a very nice environment but IIRC it really seems to chug when reloading user scripts from disk after updates.

tpxl 4y ago
C# is pretty well supported in Godot.
Jensson 4y ago
You can make unity much faster by disabling "version control" in the package manager, you don't need it but it makes code reload time much much longer. Another huge thing to make things faster is to check the "enable playmode run settings" box and ensure that you don't reload the entire code base every time you press the play button. If a "waiting" box pops up every time you press play then the settings aren't right, you can remove that so entering and exiting play happens instantly.
- mattgreenrocks 4y ago
  Thank you for the tips, I will give them a shot.

avx56 4y ago

Godot felt frustrating to use every time I've tried it, on both 4.x and 3.x versions. Compared to Unity, it was a massive improvement, the editor was much faster without crashing, and it had a reasonable node-graph design. However, I think some of the "elegant" designs pursued in Godot and some up-and-coming Rust game engines often end up feeling very time-consuming to fit your code in their abstraction (whether it be ECS or nodes), and honestly sometimes it's nice to just sit down, write some terrible macro-ridden C++ that subclasses from 15 different classes in a hierarchy that would make Alan Kay cry, and get an object that can be scripted from your level editor seamlessly. It's janky, but nonetheless it works.

logicprog 4y ago
This is why I prefer using libraries to abstract away the complicated parts of doing low level graphics, sound, etc over game engines/frameworks. Engines call me, instead of being called BY me, and that forces me to use their whole environment instead of picking just what I need, as well as forcing me to distort the concepts and abstractions that are most natural for how I think about a problem to fit into the existing way they want things to work. I prefer being able to make my own architectural decisions.
- karpierz 4y ago
  Is there a set of libraries you'd recommend in this vein?
  - logicprog 4y ago
    Unfortunately, not really. I don't actually have a ton of experience with gamedev outside of engines, I just know what the failings of engines are from using them for a few projects over the years. The one library I might've recommended is a Rust one that's now defunct.
  - IshKebab 4y ago
    I imagine he is thinking of things like SDL, SFML, Macroquad and so on.

sylware 4y ago

On elf/linux, it is missing a static libstdc++ which has the decency to libdl(dlopen/dlsym/dlclose) all its (module/version)s&(symbol/version)s from the system. But the culprit are c++ gcc devs, not godot devs.

alex7o 4y ago
Have not tested this but can you not build with llvm's libc++.
- sylware 4y ago
  I don't think llvm libc++ has a libdl mode, because that would mean that all games coded with c++ should switch to clang.

88stacks 4y ago

I think building a custom physics engine might not be the best way to go. Its a lot of work and super complicated to get right. I'd be worried that focusing on the physics will send them down the wrong path. That given I really do want to see an open source and widely adopted physics engine. I too have used bullet quiet a bit and it worked for my smallish experiments.

capableweb 4y ago
Seems like they accommodate using custom/third party physics engines as well, according to the post. The built in one is probably just gonna end up "easy to use, get started and just works", but if you need something better, integrate PhysX yourself.

seanw444 4y ago

Does anyone know where the Godot 4.0 source is? I don't see any branches or tags for it on the main repo on GitHub. I've only seen the pre-compiled dev snapshots. It would seem weird for them to develop an open-source project behind closed doors. I must just be blind?

throwawayben 4y ago
I believe it's being developed on the master branch at https://github.com/godotengine/godot https://github.com/godotengine/godot
- remram 4y ago
  It is weird that the numerous alpha/beta releases [1] are not getting tagged though. [1] https://godotengine.org/article/dev-snapshot-godot-4-0-beta-12/ https://godotengine.org/article/dev-snapshot-godot-4-0-beta-...
  - s-lambert 4y ago
    The organization with the 4.0 changes seems pretty haphazard overall, there's no conclusive list of everything that's changed without going through multiple changelogs for each individual release, or even more cumbersome ways like using git log. For example lots of stuff was renamed but I can't find any good list outside of going into the C++ converter at https://github.com/godotengine/godot/blob/master/editor/project_converter_3_to_4.cpp https://github.com/godotengine/godot/blob/master/editor/proj....

fckgnad 4y ago

I like how they address their own short comings. This is markedly different to a lot of Linux fanatics in the past. (Though I will say for Linux the ux is truly becoming more and more on par with a closed source a os)

djmips 4y ago
But they address what they think are their shortcomings which I feel is likely not the actual shortcomings.

bufferoverflow 4y ago

Godot does not have an equivalent for Nanite or Lumen. Real time GI makes such a radical difference in a way games look.

BudaDude 4y ago
They are working on it. The streaming section in the article mentions it.
Mikeb85 4y ago
Godot has realtime GI... And while it doesn't have streaming as mentioned it does have automatic LOD reduction and occlusion culling which are both a part of what Nanite does.
- nomel 4y ago
  > it does have automatic LOD reduction Sure, Roblox does too, to some extent. Nanite allows all of this to be taken to the extreme, allowing you to do things that are practically impossible with other engines, including Godot. I think the next gen of games, that use Nanite, are going to stand out in a ridiculous way, which is often appealing for AA/AAA studios.
  - seanclayton 4y ago
    They'll stand out because they'll be 200GB+ on disk and you can only have one or two of them on your console and can't install any others.
    - nomel 4y ago
      I would say that pushing the limits of the hardware has been a constant of gaming, since pong.
    - bufferoverflow 4y ago
      Who cares? Storage is cheap and is getting cheaper. Huge games are inevitable. (unless we come up with some sort of an AI that generates all the objects and textures close enough to the real ones)

jokethrowaway 4y ago

Godot is pretty amazing and certainly a Unity killer for me. It's just that I don't need Unity either. The problem is that Unreal exists and that's so far ahead it's hard to imagine how the OSS world can catch up. Glad to see that Godot is already thinking about streaming assets. The licensing model of Unreal for small businesses is pretty attractive as well as they don't charge until you made 1M. If I made 1M with my game I certainly wouldn't mind paying 50k to Unreal on my next million. On the other side, if I'm doing something for fun (read hacking on unfinished code) and I want to have the perfect abstractions, Unity and Godot are certainly not what I envision. I'd probably just work on something like Bevy.

Avamander 4y ago

HDR and proper VRR/G-Sync/FreeSync support.

Daunk 4y ago

I don't make a lot of "games", but I do make a lot of tools these days (native OS GUI/console-cli etc.). And I feel like Godot wouldn't really be a good fit for such things, or am I wrong?

tpxl 4y ago
IIRC Godot is made in Godot, so if you're looking to build a tool like Godot, it's a good fit. For a CLI application? Not so much.
EamonnMR 4y ago
It's not going to do much for you in a CLI tool, but it's got a wyswyg GUI editor which is nothing to sneeze at.

frompdx 4y ago

I really enjoy creating in Godot. However, I am far from a AA/AAA game dev. Godot is a great tool for creating games independently. Creating 2D tilemaps is significantly improved in Godot 4. For me, the most exciting thing to happen to Godot is the Steam Deck. The question of how to run Godot on the Nintendo Switch came up frequently on r/godot. There was no practical avenue for small time devs. I'm excited to see what doors the Steam Deck will open as an alternative handheld gaming device.

Buttons840 4y ago
I think people are interested in consoles because they want access to those communities. There's a lot of people that wont deal with PC gaming, and those people wont use a Steam Deck either. I would want my game to be available to console gamers, for profit and to share my with with as many as possible. As good as the Steam Deck may be, I don't think it will lessen interest in the video game consoles.
- Mikeb85 4y ago
  You can't just become a console developer though... You need to have proven releases on desktop or mobile before any console maker will even let you touch their devkit...
singingboyo 4y ago
I think 2D tilemaps is a great example of how quickly Godot can fall over terribly, though. And that's (as has been mentioned elsewhere) mostly an issue of polish. Godot can do the basic version of a lot of things, but if you need more you often get very deep into the weeds, very quickly. With Godot 4, 2D tilemaps are incredibly awkward to use alongside random generation. You have (had?) to reset neighbor tiles yourself to get it to pick the correct sprite. Setting large numbers of tiles at once is/was terribly slow. The APIs are just a bit awkward, too. Godot 3 didn't have any of these issues. Basically, once you get off the beaten path, things become noticeably janky in a lot of places. I'm sure some of the obvious bugs will or have already been fixed for the beta, but some, like tilemaps, seemed to simply have a response of "it's working as intended", and others (like GDScript scalability or native DLL hot reload) are simply not fixable without another redesign.

Thaxll 4y ago

What's missing and not in the article is a showcase game, a proof that this engine can deliver a real AA/AAA on the market.

gamblor956 4y ago
Godot's showcase game was supposed to be the poorly-reviewed remaster of Sonic Colors Ultimate that came out 2 years ago. Unfortunately, the remaster was extremely buggy to the point of being unplayable on a PC. And Godot has pretty much been DOA for AA/AAA development since then. It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement and now promise to make an "engine agnostic" interface for physics engines, which is significantly more more work than just figuring out how to implement a single physics engine (and extending that implementation to be engine agnostic). Godot is the anti-Blender; it's perpetually 70% of the way "there" but they are always abandoning that last 30% because it's too hard, or too boring, to finish. (For comparison, at this point in its lifecycle, i.e., 9 years old, Unity was well-polished and had already been the choice for indie and mobile game development for several years. In the past week alone, multiple one-developer games made in Unity have made it to the front page of HN.)
- light_hue_1 4y ago
  > It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement If it's "too hard" for Unreal, why wouldn't it be too hard for Godot? I think this is really an unfair criticism when you look at other game engines. Unreal had Bullet support in version 3 and dumped it. And they had PhysX in version 4 and dumped it in 5. > now promise to make an "engine agnostic" interface for physics engines Which is exactly what Unity did. It seems like you have a problem with what Godot does no matter what they do, even when they just follow what Unity and Unreal are doing.
  - gamblor956 4y ago
    The difference is that you can, and could, make fully functional physics-based games in Unity and Unreal because their in-house engines were accurate and performant enough. The point of integrating Bullet/physX was to provide the option for even more accurate physics engines. Godot's in-house engine is neither performant, nor accurate, and it boggles the mind to think that having abandoned the relatively easy task of implementing a single physics engine written in the same language as their game engine (and that their competitors were able to integrate and support) that they would be able to accomplish the far more difficult task of implementing an engine-agnostic interface supporting multiple physics engines, as accomplishing the latter would require them to first accomplish the former...

bdickason 4y ago

I've been using Godot off and on for the past month prototyping a mobile game. The editor loads/refreshes very quickly on a macbook air m1 (which hasn't been the case w/ Unity of late). The workflow is intuitive and for reasonably scoped games, it's a great fit. I was surprised to not feel limited by gdscript (having no python background and doing most work in JS for the past decade). I picked it up quickly and it's well documented and integrated into vscode. Not sure if it would be my choice for a large game with millions of entities (e.g. an online RPG that needs an ECS system) but for small 2d games it is a delight to work with. I may be the minority here, but I hope Godot doesn't try to cater to AA/AAA devs and keeps small indies front and center as the focus.

qwery 4y ago

Whether it's the scripting language or the physics engine, Godot's in-house solutions (and general differences to other game engines) always draw a bit of criticism. The article mentions the 'considerable amount of issues' for the in-house physics solution, but it doesn't make a direct statement about the quantity or severity of issues to do with including bullet over the years. Hugely powerful and complex physics engines have become the default solution to practically everything motion or collision related in games. But most games don't need most of what the big/serious physics engines provide. Unfortunately, there is an expectation that game engines come with one of these included and so they are, usually as the only built-in way to perform collision detection. If you're making a game that has modest 'physics' requirements, you're stuck trying to break the big physics engine to get it to do less. If you're making a game that does have a need for a high-end solution (e.g. PhysX), it becomes increasingly painful as you are forced to access the physics engine via the APIs that the game engine provided.

tekni5 4y ago

Has 3D performance improved in Godot 4? I remember messing with 3 and the overall performance was pretty terrible compared just about any other 3D engine as soon as you started adding any complexity.

caniszczyk 4y ago

If you are looking for a AAA open source engine today with an open community, check out https://www.o3de.org https://www.o3de.org I hope Godot continues to improve and competition increases in the open source AAA gaming engine space as this space is well overdue for fully open source options.

remram 4y ago
Seems to be a "developer preview" with no released games.
- m0guz 4y ago
  It is actually Amazon's Lumberyard, which was also CryEngine fork.
  - remram 4y ago
    Are there any released games built with Lumberyard?
41209 4y ago
I wouldn't attach myself to it, the community( Amazon employees mostly) are friendly, they'll even offer to help you with any issues you run into. But seriously, no games exist, no real demo projects with it exist. For some reason it uses Lua instead of strongly typed language like C#. Seriously, games NEED types. At scale projects get really messy without them. Oh wait, O3de pushes script canvas on you. At the end of the day , I find myself getting sucked back into Unity. Unity could be better, but it's still the best engine for most people. Much of that is just due to documentation. For some reason Amazon decided effectively hide all of it's old Lumberyard docs and examples when they rebranded as O3de. No one will ever know why.

malkia 4y ago

Your users at an AAA studio (artists, scripters, builders, audio designers, etc.) constantly require support: features, bug fixes, band-aids. An engine does not give you that, ultimately you need people.

EamonnMR 4y ago

I love Godot to pieces, have used it for several games and will continue to do so. Here's what's missing: * Sane animation import toolchain. The current one from blender is enormously finicky. * Good enough pathfinding (supposed to be fixed in GD4) * Better native map support (heighmap or some sort of interior) * Fix the 2d tileset editor, doing anything interesting in it is way too labor intensive because it lacks copy paste for tile parameters. A better system would let you set up a small number of tile templates and just map tiles to templates to quickly rig up huge tilesets.

sli 4y ago
The new tile editor works much in the way you describe and people overall seem to hate it. I quite like it. I'll grant them that it's a bit weird and needs some cleanup (there's a tab that's in two places for two subtly different purposes, for example), but I still prefer it to the old version. But the workflow of designing e.g. a tile hitbox and then applying it quickly to multiple tiles is exactly how it works now.
- EamonnMR 4y ago
  Awesome. I built a decent little top down tile shooter with free graphics but realized making more levels would be mostly an exercise in editing tiny tile squares so I decided to do other things.

jarsin 4y ago

Does godot have multiplayer options? I know Unity abandoned their old networking and is working on a new one, but at least there are open source options like mirror, and paid options like photon fusion.

suby 4y ago
They have multiplayer in the form of a wrapper around ENet.
andrewmcwatters 4y ago
The answer is no, you have to write your own networking. They provide enough to say, “Yes, we have multiplayer support,” but the real answer is “No,” because you still have to do it yourself. It’s a farce. It’s like including fmod bindings and saying yes we support fmod, but having zero integration. There’s no serialization, deserialization, no prediction, no reconciliation, no interpolation, nothing.

liamkf 4y ago

I think Godot is making good steady progress. I also think it's a sign of where Godot is in development that the scripting and artist interfaces are mentioned at the tail end. There's a vast graveyard of unused "programmer-led" features on big game engines, ignored by the artists or designers who make up 90% of the production team because of a lack of editor polish or discoverability. Between that and... no Perforce support (what... 95% of AA+ game studios use), I would bet that Godot's first usage for AA/AAA will come from a new team that grows an indie success and with a plucky engine team that can keep bolting on exactly what they need for their game to grow. I'll be interested to see what it is! :)

ydnaclementine 4y ago

I don't do game programming, but want to learn. I'm very keen on finding a nice project based book to learn 4.0 once it's released

sprkwd 4y ago
I’m exactly the same. Looking forward to it.

tete 4y ago

Super subjective. Not a Godot developer/user/..., just a gamer who played games that were developed with Godot. Not much I'd say, given that there's quite a few "successful" (eg. enough buyers for many positive reviews) games on Steam. Also based on those games typically being very small studios I'd assume that if a company that repeatedly throws out AAA games (that aren't just some small improvements of an existing codebase) would use Godot to do so it would be a AAA game.

everyone 4y ago

I wonder will Godot be the next Unity? Everyone I know who has seriously gotten into it complains about bugs in fundamental things (like floating point operations in one case) Thinking back, early Unity was rock solid. The core stuff was great, it's all the newer stuff in Unity that sucks. I guess if people keep patching Godot then it will be fine.

djmips 4y ago

A red flag for me is all the talk about optimizing which focuses on making things multi-threaded as if that was a silver bullet. Recently we took multi-threading out of a portion of a renderer and then fixed what actually was slow and it's now running single-threaded and much faster than the previous multi-threaded version. Learning to understand what your real bottlenecks comes from experience in how to profile. Saying your are going to fix things by going multi-threaded is great and all but first understand why your single threaded performance is poor. Not all systems are going to respond simply by going multi-threaded.

JakeAl 4y ago

Keep it away from AAA. AAA means bloatware. Keep it lean and clean and modular. Focus on ease of use, not making millions off the engine.

nosvince 4y ago

Can someone ask why does it needs to cater to AA and AAA studios? Unreal is already great for this, with Unity trying it's best to get there. We need an engine focused on the problems of smaller developers, especially on mobile. Defold is another open source engine that seems focused on this, which makes more sense to me.

SXX 4y ago

Okay I'm little late to the party, but our company actually released commercial game on Steam and GOG. It called Dwarven Skykeep and it built in Godot. Now I'll list a few things that for some reason are not mentioned in article, but crucial for Godot success in commercial game development. 1. Official console support and partnership with platform owners. Yes this code will be closed source, but without this there can't be many AA/AAA games. I'm aware that Godot Foundation is a step to solve this, but it's not yet here and unfortunately 3rd-party companies selling porting services are not sufficient. 2. Once console support is here there will be dire need for game publishers who have pipeline to fund and do marketing for games using Godot. Unfortunately it's very hard to find a publisher for game that built with Godot. 3. Godot need more stable and official support for pesky closed source ecosystems like Steamworks, GOG, etc. There are plugins for that, but they are not as easy to use as in proprietary competitors and not easy to find. 4. There need to be much better tooling for debugging and performance profiling. I've already had some lengthy discussion about it in previous Godot topics so I'm not gonna elaborate much. Its slowly being worked on and improved, but it still inferior than competition. I love open source and love working with Godot, but unfortunately it's difficult to make commercial games when ecosystem is not there. Game development is hard enough on it's own and sometimes you have to make a choice of whatever you want to support FOSS or you want to make a great games.

georgeecollins 4y ago
That game looks cool. Good job!
- aiqq 4y ago
  Yeah but it doesnt seem to be selling and looks like thousands of other games released daily.
  - SXX 4y ago
    Making games is hard and marketing them for the right audience is even harder. Anyone who want ot make make game development their primary job have to take a risk of their game not becoming bestseller. Though in reality 90% of games simply never getting to release at all. At the same time I think 2 years working with Godot full time is enough to talk about it's strong and weak sides including ecosystem problems that make commercial game development even harder.

m4nu3l 4y ago

I have been using Godot since it was open-sourced in 2014. I'm also familiar with the source code and I have made some contribution. I mostly created prototypes until two years ago when I started working my first commercial project, it's called Outer Space: War Gears and it's a six-degrees-of freedom space shooter. I chose Godot mostly because of the familiarity and hackability. However I spent a lot (too much) time working around/fixing obscure bugs in the engine. I figured I was definitely the first one to use some features (given they really didn't work), like using GDNative in a MT fashion. Another issue (for Godot 3.x, Godot 4 is much better in this regard) is that GDScript is really slow. I got to a point where it took longer to run all the script than to run the physics step (and my game is physics-based, all actors are rigid bodies!). Luckily GDScript is fully parallelizable as it doesn't have a GIL. So now I run a lot of code in thread pools and do a lot of sub-step optimizations. If you do use it with MT, though, you won't be able to debug GDScript and profile on any other thread than the main one - for better profiling I just use perf. However I'm reluctant to use Unity and UE because even just loading the project in the editor is much faster in Godot. I like it being so lightweight. I also like how you can easily write native modules for it. Recompiling the Engine is quite fast. I hope Godot 4, with more support from companies and the community will get much better.

krapp 4y ago
At the very least, language support should be better thanks to GDExtension. I'm not a fan of GDScript either and C# is too heavy for my tastes, so I'm waiting to see which alternate language implementation matures enough for someone to actually publish a game with it.