[HN Gopher] Godot for AA/AAA game development - What's missing?
___________________________________________________________________
Godot for AA/AAA game development - What's missing?
Author : milliams
Score : 209 points
Date : 2023-01-16 15:24 UTC (7 hours ago)
(HTM) web link (godotengine.org)
(TXT) w3m dump (godotengine.org)
| lazypenguin wrote:
| 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 wrote:
| What's the "something else" you're currently using?
| brookst wrote:
| Thanks for the excellent write up with big picture thoughts and
| concrete examples. I only regret that you didn't hit the
| "waiting for Godot" punchline harder.
| raffomania wrote:
| Interesting - you're describing my experience with Unity, and I
| ultimately switched to Godot because of my frustration with
| Unity.
| warent wrote:
| I've been using Unity for a few months now and what is most
| frustrating is how lazy and unprofessional the company
| presents itself.
|
| They basically found that the Asset Store is such a huge
| source of revenue for them that they now completely over-
| leverage it and abuse the community for profit. For the few
| things they do ship, they routinely break things for
| backwards incompatibility or literally just ship half
| complete "products". If you want to do anything meaningful in
| Unity you either have to build it yourself from the ground up
| or buy plugins.
|
| An example: their AI navigation system is so lacking in
| features, they haven't updated it in nearly two years, and
| the last ship they did was literally _half broken and buggy_
| for several use cases.[1]
|
| Also their help desk is currently broken, replacing random
| text with "$$anonymous$$" and deleting replies[2] :)
|
| 1: https://github.com/Unity-Technologies/NavMeshComponents
|
| 2: https://forum.unity.com/threads/certain-characters-and-
| group...
|
| EDIT:
|
| This comment is definitely a venting comment, but I didn't
| want it to come across like Unity is pure ass. It has a lot
| of really great things too. I've especially enjoyed their
| abstractions around vectors, quaternions, cameras, and
| local/world space. You can do a lot of really complicated
| operations that look and feel great, without having what
| would normally require some pretty advanced math knowledge
| that is beyond me
| arjonagelhout wrote:
| I have been using Unity for around 5 years now, and have
| come across many issues, from lacking documentation, weird
| APIs, breaking or forever-in-experimental packages, to
| issues with implementing best-practices for software
| development.
|
| However, its core is really robust and powers almost all VR
| experiences and startups, such as Gravity Sketch and Arkio.
| Which is why I still find myself drawn to Unity.
| rstupek wrote:
| That's one of the issues with open source, polishing isn't
| "fun", where massive rewrites to a new thing are.
| edflsafoiewq wrote:
| I don't know about fun, but structurally, polish is one of
| the hardest things to contribute to an open source project.
| Polishing usually has a very large "activation energy", where
| the overhead of synchronizing, making a PR, building
| consensus, etc. dwarfs the actual effort in the patch.
| Polishing may involve hundred or thousands of small changes
| like this. Outsiders are likely to prefer contributing large
| features where the effort involved is more commensurate to
| the benefits.
| dymk wrote:
| On top of that, polish usually involves some amount of
| opinionated design, which can be hard to contribute to an
| open source project - you'll break someone else's workflow,
| or maybe it doesn't mesh with the ideas of a core
| maintainer, etc.
| kwertyoowiyop wrote:
| Just like all other software!
| worldsayshi wrote:
| I don't understand why there hasn't been a widely successful
| crowd financing platform for open source yet.
|
| I imagine it has to be a bit complex but it sounds like a
| solvable problem.
| Mountain_Skies wrote:
| Wikipedia, Mozilla, Gnome... they've all been found to be
| poor stewards of donated money, using it for pet
| ideological projects instead of the projects that are the
| foundation of each organization. If I go to the discussion
| site for many FOSS projects, it's hard to go very long
| without seeing lots of political activism being pushed.
| FOSS decided to become political or those who are political
| decided to invade FOSS. Either way, they've made their bed
| and now it's shrinking their pool of potential resources.
| darkwater wrote:
| FOSS had _always_ beeen political. How the heck is giving
| you the freedom to modify and tinker the source code of
| the software you are using, no string sattached, not a
| political act? I think it 's fair to say that then "the
| ones who just want to have things for free as in beer"
| came. But FOSS has always been pretty utopian.
| drdeca wrote:
| The word "political" is used in a number of ways. When
| someone says "How could <x> __not__ be political? Of
| course it is political." in response to someone
| complaining about <x> becoming political, I think the
| person responding is typically using the word "political"
| in a way different from how it was being used in the
| original complaint.
|
| I think it would be best to attempt to understand what
| the person complaining meant by "political", (and if one
| dislikes using the word "political" by itself to express
| that idea, or if is unsure if one is interpreting
| correctly, perhaps rephrase the idea in one's own words,
| and maybe ask if that was what was meant) and respond to
| that.
|
| I saw a poll result the other day, which said that, in
| 2020, some voters and some corporate executives were
| asked whether they approved of companies expressing
| support for political/electoral/whatever causes/social
| issues, and given the options of "yes", "yes, but only if
| directly related to the company's core business", and
| "no". According to this poll result, less than 40% of
| voters picked "yes", and almost 80% said either "yes" or
| "yes, but only if directly related to the company's core
| business". (for completeness, but not really relevant to
| my point : over 60% of the corporate executives polled
| said "yes", and under 10% said "no")
|
| Perhaps an analogy can be drawn between these two
| situations?
| jakear wrote:
| IMO the issue is as soon as it's paid, there needs to be a
| "Software Engineering Manager" of some sort or another in
| the middle of the payers and the workers. That's a very
| difficult job to hard-code.
|
| Having spent some time maintaining large OSS projects as a
| first party engineer, these are the options I see:
|
| - pay a fixed donation per month, a la patreon/etc. I would
| never do this. If I'm buying software for a company I want
| a real support contract, not a "I'll really try to respond
| to your issues with higher priority!". If I'm using
| software in a personal project, I want the monthly burn to
| be as close to 0 as possible. Also, who takes that money?
| What do third party PR submitters get? What do people who
| submit excellent issue reports with crash dumps and full
| debug traces get? What do first party PR reviewers get?
| Third party? etc. etc.
|
| - stake money on the closing of a given issue/PR. This is
| better, but comes with a whole can of worms. The obvious
| failure mode is a third party contributor submitting a PR,
| the maintainer saying "eh.... I don't really agree with the
| way you've done this", then building it themselves. Next
| step on that train is a fight between the third party and
| the maintainer about how much influence one's code had on
| the other. Even if that doesn't happen, the maintainer is
| almost guaranteed to request changes of some sort, who
| decides how much the maintainer gets for their work
| reviewing versus the third party for their work
| contributing?
|
| Not to mention the dirty little secret behind many third
| party contributions: if you are new to the repo, the
| frameworks, oss in general, etc., it is highly likely that
| the maintainer's work in holding your hand through
| contributing to the repo will far outweigh the work they'd
| need to put in to make the change themselves. But few would
| agree to paying the maintainer to accept their PR, or
| likely even the maintainer getting more money than them for
| their own PR.
| rcme wrote:
| People generally don't like to pay for things they can get
| for free.
| hutzlibu wrote:
| liberapay.com is pretty much that.
|
| No fees - 100% non profit.
|
| Probably not "widely successful", though, otherwise you
| would have heard of it. And the overal money flowing
| through it, is quite modest. The main problem is still in
| the minds of people, I think. If something is free, then
| there is no need to pay, then most won't pay (or they pay
| 5EUR and think they own the developer now).
| Karsteski wrote:
| Patreon exists, but I hesitate to contribute to
| projects/people through Patreon as I want to give them as
| little money as possible...
| worldsayshi wrote:
| I also feel that something like Patreon doesn't reflect
| the semi-decentralised way open source is built.
|
| There needs to be features like feature/bug-bounties that
| you can trust even if you don't fully trust the repo-
| owner/maintainer?
| Karsteski wrote:
| I'd be more okay with donating via Patreon if they didn't
| do the thing where every internet platform that becomes
| successful feels the need to start going down the
| political route. I'm not sure if this is a more of an
| issue due to the employees, or due to social media
| pressure, or if it's just "keeping up with the times" but
| I hate it. And it's also so US-centric, which makes sense
| as they are usually US-based companies, but it just
| irritates me looking from the outside.
| bee_rider wrote:
| As someone who doesn't follow the details of day to day
| Very Online politics-adjacent drama, I haven't heard much
| about Patreon, so... they seem to be threading the needle
| well enough to stay off the radar of boring normies like
| myself. What's their issue?
| Jensson wrote:
| They started banning creators who made NSFW content a few
| years ago, might be that. They never allowed porn, but
| they started hammering down on all sorts of erotic
| material. I don't really care, but others do.
| bottled_poe wrote:
| This seems like a natural outcome of running such a
| platform. The platform is trying to optimise revenue.
| They can choose which user complaints to support/reject
| but they can't satisfy everyone.
| remram wrote:
| opencollective maybe? They have multiple "hosts" that
| handle receiving the money, tax paperwork, and approve
| spending. So a project probably doesn't need too much
| trust if you trust the host... if I understand this
| right.
| dv_dt wrote:
| There is always Liberapay
| https://en.wikipedia.org/wiki/Liberapay
| danbolt wrote:
| I love `move_and_slide` and it's perfect for me, but you're
| right that it's a very opinionated implementation. I found I
| was making huge strides in 3D very quickly, but a friend
| essentially had to re-implement it for their game.
|
| I'm curious if the best solution would be to expose more
| optional knobs and switches for KinematicBody, or to have a
| bigger ecosystem of open-source variants.
| therein wrote:
| Tangentially to your post, but nonetheless interesting:
|
| "jack of all trades master of none" is the shorthand version of
| the full phrase "A Jack of all trades is a master of none, but
| oftentimes better than a master of one" which has been used
| since 1721.
| demindiro wrote:
| > 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.
|
| Even as a contributor I've found it very frustrating to
| contribute to Godot.
|
| I've found lots and lots of bugs while working on my own
| projects using Godot. I spent a lot of time digging in the
| engine code to figure out the cause, make an issue and a patch
| if I could.
|
| However, even small changes take a lot of time and effort.
| While I used Godot 3 for my own projects most of the PRs had to
| be based against 4. At the time Godot 4 was in a very sorry
| state and I ran in many, many issues that made it hard to test
| if the same fix for Godot 3 also works in Godot 4.
|
| I wrote some libraries to work around issues that I (or others)
| could not get fixed or reverted (e.g. I replaced the physics
| engine with Rapier3D because I really needed more stable and
| _working_ joints) but I eventually threw in the towel and
| decided to focus on other hobbies.
| philipwhiuk wrote:
| > While I used Godot 3 for my own projects most of the PRs
| had to be based against 4.
|
| The lack of support for anything than the bleeding edge in
| open source is a huge issue :(
| throw_m239339 wrote:
| I mean it's a relatively young open source project. It took
| Blender 25 years to get where it is now and it still has some
| major flaws compared to the paid competition, and will need
| extensive rewrites if it wants to move forward because right
| now the C part is a horrible mess.
|
| Godot isn't going to compete against Unity or Unreal anytime
| soon. Godot's team doesn't have billions at their disposal like
| Epic or Unity.
|
| edit: Blender also had major advantage aside from begin free,
| it could do physics and volumetrics for free when the
| commercial competition required yet another paid plugin just
| for that stuff, so why pay when the free solution does more
| than the competition? and let's not even go into requiring
| separate paid rendering engines for the renders to look
| decent...
| fckgnad wrote:
| I think though that there's an apex all game engines reach
| where technological progression just slows down even when you
| have millions of developer dollars to throw at it.
|
| It's the reason why something like blender can catch up with
| state of the art commercial offerings and I think Godot could
| go through the same thing.
| fbdab103 wrote:
| Isn't that true of all software? At some point, things
| should be able to be fully feature complete. Maybe update
| the UI toolkit every five years to appear fashionable.
|
| In practice, the industry loves to replace fully working
| projects rather than tweak existing, so we will never get
| to such a state of nirvana.
| fckgnad wrote:
| Can't prove if it's true of all software. But examples of
| categories of this type seem to exist. Linux and blender
| are two examples.
|
| The software never gets to total nirvana. What happens is
| it gets to a state of nearly nirvana such that changes
| are tiny.
| snarfy wrote:
| > limited controls for navigating around the 3D viewport
|
| I still haven't figured this out yet. It's really weird it's so
| difficult to navigate the viewport, which is a really basic
| operation for a 3D engine. I've made plenty of levels using the
| unreal editor, but I can't figure it out in godot.
| tpxl wrote:
| What's missing? It's got rotating (MMB), panning (Shift +
| MMB), zoom (scrollwheel) and focus on object (F).
| snarfy wrote:
| Zoom is limited. It's not infinite zoom. How do I move
| through the level in Z direction? I saw a video mention
| WASD keys but it didn't work for me. In unreal you can fly
| through the level using mouse and keyboard. WASD is
| cardinal direction and mouse is camera rotation. In godot
| mouse wheel zooms the camera, but I couldn't find a way to
| 'move' the camera in Z.
| light_hue_1 wrote:
| Hold the right mouse button and press WASD Q/E. It works
| as you would expect. You can press shift+F to toggle this
| mode if you don't want to hold down the button.
| snarfy wrote:
| shift+F worked for me to toggle freelook. Thanks for the
| help!
| darkteflon wrote:
| Not familiar with Godot but that sounds like camera
| dolly.
|
| Afaiu the reason for two different camera control schemes
| in DCCs and game engines is that they're suited to
| different workflows. On the one hand, object-centric
| orbit-style controls are great for, eg, modeling, whereas
| free-fly WASD / mouselook controls are great for level
| blockout, in-scene camera positioning, etc.
|
| By default you have to hold the right mouse down to
| enable free-fly controls in Unreal.
|
| Sorry you might know all this. Just if you are expecting
| one camera control scheme and getting another I know it
| can be frustrating.
| the__alchemist wrote:
| As most people working on these are probably aware, this
| is very easy to implement in a 3d engine using a
| quaternion orientation that rotates the WASD vectors,
| updating position and view orientation accordingly. Can
| do it with FPS friendly things like WASD + Q and E for
| roll, and space and C for up/dn.
|
| And blockers on patching this into the editor?
|
| Context: I have a very basic engine written in Rust/WGPU.
| Mainly using for chemistry sims. This is its default nav
| system.
| light_hue_1 wrote:
| > Can do it with FPS friendly things like WASD + Q and E
| for roll, and space and C for up/dn. > > And blockers on
| patching this into the editor?
|
| This is exactly how the editor works. It's just not the
| default mode. They call it freelook mode. You can either
| hold the right mouse button or toggle it with shift+F.
| tpxl wrote:
| TBH, this is completely undiscoverable. I can understand
| the GP poster missing it. I went looking through the
| menus and clicked all the buttons in the viewport and
| didn't find this (and still can't, other than in the
| settings).
| darkteflon wrote:
| Also how Unreal works, by default. Holding right-click
| mouse button enables WASD movement and mouselook. Works
| great, once you get used to it.
| andybak wrote:
| And Unity
| FireInsight wrote:
| Godot nowadays is getting to "Master" levels of 2D IMO.
| uwuemu wrote:
| [dead]
| Rhedox wrote:
| 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 wrote:
| 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?
| vblanco wrote:
| I wrote extensively about that as part of my vulkan guide.
| 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.
| ninepoints wrote:
| 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.
| MikusR wrote:
| https://news.ycombinator.com/item?id=15338055
| bufferoverflow wrote:
| Godot does not have an equivalent for Nanite or Lumen.
|
| Real time GI makes such a radical difference in a way games look.
| Mikeb85 wrote:
| 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 wrote:
| > 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.
| BudaDude wrote:
| They are working on it. The streaming section in the article
| mentions it.
| 88stacks wrote:
| 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 wrote:
| 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.
| Daunk wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jokethrowaway wrote:
| 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.
| mkl95 wrote:
| > 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.
| seanw444 wrote:
| 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 wrote:
| I believe you misread the quote; they're not using PhysX.
| seanw444 wrote:
| 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 wrote:
| But they are only mentioning PhysX as a reference for a
| high quality phsyics engine.
|
| The only tried to integrate Bullet.
| shmerl wrote:
| 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 wrote:
| ianal but it could be a licensing thing. PhysX is BSD3 and
| Godot is MIT.
| light_hue_1 wrote:
| > 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.
| [deleted]
| Mikeb85 wrote:
| 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 wrote:
| Zelda: Breath of the Wild? HZD? Anything with vehicles? This
| is a pretty unhinged take
| ohgodplsno wrote:
| 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 wrote:
| 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.
| fbdab103 wrote:
| I think that list just emphasizes the parents point. The
| majority of games are getting by without dedicated physics
| sandboxes.
| mardifoufs wrote:
| Fortnite, GTA, RDR, apex, PUBG? I mean, scripted games are
| way less popular than they used to be. And I actually can't
| think of more than a couple major games without some sort of
| physics.
| teawrecks wrote:
| Care to elaborate?
| Supermancho wrote:
| 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 wrote:
| I will assume a high-end, state of the art physics engine is
| a must have for any AAA game.
| tpxl wrote:
| 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 wrote:
| Most games basically just have rigidbodies. Some cinematic-
| ish AAAs have fancy cloth simulation or something, but even
| that is usually prebaked I think.
| frompdx wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| qwery wrote:
| 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.
| bdickason wrote:
| 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.
| tete wrote:
| 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.
| mattgreenrocks wrote:
| 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.
| Jensson wrote:
| 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 wrote:
| Thank you for the tips, I will give them a shot.
| tpxl wrote:
| C# is pretty well supported in Godot.
| iFire wrote:
| 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.
| Avamander wrote:
| HDR and proper VRR/G-Sync/FreeSync support.
| tekni5 wrote:
| 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.
| EamonnMR wrote:
| 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 wrote:
| 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.
| everyone wrote:
| 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.
| avx56 wrote:
| 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 wrote:
| 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 wrote:
| Is there a set of libraries you'd recommend in this vein?
| logicprog wrote:
| 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.
| avx56 wrote:
| I find this hard because games often end up quite tightly-
| coupled, so while you don't have the pathfinding code
| reaching into the rendering, the rendering is usually coupled
| to the game object model and it's hard to make it reusable
| outside of a specific engine. That and the fact that AAA
| studios do _not_ want to open-source anything for some
| reason.
| logicprog wrote:
| That's true. That's why if I ever write another game I'm
| going to write it basically from scratch myself lol, true
| NIH-suffering indie gamedev style.
| LanceH wrote:
| I get where you're coming from, and there is always a certain
| hackiness to game code it seems.
|
| But I've embraced godot for 2D games and it has been wonderful.
| I get more code reuse out of the node system than I ever got
| out of class hierarchies elsewhere. I find myself with the time
| to set up a lot more test scenarios where I can play two things
| side by side to find the better feel -- rather than just
| getting one to work at all.
|
| Yes, that's all subjective and might just be me getting better
| at game development, but I was immediately productive in Godot,
| and I haven't run into a roadblock _for what I happen to be
| doing_. I imagine there may be a game type, or otherwise simple
| technique that is nearly impossible in godot, but simple
| elsewhere; that 's true of every game engine it seems.
| hugs_vs_toph wrote:
| imagine doing OOP in 2023
| donmcronald wrote:
| 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?
| lazypenguin wrote:
| Godot 3 is pretty well supported and maintained for now. It's a
| great engine for smaller or personal projects IMO. Really
| reduces the barrier to entry to make a game, especially 2D or
| basic 3D
| deng wrote:
| Well, it depends on the kids, of course. For 2D games, I think
| Gamemaker is more accessible and easier to learn, and you get
| results more quickly.
| gamblor956 wrote:
| It depends on what kind of games they want to make and what
| they hope to get out of it.
|
| A simple side scroller? Gamemaker.
|
| A more-advanced 2D game? Gamemaker or Unity.
|
| A 3D game? Unity.
|
| An FPS or other first-person game? Unreal.
|
| Programming skills that will be useful for a career in
| programming generally or in game development specifically?
| Unity or Unreal.
|
| With Godot, you'll be perpetually waiting for Godot to finish
| up and polish the 30% of features you actually want/need. I
| gave Godot 5 years before I gave up on it. Unity has announced,
| implemented, and abandoned features in less time than it takes
| Godot to finish that last 30%.
| rcarmo wrote:
| My youngest (12K) is writing a 2D platform game in it (3.x).
| He's had exposure to Pico-8 and various other environments (as
| well as basic Python) and has spent a while figuring out the
| mechanics of things like double jumps entirely on his own.
|
| (Oh, and he used Bolt visual scripting in Unity for a while,
| with decent results until we decided that Godot was much less
| hassle.)
|
| I'd say that he has come across zero bugs so far.
| cyber_kinetist wrote:
| GameMaker is pretty much the best game engine to get introduced
| to programming. It has a visual scripting tool that lets you
| write basic logic without any raw textual coding, but also
| provides a smooth transition path to learn an actual scripting
| language (GML) when the child becomes more ambitious. I've
| started programming at a young age thanks to this.
|
| (Godot had a visual scripting system but they removed it in
| 4.0. And it wasn't really intuitive to learn anyway, compared
| to how GameMaker does things.)
| Tijdreiziger wrote:
| Note that the original GameMaker isn't around anymore. They
| moved on from that to their new engine GameMaker Studio, and
| apparently recently renamed that back to GameMaker again.
|
| https://en.wikipedia.org/wiki/GameMaker#History
| ihatepython wrote:
| Gary Kitchen's GameMaker? I remember playing with that when I
| was a kid on the C64. That and SEUCK (Shoot Em Up
| Construction Kit)
| Tijdreiziger wrote:
| Considering the mention of GML, my assumption is Mark
| Overmars's GameMaker.
|
| https://en.wikipedia.org/wiki/GameMaker
| donmcronald wrote:
| That looks pretty good. Thanks for the suggestion.
| sli wrote:
| Just to add to your options, there's another, similar one
| called Construct.
|
| https://www.construct.net/
| scotty79 wrote:
| Recently I learned something named GDevelop exists. Not sure
| how good it is, but it might be one of the options to consider.
| Waterluvian wrote:
| 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 wrote:
| > By using a web engine, it can be easier for them to share
| their games
|
| Godot and Unity allow exporting into web projects.
| bcrosby95 wrote:
| At least in Unity, there's lots of sharp edges around
| webgl.
| Waterluvian wrote:
| On paper or to an engineer it might feel comparable but it
| just is not. WebGL introduces a lot of complexities.
| johnyzee wrote:
| 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.
| AshleysBrain wrote:
| Shameless self-plug: we make Construct, which has a visual
| block-based system, runs in the browser with no install, and
| also supports progressing on to JavaScript coding:
| https://editor.construct.net/
| teawrecks wrote:
| If they know any programming language (Python in particular)
| then yeah it's probably fine. Otherwise, they'll need some help
| getting oriented.
|
| I'd get them started on something like Construct 3, or maybe
| Pico-8.
| caniszczyk wrote:
| If you are looking for a AAA open source engine today with an
| open community, check out 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 wrote:
| Seems to be a "developer preview" with no released games.
| m0guz wrote:
| It is actually Amazon's Lumberyard, which was also CryEngine
| fork.
| 41209 wrote:
| 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.
| seanw444 wrote:
| 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 wrote:
| I believe it's being developed on the master branch at
| https://github.com/godotengine/godot
| remram wrote:
| 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-...
| malkia wrote:
| 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.
| Thaxll wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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...
| jarsin wrote:
| 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.
| sylware wrote:
| 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 wrote:
| Have not tested this but can you not build with llvm's libc++.
| sylware wrote:
| I don't think llvm libc++ has a libdl mode, because that
| would mean that all games coded with c++ should switch to
| clang.
| ydnaclementine wrote:
| 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 wrote:
| I'm exactly the same. Looking forward to it.
| liamkf wrote:
| 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! :)
| fckgnad wrote:
| 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)
___________________________________________________________________
(page generated 2023-01-16 23:00 UTC)