9 ms·

Godot 4.0 development enters feature freeze ahead of the first beta

173 points by tianreyma 4y ago

TillE 4y ago
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#.
- _aavaa_ 4y ago
  The Wiki page says it already supports C#. As completely on the outside, what is missing?
  - nodja 4y ago
    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.
  - sfteus 4y ago
    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 4y ago
    [deleted]
- nemothekid 4y ago
  >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 4y ago
    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.
    - jbluepolarbear 4y ago
      Unity uses their own AOT compiler IL2CPP that translates C# code to C++. Mono is an option in builds, but most projects are using IL2CPP nowadays and have been moving to .Net core. Although C++ is king, C# has quickly caught up to be a close 2nd. Unity is used to make 50% of all mobile, pc, and consoles games (according to Unity https://unity.com/our-company https://unity.com/our-company).
    - deleted 4y ago
      [deleted]
- opyate 4y ago
  > 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 https://twitter.com/LegatXyotic/status/1552219744723402756
  - Waterluvian 4y ago
    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.
    - tokumei 4y ago
      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.
    - tmp_anon_22 4y ago
      > 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.
    - stu2b50 4y ago
      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.
- fezfight 4y ago
  Does Godot's implenetation of C#/.net include the .net temeletry? https://github.com/dotnet/sdk/issues/14556 https://github.com/dotnet/sdk/issues/14556
  - Kwpolska 4y ago
    The telemetry isn’t in C#/.NET proper, it’s in the `dotnet` CLI utility.
- somehnacct3757 4y ago
  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?
  - marcosdumay 4y ago
    GDscript is a bit slow. It's not an issue if you use it to keep track of a reasonable amount of in-game data and control the objects to render. But it becomes an issue if you decide to write game intelligence in it, or keep track of a lot of things. It also doesn't have an all integrated top of the market IDE, only the Godot IDE. (Although I don't think you gain anything from using a 3rd party IDE in a Godot game. Even less something like Visual Studio.)
- drmidnight 4y ago
  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 4y ago
    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.
    - drmidnight 4y ago
      I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine. Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.
- Mikeb85 4y ago
  > but to write a serious game you really want C#. This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++. In fact, I'd argue C++ is far better than a bolted on C#...
  - TheAceOfHearts 4y ago
    I don't have experience with GDScript, so please forgive the ignorant question. Does GDScript have good debugging, linting, and profiling tools? I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development. One of the main criticisms I've heard of using scripting languages for game development is that they tend to be lacking when it comes to tooling. The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.
    - Mikeb85 4y ago
      I mean, GDScript doesn't exist outside of the Godot engine. Debugging for it is the same as debugging a Godot game. All GDScript functions are C++ methods. Also, there are type hints if you want. If you're going to be doing a very large, ambitious game, odds are you'll also be creating your own C++ methods and thus debugging using C++ tools and the game engine tools...
    - cardanome 4y ago
      > Does GDScript have good debugging, linting, and profiling tools? Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.) > The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point. GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.) Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal. C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust). Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)
strictfp 4y ago
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.
- blamestross 4y ago
  /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 4y ago
  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 4y ago
    Thanks. Do you setup an artificial tree during testing? If so, how?
    - b33j0r 4y ago
      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/running_code_in_the_editor.html https://docs.godotengine.org/en/stable/tutorials/plugins/run... 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.
mkw5053 4y ago
Is there something inherent with game engines that prohibits small, frequent software delivery? (call it agile or lean, if you want)
- prox 4y ago
  They are still updating Godot 3, even backporting features from 4.
- M4v3R 4y ago
  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 4y ago
    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 4y ago
      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.
  - reactordev 4y ago
    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.
marcodiego 4y ago
Comes in a good moment considering recent Unity backlash.
devmunchies 4y ago
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)?
- modeless 4y ago
  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.
  - ClawsOnPaws 4y ago
    Add accessibility to that list. Screen readers, magnifiers, switch controls, etc. Usually game engines don't support these while your native OS UI probably does, and the web is also not bad in that regard.
    - jamesgeck0 4y ago
      IIRC there is actually an ongoing Godot accessibility effort.
