Learn Godot Game Development | Hacker News Reader

Learn Godot Game Development

godottutorials.pro

221 pointsstudentLS65 comments

I came back to Godot this week, after tying an earlier 2.x build. I've had a 3D game I've wanted to develop for years, and gave it a shot awhile back. Unfortunately, the tools capable of building what I wanted had too steep of a learning curve for my free time. Godot, while incredibly intuitive, wasn't performant enough to make what I wanted.

I built 3.2, including a fork of the runtime for raspberry pi (frt on github). About 3 hours of youtube videos later, 3 hours of sweat, and I had a functional 3D tech demo of the idea I had.

It's well worth a look, and per geokon's comment, I too was against the team implementing a new language, but have since come to love it. It's Python, with the correct changes for the use case, and it works well.

That's great to here. Hopefully the improvements that are coming with 4.0 will make your demo even more performant.

Using C# in Godot instead of GDScript results in better performance. Roughly 4x better compared to GDScript in some naive cases.[1]

1: https://docs.godotengine.org/en/stable/getting_started/scrip...

to somehow who's used it extensively - was a DSL really necessary?

I find the whole idea of a separate language for just developing interactive media a bit off-putting. It's a huge price to pay over just plugging in an existing mainstream language. no more tutorials, zillions of references a robust toolchain, huge community.. etc. but there must be a good reason for it?

It's also why I don't write elisp. only so many hours in a day.. do I want to be futsing around in a language I won't ever use outside of the sandbox? not really...

it's not longer just a library of some language X, but an ecosystem I need to sorta sell my soul to

I find gdscript almost excusable, as it has been similar enough to Python and had a fewer killer features (exported variables are available in editor, as are declared signals, etc). It's still not the ideal design decision and I often wish I was searching snippets of e.g. JavaScript. They do have C# support now!

There is a list of reasons why they decided to go with DSL. And I like it, it's even easier to use than lua and well integrated.

https://docs.godotengine.org/en/3.2/getting_started/scriptin...

It is honestly quite a poor language too. I wrote a simple game in godot and honestly the language works okay and is quite interesting for the game logic, however it is quite poor when it comes to everything less game-like, for example reading and writing to files and string manipulation felt very rudimentary. Worst part is that it feels so much like python due to its syntax yet it is much less expressive

I wouldn't go so far as calling it a poor language, but I do feel the same way about the language in the same domains as you. I've recently run into issues with this in a project I'm currently working on

I find GDScript to be fine and very easy to pick up having never actually read a tutorial on the language. With that being said I'm more of an average programmer and I don't spend my time debating every nuance to a language so your mileage my vary. Godot does officially support C# now and there are plugins for many other languages including Python, Go, and Rust.

There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited.

> There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited.

It's not a DSL, it's a full on programming language. It's like claiming Action Script was a DSL, it wasn't.

It means tons of code in that language in order to create custom business logic, it means re-implementing things that were already written in tons of languages and so on and so forth.

So a new language makes sense but it's a trade-off.

Apparently there is the possibility of using other languages, so let's see if the integration is as robust.

https://godotengine.org/article/introducing-csharp-godot

Whether GDScript is a DSL is arguable; a game engine scripting language falls in the interesting middle ground between a special purpose DSL with a limited scope (e.g. awk) and a general-purpose programming language with tacked-on frameworks (e.g. C++ and DirectX).

There are important assumptions and specializations (e.g. the engine-managed game loop and attaching scripts to nodes) but also a large variety of use cases (for example both low effort and high performance graphics)

I, for one, loved mIRC scripting

Yes it probably is necessary. They've gone through a few iterations: lua, python, etc.

Is anyone else bored of the usage of the word language in computer circles?

Is there a need for a less boring word? :D

Is a more boring word absolutely necessary?

When you are staying home staying safe?

You can also use C#.

You can also use GDNative where you use C++ (or rust with some work)

As someone who’s gone down the route of working with an extension language—

Most language implementations are fairly poor at being used for extension. You can see that a lot of people use Lua for this purpose. Given how terrible Lua is as a language, there must be a compelling reason why people use it, right? It’s easy to use as an extension language. Same thing for JavaScript.

There are a few other random languages in this space. Squirrel, AngelScript, and Wren come to mind. It’s not a long list. Making your own language seems pretty appealing at that point.

One of the main things you want here is for sandboxed code to stay in the sandbox, and then to be able to destroy the sandbox to get a fresh slate back. V8 and SpiderMonkey do this, as do Lua, Squirrel, AngelScript, and Wren. Most language implementations do not. CPython has tons of global state. Mono, JVM are both huge and make this difficult (you can use Application Domains in .NET but that’s fairly arcane).

Criticisms of GDScript apply to these languages too, with the exception of JavaScript, as far as I can tell.

I’m leaving out a bunch of projects which for various reasons are even less suitable. Guile, TCL, etc.

Game dev here. I've used Godot only a little bit, and Unity a lot.

