Developing Godot Projects with Neovim | Hacker News Reader

Developing Godot Projects with Neovim

devpoga.org

189 pointspoga42 comments

For more Godot goodness I recommend, Martin Donald, a technical artist whom has a great mini-series of re-creating various game effects using Godot:

- https://www.youtube.com/c/MartinDonald/videos

It makes a huge change from the tsunami of "I made pong for breakfast" level of material on youtube.

That's a great channel (given there's a recent thread about great youtube channels https://news.ycombinator.com/item?id=32220192 ).

For people who are less graphically inclined, but still want to check out godot, here's a great 2D simple code-along from the channel HeartBeast - https://www.youtube.com/playlist?list=PL9FzW-m48fn16W1Sz5bhT...

It's a pixel platformer, and is intended to show you the various 2D features of godot as well as be a tutorial.

Though I am no expert and am unsure whether this remains the case, I recall reading some time ago that Heartbeast had some bad practices in his code and that it was better to learn from GDQuest/Nathan Lovato's content instead. His content is also recommended on the official docs at https://docs.godotengine.org/en/stable/community/tutorials.h...

GDQuest made an excellent web"app" (also available as a desktop application, I believe all versions are made in Godot) that provides an interactive introduction to GDScript: https://gdquest.github.io/learn-gdscript

It's my favorite resource for learning Godot and I can heartily recommend GDQ's channel https://youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ/playlis...

Hard disagree.

I dont like GDQuest, as he uses every fancy/advanced technique he knows in his free and paid courses, which means its very hard to understand whats going on.

Heartbeast only focusses on one concept at a time, which makes it easy to follow whats going on. People criticising Heartbeast are the same type of people who make fun of beginners programming tutorials "Lol, doesnt even use Kubernetes, deploying manually. Teaching bad practices lol"

GDquest makes a type 2 mistake (from my blog[0]) where he uses advanced techniques, more it seems to me to impress others rather than to help readers. I bought their courses, but couldn't finish any as I struggled to follow the 20+ concepts being taught at the same time.

0. https://new.pythonforengineers.com/blog/the-problem-with-mos...

The categorization of mistake types is completely unnecessary in this context. The problem, root cause, and solution are all inferable from the next sentence.

Godot has a lot going for it. Standing in its way was the wide adoption of Unity. I feel that the merger with ironSource maybe removed that hurdle.

Being part of "the German Godot Discord" Server and skimming through the Godot subreddit from time to time. Yes, yes it helped. Several people are asking for advice on how to make the switch.

How can I find and join this Discord server?

It's a cliché at this point, but 4.0 (or more realistically, 4.1/4.2) would be the milestone that would result in professional adoption of Godot. 3D is still at indie-level now, and requires a lot of workarounds and hacks for some advanced stuff.

There is lots of truth behind the cliche. I've been trying out it's features the whole time alpha version's been out, and it's on a different level both in terms of usability and performance. Keeping in mind of course that alphas can be quite unstable and require you to untangle yourself every now and then. I'd advise most to wait atleast until beta

Yeah, another 4 alpha user, here. There were a few regressions while developing in Alpha, but 4 is shaping up to be really good.

Even if you don’t go for godot as your main engine, the speed with which you can prototype is really nice.

Not sure why you have been downvoted as I have seen a lot of that sentiment on twitter and youtube already.

I do not believe that this ironSource thing or the comments from the CEO will cause a real downfall of Unity but I do believe that VR is the area where Godot has the chance to sidestep the huge lead of Unity and shine as a real competitor.

Because the technology is still changing very rapidly and no one has too big a lead on others (especially with standalone headsets).

Godot even had support for Oculus hand tracking in late 2019 when it was not officially released for Unity and Unreal.

At the moment everyone manufacturer is building for Unity first and everything else second (if at all), but when OpenXR finally has established itself that will be a lot less of a factor

I think it's more likely that Unity will end up in a situation similar to Apple during the period where they messed up the Mac Pro and Macbook Pro - not losing huge sales, but the creative trendsetters that used to be their biggest evangelists will start looking for alternatives.