- lbotos 4y ago
  Agreed with the poster below. Godot def could, but I know text rendering is not as nice as browsers last I checked.
- phreack 4y ago
  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.
- stephc_int13 4y ago
jmcgough 4y ago
Friends in the industry all say it's a nonstarter that it does not (and will not) have cross platform support, as much as they hate Unity. Godot's official stance on it is that you should hire a team to port it for you lol...
- somehnacct3757 4y ago
  If you're long on the games industry we are probably in the last generation of game console architecture. Everything is going to be Windows or Linux boxes with PC hardware next gen. I could see Nintendo bucking this trend but they have enough IP to be their own island. It might be smart for Godot to punt; it lets them go faster than Unity and catch up
  - r_hoods_ghost 4y ago
    I've been hearing that since the first Xbox came out (which used an x86 architecture before the Xbox 360 moved to powerpc) and it still hasn't happened.
    - somehnacct3757 4y ago
      Consoles are actively migrating their audiences onto digital subscription services so that the brand has an identity separate from the console. The future is selling hardware if you must, so you can make money selling PC games. Microsoft's strategy is to sell PC games on Windows devices. They might call some of them Xboxes. Valve's strategy is to maintain a Linux distro that can play PC games. Sony also ran.
  - KronisLV 4y ago
    > Everything is going to be Windows or Linux boxes with PC hardware next gen. Are you sure about this? I mean, as awesome as that would be just look at the mobile market - Android had every chance to be a properly open OS (e.g. AOSP), but instead its a mess of flakey drivers, locked down bootloaders and other anti-user practices that curb our freedoms with our devices. I foresee that trend mostly remaining as it is in regards to consoles as well (and IoT devices), outside of projects like Steam Deck. But then again, I'm still bummed out that it wasn't possible for me to install Linux on my PS4 and use it as a development box (since updates explicitly fixed any vulnerabilities that would allow for that), because its form factor was great. Hell, it's probably just a matter of time until PCs and laptops are sold with locked down bootloader and only run Windows or whatever other manufacturer sanctioned/mandated OS would be included.
deworms 4y ago
Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be. There was even a pull request implementing this feature opened, but they claim the assigned maintainer just didn't have the time to review it yet (over 5 years!). One person can effectively stall all progress out of spite. That's no way to run an open source project. Just look at this discussion: https://github.com/godotengine/godot-proposals/issues/2972 https://github.com/godotengine/godot-proposals/issues/2972
- detuur 4y ago
  I find it a bit untrustworthy when someone frames a language design issue as representative of the way the project is run. List comprehension is a feature that comparatively few languages have, and I can easily imagine that the GDScript team has other things they consider a priority. For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.
- rng_civ 4y ago
  Open source != open contribution. Don't like how they run it? Fork it. The maintainers have ZERO obligation to merge your PRs, especially when they don't actually agree with it.
- seba_dos1 4y ago
  > That's no way to run an open source project. The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.
- Mikeb85 4y ago
  Why would you want list comprehensions in a game engine? It's just sugar to make looping over a list or array look more functional but not particularly useful in a game.
churnedgodotdev 4y ago
After quickly falling in love with Godot and several months of serious use I'm having to give up on it due to Godot's lack of funding to fix its more than 6000 open issues on Github: https://github.com/godotengine/godot/issues Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten by #45628 opened Feb 1, 2021: https://github.com/godotengine/godot/issues/45628 When implementing controller support for a top-down Zelda-like game, it's normal to allow either the d-pad or left analog stick to control direction. But if you enable both at the same time in Godot then d-pad inputs cause your character to "freeze". Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.
- TillE 4y ago
  I found and fixed a small Godot bug, starting from zero knowledge of the engine code, in about a day and a half free time. It's really not hard to just patch stuff yourself if you're comfortable with C++. Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.