If you're working a lot with a single game engine, it's nice to have a programming language that's tightly coupled to it.

When Unity moved away from UnityScript (a javascript lookalike but specialised for their purposes) towards C# they had to e.g. change their notation for Coroutines which made it a lot clunkier, so instead of just "yield WaitForSeconds(2.5)" you now do "yield return new WaitForSeconds(2.5f)" AND change your function signature (add an IEnumerable) AND have to change how you call the function - lots of cruft where previously it was all transparent/implicit.

Also, if you're working on your own scripting language you can make it a lot more aware of the particular data and structure of in your own game (games have a lot of data!). I haven't used GDscript/Godot a lot, but I remember the autocomplete being pretty smart and aware of what's going on with your data in a way that would be hard to do with a "commodity" compiler/IDE tool-chain.

It's a lot of work for them to do this on their end, but I think it pays off. It doesn't take much time to learn (especially compared to the api/3d scene interface/etc) and overall it feels slick.

Most of the niceness is sparing on overhead, it's not a fundamentally alien or goofy language. As a games programmer I have to work with a bazillion programming languages anyway; if I'm working on a single project it's a real luxury to have the language be ergonomically fitted to the engine.

There are advantages to using a more general programming language - maybe using Lua would've been a good option, but yeah for here at least I think it's fine (ah, another commenter linked https://docs.godotengine.org/en/3.2/getting_started/scriptin..., which talks about this :) ).

On the other hand, if programming juggernaut Unity couldn't justify keeping Unityscript alive, maybe Godot is also fated to change eventually...

I like gdscript and my only gripes are that I use python for work and while gdscript is Python like I find the instances where it doesn't work like Python frustrating. Auto complete works great and it works even better when using typed gdscript, though it's still a new feature, and still has some edge cases that make it a little tricky to use sometimes.

Yeah seems kind of odd to me that Godot is making the same mistakes Unity once did but is now moving away from.

Unity had UnityScript and a C++ engine but is now heavily investing in C#, moving engine parts to C# and focusing on performance in C#. Unity once had a more static and predefined graphics pipeline like Godot, but has now made it more configurable. I'm especially apprehensive about how restrictive the Godot shader language is.

I've made 2 small 3d "games" with Godot using GDScript now. I haven't used Unity or any of the competitors

Learning GDScript was natural and might have even helped when you are learning all the principles of Godot at the same time. Programming in Godot was not at all similar to the backend programming I was used to and I had to learn all kinds of gaming specific concepts.

If they had used Python, you'd essentially need to learn a whole new Standard Library anyway, so you might as well get the benefits of a domain-specific language anyway.

Godot's scripting language is fine for what it is. Not much bigger than it needs to be. Thankfully, if you want something more there are also C# bindings for the engine, and you can also use C++ for performance-critical elements of the engine relatively trivially.

I had this opinion when I first began working with Godot, which regardless of language I've just found incredibly intuitive.

I used C#, but kept getting frustrated cause the support isn't at 100% (this is currently expected, I think C# is still declared alpha?). It was pretty easy to fill in the gaps between gdscript documentation vs C#, but certain built in functionality was missing.

My main use case for C# was strong typing, and the community support it has either with libraries or just getting answers online.

Eventually I caved in and tried gdscript. I can develop MUCH faster, and am still able to use types. You can also still use C# in the project, since the languages can communicate.

I think once C# has feature parity with Godot I'll move back to that, but until then, GDscript is great, and really easy to pick up.

You're right. C# support is not all the way there, but support continues to improve https://godotengine.org/article/csharp-ios-signals-events and will be better in 4.0 and potentially a 3.2.x release before then.

GDScript is reasonable once you've picked it up and Godot shines for 2D games because of simplicity compared to Unity. The main hassle that killed it for me is the effort required to integrate all the 3rd party libraries from ad companies, analytics, etc. There's not really good support on wrappers for common 3rd party libraries on mobile. If you're serious about game dev I'd focus on Unity because that's where the ecosystem is.

How timely! I've just started looking into game development and more specifically Godot today. I'm not exactly sure how I should proceed if my intention is to make something like Flappy bird for both Android and iOS - Would Godot be overkill? Should I try to make it with Flutter or React Native (or would those two be even more overkill)? What size would be too big for it?

Almost anything will work to make something as simple as the bird games, so don't worry too much.

Even moving HTML elements with CSS animations triggered by Lua compiled to JS would probably work fast enough...

PS: don't do that, don't create a monster!

You can trigger the CSS animations from a Lua interpreter written in JavaScript :) https://fengari.io/

I am crossing my fingers for a nice, cuddly monster! And thanks!

