[HN Gopher] Godot 4.0 development enters feature freeze ahead of...
___________________________________________________________________
Godot 4.0 development enters feature freeze ahead of the first beta
Author : tianreyma
Score : 102 points
Date : 2022-07-28 15:13 UTC (1 hours ago)
(HTM) web link (godotengine.org)
(TXT) w3m dump (godotengine.org)
| strictfp wrote:
| How do you people feel about the Godot object and lifetime model?
| I found it hard to test my code because of how objects are tied
| to the tree, that emulating the tree isn't easy during testing,
| and that initialization during live use is different than if you
| instantiate manually, making it hard to rely on a constructor,
| since you might not be able to use it live.
|
| I can't remember the exact details around this, since I only used
| Godot for a couple of jams and the last time was a year ago. But
| I was wondering if others have had the same reaction, perhaps
| this could be fixed? I love the engine in general, but this thing
| irked me.
| omoikane wrote:
| Probably not the most efficient way to do it, but I setup test
| scenes for just the functionalities I wanted to test and run
| those manually.
| blamestross wrote:
| /sarcasm/ Why would game devs write tests?
|
| On a more serious note, I do expect test-ability isn't a high
| customer priority for Godot. Godot is self-hosted, maybe check
| how they run their tests?
| b33j0r wrote:
| It's something that's pretty nice once you've implemented these
| lifecycles a bunch.
|
| The tree turns out to be a great place to keep things, and you
| get several levels of control. Here's how I think about it now.
|
| `_init`: constructor. I usually use this to create dynamic
| child nodes
|
| `_enter_tree`: now we have a parent; subscribe to signals, copy
| initial config, etc
|
| `_ready`: I can be sure that all child nodes have called
| _ready, so anything I depend on there is... er, ready
|
| `_exit_tree`: cleanup, especially anything we did with the
| parent and other ancestors. usually symmetric to `_enter_tree`
| if I'm using them
|
| I just did a find all in my biggest recent project, and I never
| actually use `queue_free` or `free` for explicit memory
| management. Most of the times when I've thought I needed to, I
| actually was creating a bug
| strictfp wrote:
| Thanks. Do you setup an artificial tree during testing? If
| so, how?
| b33j0r wrote:
| I'm not sure your mental model matches mine, but in my
| "real job" I deal with the shadow and virtual DOM. Maybe
| that's the metaphor you're looking for?
|
| I'll have to be a little practical and hope it makes sense.
| The tree in the editor is the same tree. Godot engine is
| written in Godot engine, so what is the distinction between
| being in the editor and being in the game?
|
| The answer is that godot will ignore all project scripts by
| default while you are in the editor, but it offers
| mechanisms to enable them. The main way is a keyword in
| GDScript.
|
| In Godot 3, you put `tool` as the first line of a script,
| and it will be loaded. Godot 4 has grown a pre-processy
| decorator syntax, so it's the same, but `@tool`.
|
| In your scripts, you can detect whether you are in the
| editor by checking `Engine.editor_hint`. You can do amazing
| things with this.
|
| Then you can take it a step further, and convert your tool
| scripts into an addon. With an addon, which is just a
| directory structure for assets, your custom in-editor
| functionality becomes indistinguishable from native godot
| behavior.
|
| https://docs.godotengine.org/en/stable/tutorials/plugins/ru
| n...
|
| PS: I created a virtual node tree a few times to wrap UI
| components. Much like react. But honestly, I usually find a
| more idiomatic pattern later.
| tpxl wrote:
| How do you remove objects if you don't queue free them? Just
| remove them from the tree?
| b33j0r wrote:
| Yes, or they are free'd automatically as the parent is
| free'd recursively. If you have called `add_child` on a
| node you created dynamically, godot will handle its
| lifecycle from there.
|
| If you don't add a dynamically-created node to the tree,
| you are responsible for `free`.
|
| That almost never comes up, because I eventually figure out
| how to decompose everything into a tree Node, or! A
| Resource.
|
| Resources are managed in a separate memory pool, and don't
| need to be added to the tree for godot to take care of it.
| Go ahead, you just try and `free` a resource! ;)
| tpxl wrote:
| Damn, I didn't know that. Time to remove queue_free from
| my project :)
| TillE wrote:
| It's not clear to me whether .NET 6 (and therefore C# support) is
| going to make 4.0 freeze. It's really just been one guy working
| on the dotnet6 branch, which is unfortunate.
|
| I'm really excited for many features of Godot 4, and GDScript is
| perfectly adequate for UI glue code and stuff, but to write a
| serious game you really want C#.
| drmidnight wrote:
| GDScript 2.0 has had some major performance improvements. While
| C# will still be faster, I find GDScript in Godot 4 to be
| viable now for things it wasn't in Godot 3.
|
| I still rely on GDNative for really performance critical
| systems though.
| benjaminjackman wrote:
| Sounds like Godot 4 is replacing GDNative with GDExtension.
| Just wondering if you have tried it out and have any
| thoughts. Is it a smoother experience / about the same etc.
| opyate wrote:
| > but to write a serious game you really want C#.
|
| I asked someone on Twitter about this the other day [0], and
| I'm genuinely curious: what is it about C# that makes game
| development serious?
|
| 0. https://twitter.com/LegatXyotic/status/1552219744723402756
| Cloudef wrote:
| Probably not serious, just that it's the language used in
| unity
| Waterluvian wrote:
| I won't use the word "serious" but my limited personal
| experience is that C# feels like the right balance between
| flexibility and performance.
|
| Rust is a joy to write in but I personally find that it asks
| a lot from you when you just want to ship a game that doesn't
| need to be safety rated.
|
| C++ is a great choice but it's C++ and I'm just not good
| enough to enjoy a language with fewer guardrails. It also has
| similar verbosity issues to Rust and (likely because I'm a
| noob) eats up a lot of my time chasing dumb bugs rather than
| making a game.
|
| I do most of my game dev in TypeScript because it's a
| wonderful language and web is a great platform to easily ship
| toy games (my specialty). But it just isn't fast enough for
| anything major.
| stu2b50 wrote:
| I find it hard to imagine whatever glue language you choose
| for an engine like Godot would really matter that much. All
| you're implementing is the business logic. Even the slowest
| language can run through basic business logic in the blink
| of an eye relative to the heavy duty that the Godot systems
| are doing.
|
| Eve Online runs on *python*, for instance. So does Blender.
| For a glue language, I am highly doubtful that the .net is
| that much faster than v8 or any other runtime to make a
| difference.
| tmp_anon_22 wrote:
| > isn't fast enough for anything major.
|
| I think it could be fast enough if portability to different
| platforms wasn't such a high priority for game studios
| these days. Nobody wants to write typescript and then pay
| $50M for someone to port it for Switch or whatever.
| tokumei wrote:
| I've built a few custom engines over the past decode, also
| shipped a few games. I've lately been working with Bevy in
| Rust, and I really absolutely love it. It's the perfect
| framework (for me). Bevy gets out of the way enough where I
| don't feel like I have to fight with it, which is what
| always annoyed me with actual game engines. Plus, I love
| working with Rust.
| steeleduncan wrote:
| gdscript is dynamically typed. If you have the large arrays
| of structs common in gamedev, then all data members are
| boxed, significantly increasing memory usage compared to
| something like C#.
| jayd16 wrote:
| Well you could always go with C++ but C# has a solid balance
| of high level features, good libraries, good tooling, a
| feature full (if not slick) threading mode, performance
| features when you need them and good interoperability with
| native code.
|
| Its not always fun or sexy to rewrite a reference type to a
| value type to get around your GC but you _can_ do that in C#.
| Its a have your cake and eat it sort of language.
| fezfight wrote:
| Does Godot's implenetation of C#/.net include the .net
| temeletry?
|
| https://github.com/dotnet/sdk/issues/14556
| Kwpolska wrote:
| The telemetry isn't in C#/.NET proper, it's in the `dotnet`
| CLI utility.
| nemothekid wrote:
| > _but to write a serious game you really want C#_
|
| I haven't followed game development in a long time, but has the
| industry moved to C#? I thought C# was limited to Unity and
| everyone else was still using C++?
| katamaritaco wrote:
| You're correct, the industry has not moved to C#. Not even
| close.
|
| The biggest player that uses it is Unity, but even they have
| their own special fork of Mono to get it to play nice.
|
| Full Disclosure: I work for a Microsoft/Xbox Studio.
| _aavaa_ wrote:
| The Wiki page says it already supports C#. As completely on the
| outside, what is missing?
| sfteus wrote:
| Godot ~3.2+ has support for a slightly older version of C#
| via Mono, I think it's the equivalent of .NET 4.8.
|
| IIRC (and this could be wrong / have changed since I last
| looked into it) the idea was to re-work this in Godot 4 to
| provide more like bindings, so that users could opt to use
| Mono, .NET 6, CoreCLR, NativeAOT, or whatever version they
| preferred.
| [deleted]
| nodja wrote:
| It doesn't support .NET6 specifically which is what parent is
| asking. According to the github issue it seems that the plan
| is that .NET6 support will be merged after godot 4 is fully
| released and stabilized.
| somehnacct3757 wrote:
| Former professional game dev getting into Godot recently for
| fun and maybe for hire.
|
| What are the limitations of gdscript you allude to? Let's say I
| want to render an infinite scrolling hex grid. Why would c#
| excel or gdscript struggle?
| marcodiego wrote:
| Comes in a good moment considering recent Unity backlash.
| mkw5053 wrote:
| Is there something inherent with game engines that prohibits
| small, frequent software delivery? (call it agile or lean, if you
| want)
| colechristensen wrote:
| Their users. Game engines are big and complex and the
| foundation of building a big and complex product. You can't
| have your foundation introducing fundamental changes on a
| regular, unpredictable basis.
|
| Releasing big versions means your game can use version X.Y with
| only bugfixes to the engine added as updates and you don't have
| to make fundamental changes when the game engine changes.
| jibe wrote:
| A lot of games are fragile, and have poor or no test coverage.
| So if the engine changes, it can break or have all sorts of
| unforeseen consequences. So you want to be building in an
| engine that isn't changing.
| jayd16 wrote:
| Unity has bug fix releases every two weeks so no.
|
| That said, I would say a lot of changes can be breaking because
| backwards compatibility is a much lower priority then code
| speed or size.
| prox wrote:
| They are still updating Godot 3, even backporting features from
| 4.
| M4v3R wrote:
| They do small, frequent software updates, it's called minor and
| patch versions. But when you're making a tool for creative
| professionals you don't want to release major versions of the
| tool every year, because these professionals care more for
| consistency and using their current skillset more than shiny
| new features in the next version.
| fezfight wrote:
| This especially true since this is a FOSS tool so there's no
| need to ship product bumps to sell units or anything like
| that. They can just release stuff when its ready.
| wongarsu wrote:
| Major version bumps with major features are still a great
| marketing tool; like this article making it to the HN
| frontpage. That attracts users and developers, both
| desirable for FOSS.
| gabereiser wrote:
| Except that we have releases of Adobe and Unity and things
| multiple times a year. Creatives value consistency but they
| also value ease of use. Improvements to UX and workflow
| should be allowed to break the mold of "don't touch it if it
| works". What they don't do is dictate the release cycle. Many
| patches end up in committee to be pooled together (or
| paywalled) into a vX.N.0 patch released when the business
| decides to.
| jibe wrote:
| Everyplace I've worked that's used Unity has locked into a
| version at the start, and only upgraded (other than minor
| versions/bug fixes) between projects. New projects today
| would use last years version.
|
| Adobe is less an issue because the new version of Photoshop
| isn't going to break your PSD.
| devmunchies wrote:
| Is there a reason you wouldn't use a game engine to create
| general purpose cross-platform apps? Is it cumbersome to create
| textual, structural interfaces (e.g. a twitter clone, google
| sheets clone, or an ecomm checkout flow)?
| phreack wrote:
| Yeah, likely you won't get as many tools to help with
| structured GUIs and expected hooks to the operating system
| commands that your user will want to use, but if what you're
| looking for is unstructured, quirky, or artsy content, possibly
| the way old school flash sites wanted to be, then it's
| certainly a fun option for cross platform apps.
| modeless wrote:
| You certainly could. You would probably run into a lot of
| issues in areas that games don't care about that much like
| multiple windows, smooth window resizing, fancy text layout and
| input, fast initial load times, matching OS themes and widget
| behavior, low resource usage at idle, copy/paste/drag/drop,
| software rendering, etc.
| lbotos wrote:
| Agreed with the poster below. Godot def could, but I know text
| rendering is not as nice as browsers last I checked.
___________________________________________________________________
(page generated 2022-07-28 17:00 UTC)