- herewulf 4y ago
  Out of curiosity, are you funding it? I've been funding it (a small amount monthly) for a long time now. I wish it had existed about 15 years ago in college when I had lots of time on my hands for toying with game making.
  - churnedgodotdev 4y ago
    I'd fund it if I could use it to actually ship something and make money. I've donated to other software projects. If, say, for several thousand bucks they'd actually give me a tiny bit of support by fixing bugs in the "stable" branch that affect me then I'd pay up. At this point though if I want to actually ship using open source I find I can actually get things done faster using SDL2. Because SDL2 is a minimal layer over native if there is an issue I can actually figure out what native calls are happening in what order. If controller inputs are wonky or textures are the wrong color I can figure out why. Godot does try to use an understandability friendly subset of C++ (no template metaprogramming and such) but it is still too sophisticated for me to quickly dive in and understand how it all works; and it is certainly too complicated for its core maintainers to be able to quickly dive in and fix longstanding open issues in "stable".
999900000999 4y ago
My blunt review of Godot after using it for about 3 weeks, it's the community's Unity. But it's just not there yet, things which take seconds in Unity take minutes in Godot. Or are just impossible. It's not done yet, it's going to probably be done in either late 2023 or 2024. Godot 4 needs to come out, and they need to add mono. I've never been more frustrated with a programming language before I found Godot script, just why. Why not use Python, why, why not use? I don't know, haxe. Even Godot's creator tried to calm everybody down, you're comparing what's basically a souped-up hobbyist project by maybe two or 300 volunteers to professional products by multi-billion dollar companies of tens of thousands of people. All that said, I am fighting through Godot right now and I'm having the most fun with game development I've had in years. I try to armory as well, which is not nearly as advanced as Godot, but has the most welcoming community I've ever seen. I Feel like, back when I first learned a program when I work with Godot. With mono, which is on 3.5 which is very nice. Too long. Read, if you want to make a commercial product, you're still stuck using Unity or Unreal, However, if you want to just make games for the sake of making games. Godot.
- herewulf 4y ago
  > Why not use Python, why, why not use? I don't know, haxe. Neither Python nor Haxe (presumably) have built-in types for vectors, quaternions, and matrices. Quite nice convenience features. Though I'd rather write in a lot of other languages than GDscript.
  - pjmlp 4y ago
    Python also doesn't have builtin types for linear algebra, hence NumPy. So it isn't as if they couldn't add the support.

173 points by tianreyma 4y ago

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#.

_aavaa_ 4y ago
The Wiki page says it already supports C#. As completely on the outside, what is missing?
- nodja 4y ago
  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.
- sfteus 4y ago
  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 4y ago
  [deleted]
nemothekid 4y ago
>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 4y ago
  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.
  - jbluepolarbear 4y ago
    Unity uses their own AOT compiler IL2CPP that translates C# code to C++. Mono is an option in builds, but most projects are using IL2CPP nowadays and have been moving to .Net core. Although C++ is king, C# has quickly caught up to be a close 2nd. Unity is used to make 50% of all mobile, pc, and consoles games (according to Unity https://unity.com/our-company https://unity.com/our-company).
  - deleted 4y ago
    [deleted]
opyate 4y ago
> 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 https://twitter.com/LegatXyotic/status/1552219744723402756
- Waterluvian 4y ago
  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.
  - tokumei 4y ago
    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.
  - tmp_anon_22 4y ago
    > 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.
  - stu2b50 4y ago
    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.
fezfight 4y ago
Does Godot's implenetation of C#/.net include the .net temeletry? https://github.com/dotnet/sdk/issues/14556 https://github.com/dotnet/sdk/issues/14556
- Kwpolska 4y ago
  The telemetry isn’t in C#/.NET proper, it’s in the `dotnet` CLI utility.