Check out Corona (https://coronalabs.com/). It’s a pretty straightforward 2d engine with support for many platforms. Games are written in lua which isn’t hard to learn if you’re already familiar with JS.

This is not the right time to give someone Corona.

I'm not saying they should change their name, but maybe lay low for awhile.

Corona Labs is shutting down in a couple of weeks. While they're releasing everything under a permissive license (MIT) and turning it into an open source project, the future is very uncertain.

the lead developer of the engine is continuing and has support on github to continue the development.

Thanks for the suggestion!

If you just started game developement, and your intended game is simple, I would just use plain javascript, html elements for UI, audio and canvas and consider everything else overkill. ChromeDevTools are a very powerful IDE nowdays, but simple enough, that you can just use the debugger, without setting anything up.

Very simple, but so you learn the basic concepts, without getting side tracked in millions and millions of different libaries and tools.

And if you do things right, your game will then run anywhere, where a modern browser works.

There's value in using the right tools for the job. Making games with plain javascript is HARD, there is too much complexity as the environment is simply designed for a different use case.

There's much to learn in game development on itself, so using a dedicated library that will make the simple tasks easy is always a good idea.

To say to not using any game engine was maybe exaggerating, but I believe it is important to understand the basic concepts. And when the goal is, to make a flappy bird like game, the canvas and some scripting would be a good start, I believe, if there is zero experience.

On the other hand, I also started with Adobes Flash. You could draw and animate and script right away ... and get awesome results right away .. without having to google html audio element.

last I looked at it a few years ago, Cocos2D was a pretty good balance between powerful and newbie-friendly. The tutorial started from the basics of what makes a game program and built up from there. Quite a nice engine for 2D stuff.

For cross-platfrom 2D (not mobile, but Windows, Mac, Linux) I recommend looking at Love2D

https://love2d.org/

Easy to use, good documentation, simple API, based off Lua. I suspect it's meant for smaller projects.

Actually, Love2D is for used mobile as well. Both android and iOS is supported and there are community ports for other platforms

Thanks!

Your output artifact will be larger with godot than with gideros. I really like the node scene system in godot though. I'd flip a coin (especially if you are new to programming :)).

Thanks!

Something like Flappy Bird is easily done in Godot and can help you learn the engine. I for one really like Godot and look forward to using it for many of my game projects. You'll really like the node system once you get into it. Look on YouTube for tutorials, there's quite a few.

Thanks!

Might as well ask here, but if I want to make a third-person shooter, but in the style of S.T.A.L.K.E.R, would Godot work for that? I've started with Unreal, but it's starting to feel way too heavy, but I don't want to reinvent the wheel either.

Unity is usually better suited/more mature for 3d than Godot.

It would work in all 3 of them. A (huge) project like stalker does not fail because of engine choice, I would guess (the custom programming required for such a project is so enormous that any game engine peculiarities are dwarfed in comparison).

I would look at the https://github.com/godotengine/tps-demo (which I think comes preloaded at least on the steam version) to see what Godot's current capabilities are for a 3d shooter.

Godot is currently undergoing a major 3D graphics rewrite/update for version 4.0, with Vulkan support and a big push for 3D feature parity with other engines.

You could use Godot if you really like the open-source-ness of it, and don't mind waiting for 4.0 or doing the work to port your game from 3.2 to 4.0. If you want to get going now, use something else.

I feel like Godot is not graphically competitive with Unreal, but it feels much more conceptually cleaner. Godot will probably get better graphics, in the way that Unity has over the last few years. I guess the question is, are you planning on having state of the art graphics? If so -- use another engine.

I like Godot a lot.

UE4s c++ documentation really is frustrating

I've been waiting for it so long

Why? I haven't finished their official guide yet, but I already have lots of bookmarks on different tutorial series like this one

https://www.youtube.com/user/uheartbeast/videos

There is no shortage for godot tutorials anymore

It's a joke about the play "Waiting for Godot"

https://en.wikipedia.org/wiki/Waiting_for_Godot

I say this play with Patrick Stewart and Ian McKellen.. basically the highlight of my life.

Truly one of the best acting duos in history.

Can Godot produce 3D games that are 10x more performant and efficient than Dreams on PS4?

Weird comparison to request. Godot doesn't support Ps4. There are some impressive performant demos with Godot, such as Zylann's voxel plugins. It has similar issues as Unity, where if you write things in C# or GDScript, the garbage collector will cause intermittent lags, but C++ is fully supported where you need it.

I didn’t mean to compare specifically to PS4. I was just clarifying that Dreams is a PS4 game.

The comparison is more about the framework usability vs the quality of the end product.

I’m wondering if Godot is maybe targeting similar audiences as Dreams or if Godot is targeting a more serious developer concerned about things like performance

Godot targets both, it's used to teach kids programming KidsCanCode[1] and supports visual programming via VisualScript[2]. Also they work on support for Vulkan (Godot 4.0) for high perf graphic.

1: https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg/vid...

2: https://www.youtube.com/watch?v=WW8CJQ8jMBM

I can't compare it to Dreams as I don't own that one but as performance goes it's certainly no Unreal Engine but you can do impressive things with it without too much effort.

I did a VR game in Godot [1] which was my first ever VR game and my firt Godot game and it turned out pretty OK without too much friction

[1] https://www.vrworkout.at

Reply on news.ycombinator.com