The Unity situation is definitely weird and Unity basically introduced a lot of FUD about itself. I know a lot of indies are worried about things like Unity pushing microtransactions on all developers. I think I would be worried even if I was the developer of one of those huge microtransaction games. Unity has probably seen how much money Apple and Google are making from their cut of microtransactions while Unity itself is only making money from the engine seat licensing (at least that’s my understanding. I don’t believe Unity collects royalties). I wouldn’t be surprised if Unity tries to change licensing for future versions of the engine to try to get it’s own slice of the microtransaction money.

What I'd see as a more of an obstacle is the lack of an asset store. Unity asset store has tons of stuff in it for very cheap and it's integrated straight into unity

There is an official asset library that only allows (F)OSS licensed stuff, and there are third party stores (but I don't know which is the best/most successful).

It hardly can be considered for a serious commercial project without having a engine team already. But for hobbyist it might become a good choice and the popularity definitly helps.

Might be a nitpick, but there’s also the problem of what exactly we are calling a “serious commercial project”.

Right now the most successful game made with Godot Engine is Cruelty Squad (https://store.steampowered.com/app/1388770/Cruelty_Squad/). Regardless of if you would call it “professional” or not, it was one of the most noted indie games of 2021, had great reviews, and probably was much more commercially successful than your average Unity/Unreal “professional” indie title (given how so many of them flop). Same goes for some highly successful RPG Maker games, which usually people would not call it a “commercial-quality” engine.

I think there’s a lesson here: don’t care that much if you’re using a “commercial” quality engine or not, just care if the engine will give the right tools to make the game that you envision.

https://store.steampowered.com/app/1249480/ExZodiac/

Here's an absolutely beautiful commercial game made in Godot.

miziziziz's wrought flesh has some great devlogs on the godot journey:

https://www.youtube.com/watch?v=qpFgdvG_WmI

There are still people out there rolling their own engines for commercial projects, it's all about what you can pull off with the tools you've chosen. But I would agree that there's a professional network and support system around Unity that Godot currently doesn't have. If you're planning to hire a team, it'd be much easier to find good Unity developers than Godot devs.

The Sonic Colors PC port is also running on Godot Engine.

sonic fans have mostly decided that was a bad port, saying that might do more damage than good

To be fair, Sonic fans don't like any Sonic games that have been released in the last 20 years.

Many of us consider _Sonic Mania (2017)_ to be the best sonic game ever made.

Some of the most egregious issues turned out to be because people on Twitter were not disclosing that they were running a brand new Switch game in an emulator.

But even aside from that, I'd argue Godot probably had little to do with the quality of the port. There's ample evidence that you can make buggy games with any engine, and the Sonic franchise in particular seems to have a long running problem with SEGA pushing releases out half-baked.

I've already seen some Unity expats in a game dev discord I'm part of, starting to pick up Godot. It's not just the ironSource merge, the CEO has made their focus ad-tech and monetization, whilst the game engine itself is still grappling with split focus issues and playing catch-up with Unreal. It's hard not to see that as a creative indie-dev and conclude that you're probably not the target market for the engine anymore.

The godot language server also seems really nice. You just add something like: lspconfig.gdscript.setup({}) to your init.lua (or equivalent in init.vim), then it works with the normal neovim autocomplete. More significantly, it means you can get the really great godot docs in a floaty window bubble without any context-switching.

How much worse is support for c# than for GDScript? We want to move away from unity and the whole team is already fluent in c#.

Not an expert in Godot and definitely not an expert in C#, but I'd say the only real difference is that the documentation for GDScript is slightly better and there are significantly more tutorials for using GDScript than C# with Godot. All of the functions and concepts that are used in GDScript have an equivalent in C#, and you normally can just use the same function in camelCase.

You can use both languages in one project, so I'd recommend trying GDScript at first. It's a very simple language so it can be picked up quickly, but as soon as you feel yourself reaching for LINQ or wanting a proper type system then switch that script to C#.

What about for C++? Reading the docs, the C++ support seems somewhat of a side-show, and documentation seems patchy on it.

I'm not sure if you are referring to GDNative which is the native/binary "scripting" interface, or hacking on the engine code itself. Neither are the primary way to use Godot -- the documentation reflects that, I guess. A lot of the documentation is not language specific, and a lot of the topics covered are fundamental.

The engine code is great. It's structured logically and navigating it is intuitive. Building the engine is simple, customisable, and documented well. Significant chunks of the engine are integrated as compiled in 'modules'. You can add your own modules and the build system lets you select which modules to include. Adding new node types and working with the scripting/binding system is pretty straight-forward.

I think the documentation for working on the engine[0] and contributing to the project[1] (as well as the code itself) are areas where Godot is doing exceptionally well.

GDNative can be used to integrate external libraries, add support for other languages[2], without compiling the engine. You can use it as a scripting layer, add node types, etc. I haven't used GDNative non-trivially.

* [0] https://docs.godotengine.org/en/stable/development/cpp/index...

* [1] https://docs.godotengine.org/en/stable/community/contributin...

* [2] https://github.com/godot-rust/godot-rust

Godot home page itself mentions c++ on the same line as GDScript and C#.

Text from Godot home page:

"Use the right language for the job:

Keep your code modular with an object-oriented API using Godot's own GDScript, C#, C++, or bring your own using GDNative."

But my memory was that last time I tried about a year ago, something was patchy about c++ documentation.

My doubt still is if c++ is a first class citizen in Godot at par with GDScript and c#.

Out of curiosity, why do you want to move away from Unity?

Stability, the editor just gets slower and slower, price (especially as the team grows and you have to pay per person per month), corporate direction they’ve been going in lately.

I am a novice Godot user, but I find the c# support is really easy to use. A lot of the code on their site you can view in either language. And even when I can find people's examples only in gdscript, it's really easy to translate it to c#. I have it linked to visual studio, so I get auto-completions which are 99% of the time all I need.

It's really nice to be able to just create some game object, then immediately take advantage of anything else I need to do on the c# side.. whether it be some basic classes for player objects, helpful static data structures etc.

The Godot documentation is also pretty easy to parse. So I made a Dash[1] docset from it: https://github.com/poga/godot-dash-docset

[1]: https://kapeli.com/dash

On linux based OSes, Godot must generate pure and simple ELF64 binaries which do libdl everything from the system, and that means:

   * no C/c++ main(), but the sysv ABI entry point (which is basically main() anyway). When the libc will be libdl-ed, the init functions are called with the same arguments stack than the sysv ABI entry point.

   * interact with system TLS-ized variable with only the sysv ABI __tls_get_addr(), for instance if there is a need to use errno. I have to admit, I did not get really into this issue yet (but there my be seriously nasty things related to the "TLS offset").

   * fork the static gcc/clang libstdc++ in order to libdl-ize it, because even with -static-libstdc++/-static-libgcc options, it won't libdl what it requires from the system libs (gcc devs 100% at fault here, they have been carefully ignoring the availability of games on linux OSes for a decade). rant[on], to avoid this and the dependency on the very few c++ compilers (because c++ syntax is beyond sanity), godot should have been a simple and lean C project, rant[off].

Currently, the only way to mitigate the GNU symbol versoning abuse from the glibc devs (100% their fault), is to compile/link against a years old glibc (_REALLY_ old).

That said, they should od exactly the same on other OSes, which means the code structure would be the same, only different compile-time and runtime function tables.

I'd also check out https://www.o3de.org if you're looking for an open source gaming engine

I am curious. What's the point of having yet another DSL for scripting when there are established scripting languages like the Lua/Teal/Luau/Janet family ?

This is actually explained in the Godot docs: https://docs.godotengine.org/en/latest/about/faq.html#what-i...

Thanks!

Reply on news.ycombinator.com