somehnacct3757 4y ago
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?
- marcosdumay 4y ago
  GDscript is a bit slow. It's not an issue if you use it to keep track of a reasonable amount of in-game data and control the objects to render. But it becomes an issue if you decide to write game intelligence in it, or keep track of a lot of things. It also doesn't have an all integrated top of the market IDE, only the Godot IDE. (Although I don't think you gain anything from using a 3rd party IDE in a Godot game. Even less something like Visual Studio.)
drmidnight 4y ago
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 4y ago
  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.
  - drmidnight 4y ago
    I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine. Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.
Mikeb85 4y ago
> but to write a serious game you really want C#. This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++. In fact, I'd argue C++ is far better than a bolted on C#...
- TheAceOfHearts 4y ago
  I don't have experience with GDScript, so please forgive the ignorant question. Does GDScript have good debugging, linting, and profiling tools? I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development. One of the main criticisms I've heard of using scripting languages for game development is that they tend to be lacking when it comes to tooling. The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.
  - Mikeb85 4y ago
    I mean, GDScript doesn't exist outside of the Godot engine. Debugging for it is the same as debugging a Godot game. All GDScript functions are C++ methods. Also, there are type hints if you want. If you're going to be doing a very large, ambitious game, odds are you'll also be creating your own C++ methods and thus debugging using C++ tools and the game engine tools...
  - cardanome 4y ago
    > Does GDScript have good debugging, linting, and profiling tools? Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.) > The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point. GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.) Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal. C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust). Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)

strictfp 4y ago

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.

blamestross 4y ago
/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 4y ago
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 4y ago
  Thanks. Do you setup an artificial tree during testing? If so, how?
  - b33j0r 4y ago
    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/running_code_in_the_editor.html https://docs.godotengine.org/en/stable/tutorials/plugins/run... 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.

mkw5053 4y ago

Is there something inherent with game engines that prohibits small, frequent software delivery? (call it agile or lean, if you want)

prox 4y ago
They are still updating Godot 3, even backporting features from 4.
M4v3R 4y ago
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 4y ago
  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 4y ago
    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.
- reactordev 4y ago
  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.

marcodiego 4y ago

Comes in a good moment considering recent Unity backlash.

devmunchies 4y ago

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)?

modeless 4y ago
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.
- ClawsOnPaws 4y ago
  Add accessibility to that list. Screen readers, magnifiers, switch controls, etc. Usually game engines don't support these while your native OS UI probably does, and the web is also not bad in that regard.
  - jamesgeck0 4y ago
    IIRC there is actually an ongoing Godot accessibility effort.
lbotos 4y ago
Agreed with the poster below. Godot def could, but I know text rendering is not as nice as browsers last I checked.
phreack 4y ago
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.
stephc_int13 4y ago

jmcgough 4y ago

Friends in the industry all say it's a nonstarter that it does not (and will not) have cross platform support, as much as they hate Unity. Godot's official stance on it is that you should hire a team to port it for you lol...

somehnacct3757 4y ago
If you're long on the games industry we are probably in the last generation of game console architecture. Everything is going to be Windows or Linux boxes with PC hardware next gen. I could see Nintendo bucking this trend but they have enough IP to be their own island. It might be smart for Godot to punt; it lets them go faster than Unity and catch up
- r_hoods_ghost 4y ago
  I've been hearing that since the first Xbox came out (which used an x86 architecture before the Xbox 360 moved to powerpc) and it still hasn't happened.
  - somehnacct3757 4y ago
    Consoles are actively migrating their audiences onto digital subscription services so that the brand has an identity separate from the console. The future is selling hardware if you must, so you can make money selling PC games. Microsoft's strategy is to sell PC games on Windows devices. They might call some of them Xboxes. Valve's strategy is to maintain a Linux distro that can play PC games. Sony also ran.
- KronisLV 4y ago
  > Everything is going to be Windows or Linux boxes with PC hardware next gen. Are you sure about this? I mean, as awesome as that would be just look at the mobile market - Android had every chance to be a properly open OS (e.g. AOSP), but instead its a mess of flakey drivers, locked down bootloaders and other anti-user practices that curb our freedoms with our devices. I foresee that trend mostly remaining as it is in regards to consoles as well (and IoT devices), outside of projects like Steam Deck. But then again, I'm still bummed out that it wasn't possible for me to install Linux on my PS4 and use it as a development box (since updates explicitly fixed any vulnerabilities that would allow for that), because its form factor was great. Hell, it's probably just a matter of time until PCs and laptops are sold with locked down bootloader and only run Windows or whatever other manufacturer sanctioned/mandated OS would be included.

