[HN Gopher] Godot 4 Beta 1
___________________________________________________________________
Godot 4 Beta 1
Author : f47il
Score : 215 points
Date : 2022-09-15 18:04 UTC (4 hours ago)
(HTM) web link (godotengine.org)
(TXT) w3m dump (godotengine.org)
| [deleted]
| pwdisswordfish0 wrote:
| It would be nice if we brought the rule back where it's against
| HN guidelines to post submissions for every new version of some
| software. Every Godot thread ends up with the same comments
| posted, none of them particularly interesting or insightful. And
| in this particular case, it's not even an official release; it's
| just a beta!
| andrewmcwatters wrote:
| I disagree. I want to see more actual software on Hacker News.
| This is a space for "hackers," is it not?
|
| While Godot fairly established, there are up-and-comers in
| software development, and one of the few ways I will ever know
| about these people and their projects are by Show HNs and
| product update submissions.
|
| It may be dozens of releases or years before I even hear about
| a project, and this type of comment clearly comes from a place
| of not knowing at all what it is like to work so hard on
| something nor knowing at all how to promote a product.
|
| People have an aversion to promoting and advertising, but I
| want to see "WAYWO?"!
|
| I'd far more* rather see that than political nonsense, bullshit
| tech opinion articles, and news completely unrelated to the
| hacker or business space.
|
| Edit: Further, with respect to Godot, the authors continually
| make more progress on the codebase and there is a lot to talk
| about. Not just specifically with Godot and their
| prioritization of software features, but how the developers and
| contributors are having an impact on the hobbyist and
| independent developer scene.
|
| I have gripes with the space as it currently is, and I know I'm
| not the only one. I want to read those opinions here. If you
| don't like it, don't upvote it.
|
| For example, why have they in the past prioritized their own
| programming language? Decades old game engine codebases have
| rich features like material sounds, and fully integrated
| multiplayer features, but almost no open source game engines
| feature these things. Instead, they all focus on shallow flashy
| features like PBR workflows. I want to talk about those things.
|
| Another comment here mentions a custom physics engine that is
| being introduced. That's interesting! And further discussion is
| warranted over whether or not that is something that developers
| care about! What about other features like native split screen
| support? There's so much in this space to discuss.
| [deleted]
| derac wrote:
| Godot has a large number of integrated multiplayer features
| from low level primitives to higher level interfaces. It also
| has support for p2p with webrtc.
|
| https://docs.godotengine.org/en/stable/tutorials/networking/.
| ..
| runevault wrote:
| This isn't merely some milestone. This is a 2-3 year major
| rewrite of the engine with a rewritten render pipeline/engine,
| a heavily updated scripting engine+language, and a lot more.
| People (I admit, myself among them) have been chomping at the
| bit to see Beta 1 where the API/etc stability is guaranteed
| barring major bugs forcing them to revert things.
| TulliusCicero wrote:
| This comment makes no sense. If it was some random alpha
| release of Godot (there have been more than a dozen) then sure,
| but this is the first beta release, which means it's now
| somewhat stable. That's a big deal, considering how much
| rewriting as been going on.
| spookie wrote:
| What's wrong with posting milestones of a great open source
| project?
| terafo wrote:
| Godot 4 entering beta is quite an important thing since that is
| update that has been in works for a couple of years now and
| adds lots of new capabilities to Godot.
| jay_kyburz wrote:
| I hope to be the one to post LOVE 12 when its out. LOVE is a
| far superior game engine in every way! https://love2d.org/
| m0llusk wrote:
| I actually agree with the idea of restraint, but this is a
| colossal release with literally dozens of major highly
| anticipated features and a huge load of bug fixes and
| performance optimizations. Given the development time frame and
| resources this is a spectacular delivery. Also highly recommend
| checking out the code base directly as the team have done a
| great job of keeping the sources well organized and clear.
| KMnO4 wrote:
| Ultimately it's the HN community that collectively votes on
| what makes it to the front page.
| hitpointdrew wrote:
| 100% this, lets leave rules and mods out of it as much as
| possible. Let the community decide.
| [deleted]
| jokoon wrote:
| I tried the gdnative thing and implemented a few classes, but
| there doesn't seem to be a lot of difference with gdextension.
| japhib wrote:
| I think the main difference is that GDNative only had access to
| Godot's scripting API, so it could only manipulate the same
| stuff that GDScript or C# already could. So in 3.x, if you
| wanted to manipulate engine internals, you had to "engine
| extensions" which had to be compiled with the engine itself.
| But with GDExtension I think you're supposed to be able to do
| _everything_ that "engine extensions" could do, but without
| having to re-compile Godot itself.
| lbotos wrote:
| Early pandemic I was playing around with making a network shooter
| in godot but I got hung up on a good way to make a shared lib for
| the client/server "projects". Anyone solve that or have tips? It
| seemed like I either needed to make a mono repo and toggle the
| build for client=true but I really wanted to make 3 repos,
| client, server, and game-core-lib. Would love tips/guides if you
| have them!
| andrewmcwatters wrote:
| In my experience, you're better off having a single codebase
| with client/server/shared code and using either the equivalent
| of ifdefs or conditional blocks gating execution for these
| states.
|
| Unreal uses a different architecture where the codebase allows
| you to define who owns what, but it's ultimately the exact same
| thing, and more confusingly done. Further, they have some actor
| states which are never actually used.
|
| Unsurprisingly, Unreal's networking model is unpopular. They
| also struggle with an architecture that has been unreliable by
| design since the late 90s, but now I'm digressing.
|
| One codebase, split execution. If you use this traditional
| model, you can also avoid shipping server binaries to users if
| you so desire.
|
| For reference, I am the author of Planimeter Game Engine 2D.
| intelVISA wrote:
| Yeah you can easily compartmentalize client/server with
| ifdefs but it's pretty hideous. Do serious shops on MP titles
| stick with UnrealNet? I find it performs poorly even with
| some of the bandaids like Replication Graph.
| andrewmcwatters wrote:
| Unreal's default multiplayer architecture is unreliable by
| design and Tim Sweeney's whitepaper on its design from
| 1999, IIRC, talks about it in plain language. It's
| dramatically different than the Quake family of engines
| which reliably replicates entity states. The fact that he
| does not think of clients as being capable of having
| accurate replicable state is jaw dropping and appalling to
| read. It's, well, like reading a dissertation of provably
| wrong statements.
|
| Serious shops hack around the fact that Unreal uses a
| variable timestep. Because it uses a variable timestep and
| uses an RPC design that does not align state changes with
| frametimes, you, by definition, cannot make say, a reliable
| first-person shooter. Every game that uses Unreal must use
| cone projection and proximity hacks on top of the RPC
| system to attempt to make a reliable first person shooter,
| because you cannot guarantee the state of actor positions
| and inputs coming from the same frame of execution.
|
| Beautiful game engine though. Absolutely unreliable,
| though.
|
| If you ever wondered why FPS games on modern versions of
| the Unreal Engine had multiplayer that felt so bad, it's
| because the engine isn't designed from the ground up to be
| accurately replicated to clients.
|
| The design issue is systemic, so it may never be fixed, and
| Unreal engineers have decided it's too difficult or
| laborious to tackle.
| lbotos wrote:
| Thanks! I think it makes sense, as a non-game programmer it
| felt "weird" so appreciate the confirmation from your angle.
| keyle wrote:
| I'm very excited for Godot 4 beta.
|
| I shipped games on Godot 3 and the idea of having Vulkan and
| better culling is really attractive.
|
| When I tried the alpha fairly early on the editor was completely
| unusable on macOS.
| cmdrk wrote:
| Fantastic news. I'm really looking forward to Godot 4.0 exposing
| more of the ENet wrapper into GDScript etc. I've been writing a
| game server in Erlang and very much looking forward to offering
| ENet as an option in addition to WebSockets!
| japhib wrote:
| Whoa, that's interesting -- does ENet have a good integration
| with Erlang, or something like that? I'm interested in both
| Elixir/Erlang and Godot, but haven't seen an opportunity to use
| them together previously. I'd love to hear more details about
| this project of yours, and how the Godot 4.0 release impacts
| it.
| ummonk wrote:
| Impressive stuff. Starting to have the table stakes features that
| would need for a modern game.
| runevault wrote:
| I played with Godot back in the early 3.x timeframe (3.1? 3.2?)
| and then fell away and spent some time with Unity. But between
| some of Unity's missteps and Godot getting dotnet 6 support it is
| time to give it another go, plus a bunch of nice changes to
| gdscript that might make it something I'm okay with using
| (functions are first class citizens now unlike before where you
| just passed the name of the function as a string which always
| felt incredibly gross).
|
| Though based on the discord conversation there are still a lot of
| bumps even in the beta so I would not expect smooth sailing yet,
| but lets see if it is any good.
|
| For anyone interested, the main documentation on their site is
| still pointing at 3.x. If you want the docs for 4.0 start here
|
| https://docs.godotengine.org/en/latest/index.html
| prox wrote:
| Yeah callables are a great addition to 4!
| malikNF wrote:
| from the article,
|
| >>As much as we love exciting new features, we also want to see
| people create games on the full spectrum of devices for everyone
| to enjoy.
|
| This is one of the main attitudes of the Godot team I really
| appreciate a lot. It might be easy for people in more developed
| nations to upgrade their hardware every few years, but there's
| people still playing games running on computers from 2002 and
| before. I used to know of a player who used to play (an old
| MMORPG) games on a computer he aimed a table fan at to keep it
| cool. The whole casing was open, it was kinna funny to look at it
| and it had hardware he got as a birthday gift more than 10 years
| ago. He played that old MMORPG because newer games wouldn't even
| start on that old thing. But most people who played that MMO were
| in the same boat, it was one of the very few ones they could run.
|
| The requirements for some of the games coming out these days is
| sometimes so insane a lot of people from around the world are
| unable to play them. I always found it funny how we had so much
| developer time wasted on supporting ie6 because a small
| percentage of people were unable to upgrade their browsers, but
| when it comes to gaming, all bets were off and you are now
| expected to spend a few grand a year on upgrading your computer
| to play newer games. And don't get me started on the bandwidth
| costs to play some of the new games.
| tmpz22 wrote:
| Even seemingly simple games are clocking in at 100GB+ in disk
| space. I think in terms of performance many games are setting
| the floor at the Nintendo Switch or the Steam Deck, often
| ripping out features to get it to run on those platforms (CIV6,
| 2k etc).
|
| This is one reason I really admired Valheim (~1GB). Though even
| that game had CPU issues (also its an indie title so...).
| throw10920 wrote:
| Optimization levels of many newer games are terrible.
|
| Low-poly, visually simplistic games like Fortnite, Risk of Rain
| 2, Valheim, and Deep Rock Galactic barely run on a friend's
| computer (that was made only 5 years ago). Visually more
| complex games like League of Legends run buttery smooth on the
| exact same hardware.
|
| (ironically, he says that Valorant, made by a non-Epic company,
| apparently runs _significantly_ better than Fortnite, made by
| Epic - even though both are using the Epic-made Unreal Engine)
| Thaxll wrote:
| [deleted]
| KaoruAoiShiho wrote:
| I think Fortnite is UE5 while Valo is UE4.
| intelVISA wrote:
| Valorant has a solid engineering team and invest heavily in
| optimization, can't speak for the others. I could be
| misremembering but there was an interesting bug that was
| featured in an Unreal profiling case study where a Fortnite
| font was eating ~2ms (or similarly obscene) CPU budget.
| TulliusCicero wrote:
| DRG should run fine on a gaming PC from five years ago I
| think (a mid-range GPU from then would be like a GTX 1060).
|
| Actually, I think basically all of these games should run
| fine on that sort of hardware, as long as the quality isn't
| turned up high. Did they just build a really cheap machine or
| something?
| throw10920 wrote:
| Core i3-5015U with Intel integrated 5500.
|
| Yes, that's a low-end processor. No, it doesn't matter,
| because the fact is that there are several other games that
| look better and run _much_ better on the same hardware.
| TulliusCicero wrote:
| C'mon man, of course an iGPU is gonna do poorly with PC
| games.
|
| It absolutely does matter that integrated GPU's have
| usually been terrible at running games, and that one is
| no exception.
| throw10920 wrote:
| > It absolutely does matter
|
| You literally did not read my comment.
|
| I just explained why it doesn't matter - because there
| are _other_ games that run faster _and_ look better on
| the exact same hardware - and you completely ignored it
| without providing a single counterargument.
|
| That is _existence proof_ that that hardware, weak as it
| is, is _more_ than capable of providing that performance
| for that graphics quality.
| sph wrote:
| > Fortnite, Risk of Rain 2, Valheim, and Deep Rock Galactic
|
| Those games are low poly but NOT visually simplistic. Memory
| tends to play tricks and we remember older games looking
| better than they actually did, so we imagine lower polygons =
| 2005 tech game. Those games you've mention run on advanced
| and heavyweight fragment and vertex shaders to create a
| specific look (cartoony graphics in Fortnite, there's a
| million effects on screen a dozen levels in a Risk of Rain
| game, etc.)
|
| They might have the same poly count of Old School Runescape
| (but not really, as the models are actually quite complex)
| yet everything else is 20 years ahead of that game tech and
| complexity wise.
|
| Also not sure what your friend's PC is like, because a 5 year
| old PC can play all of those games with ease, though perhaps
| not at max settings. A 1080 ti from 2017 can run RoR2 at ~190
| fps at 1440p. https://youtu.be/TdfE3n8YLYo
| TulliusCicero wrote:
| They responded to my comment: it's an integrated GPU, and
| not one of the decent ones.
|
| The CPU is an ultrabook-class i3 too, of course games play
| terribly. This is a surprise to exactly zero people.
| throw10920 wrote:
| This logic doesn't hold up.
|
| > Memory tends to play tricks and we remember older games
| looking better than they actually did
|
| We compared what League of Legends, Valorant, and
| Inscryption look like _now_ with what those other games
| look like _now_. There 's no rose-tinted glasses involved -
| this is an apples-to-apples comparison.
|
| > Those games you've mention run on advanced and
| heavyweight fragment and vertex shaders to create a
| specific look
|
| If that same look is being created in a far more performant
| manner by other games, then that means that the game is
| poorly optimized.
|
| > cartoony graphics in Fortnite
|
| Same effect class as Valorant and League, with lower visual
| fidelity, _and_ worse performance.
|
| > there's a million effects on screen a dozen levels in a
| Risk of Rain game
|
| Risk of Rain is incredibly laggy in the _menu_ , with
| _zero_ mobs on screen and a single small scene as the
| background.
|
| > yet everything else is 20 years ahead of that game tech
| and complexity wise
|
| Again, see Valorant, LoL, and Inscryption.
|
| > Also not sure what your friend's PC is like, because a 5
| year old PC can play all of those games with ease, though
| perhaps not at max settings.
|
| Core i3-5015U with Intel integrated 5500[1] - so, 7 years
| old. Yet, it can still run League and Valorant at >60 fps
| with default settings, and 20-30fps Inscryption and Dota 2
| with reduced settings - meanwhile, Fortnite, DRG, RoR2, and
| Valheim are _all_ slideshows with _all settings turned all
| the way down_.
|
| The claim that "these new games are just so much more
| involved than older games" simply doesn't hold up against
| the reality that there are _recently-released games that
| look better and perform better simultaneously_ than these
| examples.
|
| My lived experience, my understanding of computer graphics,
| and knowledge of things like the GTA Online incident[2]
| _strongly_ indicates that this line of reasoning is
| incorrect.
|
| [1] https://ark.intel.com/content/www/us/en/ark/products/84
| 698/i...
|
| [2] https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-
| times...
| dgunay wrote:
| Not gonna excuse Fortnite since I've personally had terrible
| experiences with it on top-end hardware, but from what little
| of it I was able to play it has much larger environments &
| draw distances to contend with. The tight lines of sight
| Valorant & other tactical shooters have can be an advantage
| when it comes to rendering optimizations.
| Reubend wrote:
| I think writing their own physics engine might be wrong way to go
| here. I understand that Bullet leaves a lot to be desired, but my
| instinct is that the complexity from their own engine will leave
| a lot of edge case bugs that need to be ironed out over time, and
| that games using their own physics engine will suffer from a lot
| more quirks in the meantime.
| dljsjr wrote:
| A few years ago, as someone who has worked on physics engines
| for robotics simulations, I would have agreed with you. But now
| a lot of people are doing greenfield physics engines for games
| and having it work out pretty well. There's a ton of
| established academic and conference literature in the area now
| and it's not nearly as scary as it used to be.
|
| For example, Horizon: Forbidden West uses a custom physics
| engine that started out as one of the core dev's fun side
| projects: https://github.com/jrouwe/JoltPhysics
|
| Physics engines (at least game quality physics engines) are
| starting to drift in to "solved problem" territory and there's
| enough literature now that you can get something reasonable
| going yourself after doing some weekend reading.
|
| Edit to add: Godot has had its own engine available for a long
| time, so it's not a totally new effort. It's a heavy refactor
| and a large improvement but the bones for this were laid years
| ago so some of that technical debt you're describing has
| already been paid down.
| Dracophoenix wrote:
| How complicated were the physics engines you worked on? How
| exactly did they differ from turnkey solutions like Bullet,
| Havok, etc.?
| dljsjr wrote:
| Lots of simulators for robotics use ODE or Bullet,
| actually, and they're quite good for lots of things that
| you might want to simulate. But there are some people who
| would argue that they aren't the best for it, especially
| for simulating legged locomotion, because of the way
| physical constraints such as joint limits are enforced (via
| Lagrange multipliers). A popular alternative formulation is
| Featherstone's Method[1], which is becoming more widely
| available and goes by other names sometimes; for example,
| Rust's `rapier` physics engine refers to this type of
| dynamics model as "reduced coordinates" (they don't yet
| support it, but it's on their roadmap). Featherstone's
| method is becoming more popular but it's still not widely
| used in a lot of physics engines because most physics
| engines are targeting games and Featherstone's doesn't
| always have the best performance characteristics, instead
| favoring physical fidelity. Bullet can run using
| Featherstone's Method, by the way. One of the few FOSS
| engines I know of that supports it out of the box.
|
| Additionally, there are people in robotics who like to say
| that simulators are like lightsabers, you haven't become a
| true Jedi until you've built your own, so there's a _lot_
| of home grown physics simulators in robotics.
|
| [1]:
| https://en.wikipedia.org/wiki/Featherstone%27s_algorithm
| Buttons840 wrote:
| I've briefly looked into physics engines and they seem to
| require a lot of trade-offs. If a rock meets a hard place,
| what should happen? Gamers have seen the hilarity that can
| ensue. Designing your own engine allows you to make those
| trade-offs with the end goal in mind. You can do things like
| set global force or speed limits, because you know your
| game's design and the appropriate limits.
| worble wrote:
| I reckon they're thinking long term here though, if they don't
| change it now then likely the only time they could change it is
| when a theoretical Godot 5.0 comes out in who knows how many
| years.
|
| It sounds like it's got bugs that need fixing either way, so at
| least for their own engine they're not reliant on anyone else
| to get those fixes out (or have to use hacky workarounds as
| would most likely be the actual fix).
| runevault wrote:
| From everything I heard the existing physics engine was
| already buggy/hard to work with, which is harder to fix
| because either they had to fork it and then maintain compat
| themselves or ensure all their changes got accepted upstream.
| At some point it can easily make sense to just go your own
| way, and I can't fault them for deciding to do so.
| Quot wrote:
| One of the benefits of 4.0 is also the modularity of it with
| GDExtension. The major parts of the engine (including the
| physics) can be swapped with replacements without the need to
| recompile the entire engine. I'd usually say that is a long
| shot for community run projects, but even Bevy engine has
| community made extensions for separate physics engines.
|
| https://bevyengine.org/assets/#physics
|
| Forgetting about extensions, though, I see your point and
| almost agree, but Godot has shown that they will put in the
| work to improve their project, even if that means removing
| features like they did with visual scripting. Their physics
| engine will definitely be rough at first, but based on their
| past work, I believe they are willing and able to maintain it.
| sylware wrote:
| For the elf/linux target, I hope the build containers have a
| really, really old glibc (dunno which version it is) and the
| "-static-libgcc" and "-static-libstdc++" are defaults.
| adamrezich wrote:
| haven't used Godot in a couple years but it's good to see the
| progress on their tile system for 2D games! it was terrible last
| I checked, yet pretty crucial for making many kinds of simple 2D
| games
| cridenour wrote:
| This is great.
|
| I've been building my game on the Godot 4 alphas and the
| improvements in networking and rendering have more than made up
| for any instability or keeping up with changes. That said, more
| stability will be welcome and a focus on bug fixing instead of
| feature proposals will be key to a strong 4.0 release.
| dopu wrote:
| HN hug of death? godotengine.org is offline for me at the moment.
| Regardless, really looking forward to trying it out! Here it is
| on the wayback machine:
|
| https://web.archive.org/web/20220915181526/https://godotengi...
| runevault wrote:
| I think this goes beyond just HN. Their discord was also
| buzzing since last night when the tag got updated on the main
| branch.
| japhib wrote:
| In the discord they said it's pretty typical for the website to
| go down a bit when they @everyone like they did for this post
| cridenour wrote:
| Their web hosting has been pretty awful the last month or two.
| Multiple days of downtime for critical pieces. I know they get
| it free from tuxfamily but this certainly feels like they're
| getting what they pay for.
| moffkalast wrote:
| What, the whole five of us? Impossible.
| [deleted]
| abledon wrote:
| Logo change in Godot 5 ?
| intelVISA wrote:
| Been meaning to pick up Godot one of these days, how does it fare
| on the wasm/webGPU front?
___________________________________________________________________
(page generated 2022-09-15 23:00 UTC)