deworms 4y ago

Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be. There was even a pull request implementing this feature opened, but they claim the assigned maintainer just didn't have the time to review it yet (over 5 years!). One person can effectively stall all progress out of spite. That's no way to run an open source project. Just look at this discussion: https://github.com/godotengine/godot-proposals/issues/2972 https://github.com/godotengine/godot-proposals/issues/2972

detuur 4y ago
I find it a bit untrustworthy when someone frames a language design issue as representative of the way the project is run. List comprehension is a feature that comparatively few languages have, and I can easily imagine that the GDScript team has other things they consider a priority. For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.
rng_civ 4y ago
Open source != open contribution. Don't like how they run it? Fork it. The maintainers have ZERO obligation to merge your PRs, especially when they don't actually agree with it.
seba_dos1 4y ago
> That's no way to run an open source project. The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.
Mikeb85 4y ago
Why would you want list comprehensions in a game engine? It's just sugar to make looping over a list or array look more functional but not particularly useful in a game.

churnedgodotdev 4y ago

After quickly falling in love with Godot and several months of serious use I'm having to give up on it due to Godot's lack of funding to fix its more than 6000 open issues on Github: https://github.com/godotengine/godot/issues Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten by #45628 opened Feb 1, 2021: https://github.com/godotengine/godot/issues/45628 When implementing controller support for a top-down Zelda-like game, it's normal to allow either the d-pad or left analog stick to control direction. But if you enable both at the same time in Godot then d-pad inputs cause your character to "freeze". Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.

TillE 4y ago
I found and fixed a small Godot bug, starting from zero knowledge of the engine code, in about a day and a half free time. It's really not hard to just patch stuff yourself if you're comfortable with C++. Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.
herewulf 4y ago
Out of curiosity, are you funding it? I've been funding it (a small amount monthly) for a long time now. I wish it had existed about 15 years ago in college when I had lots of time on my hands for toying with game making.
- churnedgodotdev 4y ago
  I'd fund it if I could use it to actually ship something and make money. I've donated to other software projects. If, say, for several thousand bucks they'd actually give me a tiny bit of support by fixing bugs in the "stable" branch that affect me then I'd pay up. At this point though if I want to actually ship using open source I find I can actually get things done faster using SDL2. Because SDL2 is a minimal layer over native if there is an issue I can actually figure out what native calls are happening in what order. If controller inputs are wonky or textures are the wrong color I can figure out why. Godot does try to use an understandability friendly subset of C++ (no template metaprogramming and such) but it is still too sophisticated for me to quickly dive in and understand how it all works; and it is certainly too complicated for its core maintainers to be able to quickly dive in and fix longstanding open issues in "stable".

999900000999 4y ago

My blunt review of Godot after using it for about 3 weeks, it's the community's Unity. But it's just not there yet, things which take seconds in Unity take minutes in Godot. Or are just impossible. It's not done yet, it's going to probably be done in either late 2023 or 2024. Godot 4 needs to come out, and they need to add mono. I've never been more frustrated with a programming language before I found Godot script, just why. Why not use Python, why, why not use? I don't know, haxe. Even Godot's creator tried to calm everybody down, you're comparing what's basically a souped-up hobbyist project by maybe two or 300 volunteers to professional products by multi-billion dollar companies of tens of thousands of people. All that said, I am fighting through Godot right now and I'm having the most fun with game development I've had in years. I try to armory as well, which is not nearly as advanced as Godot, but has the most welcoming community I've ever seen. I Feel like, back when I first learned a program when I work with Godot. With mono, which is on 3.5 which is very nice. Too long. Read, if you want to make a commercial product, you're still stuck using Unity or Unreal, However, if you want to just make games for the sake of making games. Godot.

herewulf 4y ago
> Why not use Python, why, why not use? I don't know, haxe. Neither Python nor Haxe (presumably) have built-in types for vectors, quaternions, and matrices. Quite nice convenience features. Though I'd rather write in a lot of other languages than GDscript.
- pjmlp 4y ago
  Python also doesn't have builtin types for linear algebra, hence NumPy. So it isn't as if they couldn't add the support.