Stop Waiting for Godot | Hacker News Reader

Stop Waiting for Godot

itch.io

363 pointspolm23127 comments

The post title was a tad misleading - I got the impression that it was saying that Godot isn't ready and we shouldn't wait for it to become ready. I suppose it got my attention by being like that, and that was the point. Maybe it'd've been better as "Stop Waiting for Godot - Game Jam".

Happy to see Terry Cavanagh is trying Godot. I love Super Hexagon and VVVVVV, and am planning to play Dicey Dungeons in the future. Looking forward to see what he makes.

The title refers to the play "Waiting for Godot" by Samuel Beckett. The phrase, "waiting for godot," has come to mean a situation where people are waiting for something to happen, but that particular thing will likely never happen.

So, in the title here, the phrase is used as a double entendre in a discussion about no longer putting off learning about an application that is also named Godot. That's my read, anyway.

All of that is correct for sure, but there is also the aspect of waiting for version 4.0 in the godot community. While Version 3.3 is really good already, 4.0 is supposed to be even better and the aspect of waiting for 4.0 to start a new project is a recurring theme in the godot community.

Godot was named after "Waiting for Godot" to start with! The word "Godot" doesn't mean anything else.

I heard of a famous prosecutor also named Godot.

But readers like WillDaSilva may not have heard of the play but have heard of the game engine, and might instead assume that the title refers to "waiting for Godot [...to be mature/ready for developer attention]".

And then they might read the article

We've come full circle. WillDaSilva remarks about their confusion based on the title after having read the article.

I've used Unreal and for some things, GameMaker Studio. Never have I used Godot. Would you recommend Godot over Unreal or GM2?

Yup, unless the game absolutely needs to be running in the Unreal Engine, or absolutely needs to be made out of stuff from the Unity asset store :)

I think if there's any ambiguity about what might be best, and asking 'what engine' is actually a question at all, then Godot is probably the answer. If it's not really a question because you already know you require certain kinds of rendering or asset store dependency/workflow, then you've probably already settled on the engine that optimizes for those needs… but if it's more of a negotiation among competing needs, Godot rapidly becomes relevant.

Thank you. That is very helpful.

I can only recommend Godot. It's easy to pick up and feels like a consistent and fresh take on a game engine. For Unreal especially, for me, it felt like it would always come to the point where Unreal magic is needed to fix a certain problem. With Godot I've never had this feeling, the things you set out to do just work the way you expect them to. Overall you get the feeling that the engine distills the best gamedev ideas of the last 10 years into one nice package and I couldn't ask for more.

I tried to get into it a little, but it feels like you end up in the deep end quickly and it's hard for me to make sense of how you hook things up.

I get that there's some message passing thing going on but I don't really quite get how the objects all bind to each other or where you put your logic for controlling things.

A scene seems like an interesting primitive, it's just hard for me to make sense of how to organize things into it and the tutorial basically just says add all the things you want to see on the screen into your scene and don't worry too much about wiring things up.

But I sort of feel like I don't have a real model of how things interact in Godot to make sense of what they're doing yet.

How do you find the tools? I feel like these kinds of systems live and die by what the tools offer you in terms of features, ergonomics, extensibility, etc.

What about the actual output? Are 3D games written in Godot comparable in performance to commercial products?

If you're looking for a good 3D engine that is open source there's https://o3de.org/ which is now part of the Linux Foundation and based off of Amazon's Lumberyard game engine

The remake of Sega's Sonic Colors was apparently created with Godot.

That question cannot be answered in a meaningful way unless we know your skill profile and use case.

A qualified comparison is "Gamefromscratch: Choosing A Game Engine in 2021" <https://www.youtube.com/watch?v=rK6ulQaOpso>

If you need Unreal for your game, I wouldn’t recommend Godot. If you would use basically anything else, try Godot.

For 2D specifically, if you feel at home with GM and are already productive, stick with it. Otherwise, do try it out as it's incredibly good and the learning curve is not steep. For 3D, stick with Unreal.

Thank you.

Ah cool. And apparently that play it where Godot got its name from. TIL. Excerpt from Wikipedia:

> Linietsky stated in a presentation that the name "Godot" was chosen due to its relation to Samuel Beckett's play Waiting for Godot, as it represents the never-ending wish of adding new features in the engine, which would get it closer to an exhaustive product, but never will.

Thank you for that. I didn't know that's where the app got its name - though, the play and the app are the only two things I am aware are named Godot!

I invite you to read it. It is short and quiet absurd. One my favorite plays.

I remember the actual play being excruciating, over three hours long, but I believe that written down it's rather short. It's often just waiting, with long pauses and empty stares.

Uh, it’s not. I suppose people can produce a given play however they wish but I don’t think three hours is typical…

Web searches suggest 2.5–3 hours is typical, both for stage productions and film adaptations.

A 2021 Broadway production was 3 hours long. A 2013 Broadway production was 2.5 hours (including intermission). I couldn't find any shorter examples.

Some of Beckett’s other plays are much shorter.

Ah? It should last around 2 hours, usually (like to what your 2.5 hours with interval comes down). I don't remember anyone complaining about the length when we went to see it in high-school; which speaks for itself, I guess, eh :-). The French performances (which are relevant since it was written in French) I can find last between 1h45 and 2h10. Perhaps in the US, like for TV programs, they inserted a total of 45 minutes of commercial breaks ;-)

Plays usually have a ~15m intermission.

This gives a new spin/explains the tagline on their website as well:

"The game engine you waited for."

Has anyone tried to port Godot to Solaris on SPARC?

Then you could listen to this tune while waiting for it to compile Godot and tell you what went wrong:

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

My H.S. English teacher taught the class that the "Waiting for Godot" title could well be interpreted as "Waiting for God". And that includes exactly what you say: a situation where people are waiting for something to happen, but that particular thing will likely never happen.

Thanks for the explanation. I’ve never heard of the play or the phrase, so I thought exactly the same thing as OP. Now the title makes more sense, though it does require insider knowledge.

I think the insider knowledge doesn't really help that much. In the play, he never shows up. So even with the knowledge of where the name comes from, a valid interpretation would be that people waiting for Godot to be ready are wasting their time and should go do something else.

Why did you have that interpretation instead of "You might not think Godot is ready, but it is, so you should stop waiting and start using it"?

Good question. Not sure. Maybe my mindset is too negative in general. Maybe I was prompted to take a negative stance towards it because of the use of the word "stop", as in "Stop Waiting for Godot" as opposed to "Start Using Godot".

I thought the same thing. Poor choice of words

It's an excellent title for a post but not everyone is familiar with Samuel Beckett's 'Waiting for Godot'. Terry is Irish and I certainly like the homage.

I'm familiar with the play on words but i still interpreted it like that because the whole point is that godot never comes (will never be ready for prime time in this analogy).

A more fun play on words in my mind would be 'the wait for godot is over' or 'godot has finally arrived' but i understand how that wouldnt be as true to the spirit of the play

I don't think the analogy breaks down at the "never comes" part. I think that's fine. I know I have a list of future projects I want to get to, many of which I never will. Someone might have a similar list with "Learn Godot" on it. The title of the post is basically saying "Do it now, don't wait forever".

The analogy breaks down at where the control lies. In the play, the characters waiting have no control over when Godot arrives. So they're waiting on an external entity. With this article, the waiting is procrastination and the arrival is fully in control of the person doing the waiting.

I feel like he came up with a very clever post title first and then had to write a post to go with it.

> It's an excellent title for a post

But perhaps not this post.

I have a friend who's been trying to go all-in on Godot but decided recently to switch over to something else, largely due to ongoing issues with its lighting system. When toying with it, he encountered poor lighting overall and some particularly counterintuitive behavior with the (rather simplistic) lighting system.

For example, a simple scene with a wall intersecting the floor and a light placed on one side. In this scenario, you get weird light spilling around the edge onto the vertex where the wall meets the ground (see [0] and [1]). There's also poor handling of multiple light sources; if you cast a shadow and place a light directly on top of the shadow area, it's impossible to displace the shadow (see [2]). These sorts of things are very noticeable, and part of the recent work that they've just released was supposed to address this. However, these examples came from the most recent release, which made my friend begin considering other options with more robust lighting.

[0] https://imgur.com/rsxjV5u [1] https://imgur.com/kOzKQnL [2] https://imgur.com/NH9ZViP

Yeah, the light system is problematic, and I believe pancaking is a real problem for shadows for instance. Carinou mentions some work arounds in the subreddit.

Godot 4 should see a lot better results.

> Carinou mentions some work arounds in the subreddit.

I can't find it, do you have a link?

https://www.reddit.com/r/godot/comments/9p0adp/could_shadows...

https://www.reddit.com/r/godot/comments/p9hl5y/directional_l...

https://www.reddit.com/r/godot/comments/oa75ej/shadows_in_3d...

Last link is the one I read, but the others might help you as well. It’s Calinou btw, always write his name wrong.

How is Godot4 going to improve this?

Probably by dropping support for older OpenGL versions and pushing for Vulkan on as many platforms as possible. The extra performance overhead will enable all the fancy effects you're probably thinking about, like bloom, accurate AO, subsurface scattering and screen-space reflection.

Ah ok. I thought that the techniques of dealing with shadow issues aren't always requiring new API capabilities, so it seemed strange that something would be blocked on Vulkan.

I've recently checked out Godot and it turned out to be easier than I expected. I followed this series of tutorials [0] (I found it most palatable at 2x speed, occasionally going to 1x for critical parts).

Took me about an hour altogether to get pretty productive at making a non-trivial game. The engine is cool and takes care of a lot of routine things, like physics, collisions, and organizing things hierarchically.

[0] https://www.youtube.com/watch?v=HvPTSZl2WCc

I have never, ever even worked on the visual design or coding of a 2D/3D video game in my life. I tried out Godot a few weeks ago, and even for an idiot like me it was pretty easy to get into, understand, and start doing things with. I was pretty impressed, to the point where I was wondering if I could even make my own little indy game.

Me too, I had zero gamedev experience but found the documentation really good and the tooling and data model pretty accessible!

I didn't like GDScript - even with the bolted-on type checker it felt way too loosey-goosey[1]. But I had the feeling gamedev is just a bit different from other software eng so it's worth being open-minded about these things (plus you can always use other languages once you've got a grip on the core systems).

[1]Mainly because a) signals remain stringly-typed, and they are really important, b) you can't enforce type checking (it's just a hint in the IDE) and c) I couldn't get my whole codebase 100% type checked.*

I also felt the same about GDscript. There are ways to use c++ directly instead of GDscript, but most beginner tutorials seems not to be covering that.

You can always use C# through Mono

Would love to see Godot become the Blender of game engines: a genuinely professional-grade tool despite being free and open-source

Unity, its closest peer, is a piece of crap in a lot of ways. But it's a piece of crap that has a lot of important features. I look forward to the day nobody ever has to reach for Unity again.

I feel like i share your positive view of Godot, yet i'm afraid that it might take somewhere close to a decade for it to become a viable alternative to Unity, since a lot of engineering effort has gone into it.

Currently, in comparison to Godot, Unity is better in regards to:

  - C# as a first class citizen, really good performance, especially with DOTS
  - extremely wide platform support, especially in regards to consoles
  - many optimizations and functionality such as occlusion culling and LODs out of the box
  - modern render pipelines that are geared towards lower end devices (URP), while others that are suited for more visually stunning projects (HDRP and i'd argue that also the default pipeline)
  - a huge amount of tutorials, articles and examples of how to do something
  - the biggest asset store of any game engine out there, providing everything from AI plugins, character controllers, inventory systems, real time occlusion culling solutions, billboarding solutions, model LOD generation solutions, dialogue systems and anything else that you could think of, really; it's an excellent source for throwing together prototypes and yoinking a few ideas of other developers after looking at their code
  - really big share of the market is taken up by Unity, so professionally it makes sense to use it and learn it
  - this also means that most of the external tools that one might want to use also integrate really well with Unity

However, Unity is also a lot worse in other aspects:

  - there is no networking solution that's actively supported
  - DOTS and URP/HDRP were both haphazardly thrown together and feel broken
  - frankly, in the past 3-5 years, it seems like Unity doesn't know what it wants to be and as a consequence feels inconsistent
  - the closed source nature of it is also a pretty big problem for many projects

Who knows where the industry will be in 10 years, but personally i hope that Godot succeeds where jMonkeyEngine, Xenko/Stride, NeoAxis and many others have failed.

> C# as a first class citizen, really good performance

I've been doing C# since .Net 1.0, have netcore contributions, and have to conclude that this is "pro" extremely subjective.

- Unity forces you to use ugly non-idiomatic C#.

- GScript is a language built for game engine scripting. It has deep knowledge of game concepts, as well as the scene graph.

- Rust/other via GDNative are just as good as DOTS.

- There is a GD build with first-class C#.

> - Unity forces you to use ugly non-idiomatic C#.

Can you elaborate on this?

E.g. their own API https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h....

Idiomatic C# is PascalCase public members. Look at the BCL. Yes, the capitalization of fields in Unity determines the flavor of property, buy that's exactly what attributes were designed to do.

If you want good C# support, Stride is on NET5 right now, with NET6 as a PR in review.

disclaimer: I wrote the NET6 PR.

> GDScript is a language built for game engine scripting. It has deep knowledge of game concepts, as well as the scene graph.

Agreed, however it also being purpose built not only makes it so that your skills will be non transferable, but also that learning resources for it will be more limited in comparison as will code libraries.

For example, last i checked the language also has some interesting restrictions, like no Singleton design pattern for example; that alone makes managing global background services in games harder. Edit: seems like you can sort of have Singletons now, though having some that are completely separate from the scene graph would be even better: https://docs.godotengine.org/en/stable/getting_started/step_...

There are some really lovely people making plugins for Godot as we speak (the terrain one is especially cool), however it will take years for an ecosystem to be built around Godot. Historically, it has worked out for some languages nicely, like Lua, but less so for others, like ActionScript. For some people a purpose built language is a boon, for others it's a drawback.

> There is a GD build with first-class C#

I think our definitions of "first class" differ. In Unity, you don't use anything else apart from C# and even when there also was Boo or their version of ECMAScript, C# got a really large amount of love in regards to documentation, examples and tutorials.

Since C# support is so new in Godot, that's not exactly the case and for example, as of now i cannot yet open a project in JetBrains Rider and get information about which API methods are slow and should be used with caution, or common code suggestions like i can for Unity.

Now, personally i believe that C# being supported is a good thing and even Godot having separate builds for versions with/without is an idea that makes sense, but there's still a lot of refinement to be had before it is truly usable enough so that you can breeze through projects with it and be sure that both your code will be performant enough (without having to go down to a lower level) and that you won't hit snags along the way.

The efforts of Unity to have their .NET workflow be smooth and comfortable cannot be praised enough - if they gave as much attention and consideration to the actual editor and plugin ecosystem (as opposed to deprecating features with no replacement, or releasing features before they're stable), they'd really be in a stable spot!

Oh, and you can also look at Xenko/Stride engine to see what another engine that uses C# and has had a bit more attention given to it looks like (even though the engine itself is somewhat half baked and doesn't have terrain support out of the box, much like Godot).

That said, i'm sure that the situation will only improve in the coming years!

But you need to remember that it's only been three years since you could use the latest C# version in Unity. Before that change you were stuck with an absymally old NET runtime (Mono from 2011) that only supported C# 3 (with a few C# 4/5 features), and had an incredibly bad garbage collector (Boehm stop-the-world GC) that would cause lots of headaches. Lots of good stuff like LINQ was discouraged in Unity because of the GC issues, and Unity C# was quite different from "normal" C# (with all its hacks and workarounds). The ancient Mono runtime was all because of licensing issues with Novell/Xamarin (Novell developed the Mono runtime until it got bought by Xamarin) - Xamarin probably asked for an enormous sum for the relicensing, and Unity refused it, resulting in Unity unable to update Mono for 6 years.

If Microsoft hadn't bought Xamarin and rereleased Mono with a more permissive license than AGPL (so that Unity can finally update their Mono runtime), then Unity would have really met its downfall. If this (stealth) partnership between Microsoft and Unity didn't happen, I expect a lot of developers to have already moved on to Unreal/Godot in much faster rates.

GDScript is good enough for what it does, especially as an introductory language for people who have not done game development before.

Personally I found that the choice of programming language mattered much less than I thought they would, since I spent most of my time and effort on drawing rather than coding.

I say this as someone who hasn't had time to play around with Godot for the last 9 months, so take it with a grain of salt, but Godot's C# support was coming along great and I had switched over to it exclusively before work pulled me away. Has it fallen off and not improved? It was just as fast (if not faster than) native GDscript.

Unity has two NetCode stacks that are in full development with large resources behind them. One for regular GameObject-land and the other for DOTS. I have a very large budget for two games using the latter, and it’s been rock solid.

Unity taught me how to program, and even today it's just the easiest way to get something done fast.

For example if I want to build a platformer, with tons of special effects, I can do this in about 2 days with Unity.

The asset store itself is Unity's biggest advantage. Want to make a game about finding Easter eggs in the woods, buy Gaia and you have your forest.

From a technical point of view , Unity is amazing. My one concern is the business seems to want to extract more and more from users. You went from being able to buy Unity to needing to subscribe, and subscribe to a bunch of other auxiliary services.

That said, C# is C# so your skills are easily transferable. I'd love to see another commerical C# driven option.

I'm not a big fan of how Godot tries to support 3 or 4 programing languages. This fractures your userbase and makes finding tutorials much harder. Although I will admit my very first programing language was Unity's JavaScript implementation.

It might have been true about Unity some 5 years ago, but during last couple of years Unity has been improved significantly.

Isn't it still in deprecation hell? Do they even have a recommended proper own network solution?

Everytime I use unreal I'm blown away by how smooth it is (as long as I find what I'm looking for in their insanely huge toolbox), unity meanwhile just feels like constant roadwork.

What I hear from people who use it professionally is that it's constantly having features get deprecated, sometimes before they have a full replacement, that it constantly crashes and has various undocumented SDK behaviors (which sometimes change without warning), etc

Over the last five years it went from "not a professional game engine" to "a professional game engine". That doesn't mean it's a good one.

Hm, I've been trying to learn godot, but I kinda keep hitting walls I'm not sure how to navigate. I pretty much get the idea, for a simple platformer, you'd build your enemies, players and level elements as scenes, and then you use godot as a level editor to build your level, instantiating these scenes.

However, I'm seriously struggling to think some different scenarios. For example, how to structure the application in order to have some procedurally generated contents for a level and how to add that into the godot structure.

Or, another thing was I had some situations where it feels like I need to parametrize a packed scene with some other instances of a packed scene. Think of a toolbox filled with tools, which are again instances of other packed scenes. That grew into a really weird monster pushing paths of instances around, but became very unwieldy quickly.

At that point I'm confused if I have a mental block because I'm thinking incorrectly about the problem, or if godot is not a good fit for stuff like that, or if there is a great way to structure this in godot.

Dunno. Somewhat rambling, but maybe someone has some pointers there.

This guy has some fantastic videos on architecture in Godot. It takes a little more work to go from simple->complex, like using the event system properly, global scripts, etc

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

I recommend anyone interested in Godot watch and preferably follow along with this one - I went through it over a week and so many things in Godot made much more sense at the end.

Plus the pattern for referencing child nodes as NodePath exports and just setting them from the editor, rather than hard-coding (and recoding) resource paths, makes UI design much much easier:

    export(NodePath) onready var Header = get_node(Header) as RichTextLabel

Also HeartBeast's action rpg tutorial is a must[0]

[0]https://www.youtube.com/watch?v=mAbG8Oi-SvQ&list=PL9FzW-m48f...

You can make every scene self contained, or have it communicate in a framework (could be signals, could be calling from a scene)

You can store data anyway you like, so content can be a file, can be in a database, can be through a c++ extension.

Creating a game is often mostly about these choices I found. Whatever engine or language you are using. Maybe Godot just gets you faster to the point where you think about them?

SimulaVR (www.simulavr.com -- Linux VR Desktop ported to a portable VR headset) is built over Godot. We've ran through some bugs during the development process, but being able to alter the game engine's code on the fly has been really nice.

This is very inspiring, really scratches an itch I have to build 3D text enviroments - I'll be very interested to see if I can take advantage of your text rendering code. I haven't done any 3D yet save for some very tortured HTML/CSS, and have had some decision paralysis about whether to learn nitty gritty of shaders, or the bloat of unity, or some 3D engine in between. SimulaVR is making a strong case for Godot for me now.

looks legit.

There’s also an interface to use OpenAI Gym environments in Godot.

https://github.com/lupoglaz/GodotAIGym

I have succeeded in modifying the interface to send images to a version of Google’s DreamerV2 RL learner. I have a simple test environment I could publish.

But I stalled because I kept getting a segmentation fault and I wasn’t up for debugging it. I have enough plumbing that it begins testing and makes it at most a few thousand cycles but this segfault eventually comes up.

I think it would be very cool to be able to make a game in Godot and then train an agent to play it using DreamerV2 or similar. I’ve still not posted my sample files but if someone responds here saying they would like to see it, I will try to push it all to GitHub.

oh please do! I've tried using GodotAIGym myself, but it was a bit too complicated to make it work, and I was getting non-trivial errors too (in fact last commit on the repo is a small pull request from me).

I'd love a way to make Pytorch work in Godot. I see a lot of future in videogames like that, and it's also just plain fun to simulate RL agents. I'm reminded of the Primer youtube channel [1]

[1] https://www.youtube.com/channel/UCKzJFdi57J53Vr_BkTfN3uQ

what license would you use if you pushed it?

CC0, MIT, or Apache, unless I find that used some code that requires something else.

Sounds good! I'd like to check it out but I don't know if I can make immediate use of it!

Alright! I’ll see about cleaning it all up. Might take some time. If your Twitter in your profile is active I can let you know there when I’ve got it posted.

Yep, DM's are open too!

I like the enthusiam godot is generating in kids or people new to complex programming environments. You can see the energy in the chatrooms, forums and subreddit. Really creative stuff from the younger crowd showing the tool is getting out of the way allowing them to express what they want quicker.

Also suprising to me was seeing an app like Pixelorama built on top of godot. The fact they chose it over .net, java, gtk etc is pretty cool.

The UI system in godot is pretty nice. The binaries are also 30mb, which is pretty light everything considered.

I thought this was a reference to Godot 4. It’s been in development for a while but the latest stable is still 3.3.3

Cool!

An alternative OSS 3D engine is Open 3D Engine (O3DE), more here: https://o3de.org/

This is a new Linux Foundation project. (Full disclosure: I work for the LF, though I don't have any connection to O3DE.)

Truly wholesome hackathon invitation. Glad to see it got so much traction already.

Hoping this is what will make me really dive deep into Godot and game development in general

For some reason, my brain has a hard time translating my ideas to scenes and nodes

It's been a loooong time since I last used godot. Did they get vulkan support in?

Vulkan-support is one of the main features on Godot 4.0 which is still not in alpha. But from what I've gathered alpha-release is pretty close. But no date announced.

I remember reading about Godot but think it didn't work in my scenario which is: HTML5 Mobile compatible(in webbrowsers such as mobile Safari) Web sockets for communications (such as socket.io or signalr)

Anyone knows if this is still the case? There seems to be a lot off stuff that you get off the shelf with Godot which I have to resort doing myself now, using Pixi.js

They've got a web editor (wasm-compiled version of the actual editor) that can edit and run game files, so I assume that they do have HTML5 export: https://editor.godotengine.org/releases/latest/ But maybe you found that mobile Safari is missing a feature that is required?

And it looks like they're making good progress on interop with JS/web code so the socket.io stuff should be possible now/soon: https://godotengine.org/article/godot-web-progress-report-9

HTML5 export works, even WebXR, Haven't tried websocket yet but I am pretty sure it works as well.

I am working with Phaser 3 for my first 2D game, but I am looking forward learning Godot during this jam. This is probably why it's so hard for me to deliver something :)

How is your Phaser experience so far? I like how intuitive it feels, but the fact that it uses the same javascript I use at work makes it a huge turn-off for me.

I feel clickbaited here. I was fully expecting some weird 'Waiting for Godot'/Beckettverse itch.io game. That said, maybe I'll join the jam!

…and make that very game you expected! :)

Would love an open source godot-based board game emulator.

Be the change you want to see, buddy. :]

Hey Terry, love Dicey Dungeons :) I think Godot is okay for simple things but GDScript ruins the whole engine for me. It's not a real language (which is antithetical to the whole idea of shared open source standards), you can't do things that matter with it, but you certainly have to waste time learning the syntax and trying.

You can use C# instead. And I don't even know what you mean by saying GDScript "isn't a real language".

I know you can use C#: I have used C# and C++ in my Godot projects. However, other languages are not first class citizens in Godot. When I say GDScript isn't a real language people may interpret that as me being hostile towards Godot. In reality I'm just frustrated because I think the Godot editor is nice, but it's not capable of creating the types of games I want to play. GDScript is not used outside of Godot, and therefore it complicates the task of developing a shared commons of open source editor tools. For me, a criteria of open source is that it works with all toolsets, not just derivatives of a specific environment.

Sorry if this is a bit cynical, but isn't the general idea that game engines are pushing towards that you need to code less not more?

I've been writing VRWorkout in GDScript for a bit over 1 1/2 years so far and there haven't been any major roadblocks.

I agree that game engines should empower everyone to create more and better content with less effort. However, I don't think that a game engine specific scripting language is the best approach. For simple games that are similar to other games, GDScript is tolerable... it's when you try to push the boundaries of what's possible in games that GDScript falls apart.

I don't think that most of the games that are made today particularly push the boundaries of an engine. Maybe with complex shaders, but that's a different language anyways.

Godot sure has some ways to go, but since it has been compared to Blender in another comment. Blender from 15 years ago is quite different from what is now and they still managed to create something like Elephants Dream with it.

Or look at Sonic Colors: Ultimate that is relasing next week. That's also made with Godot. Granted it's probably a heavily modified version, but that's exactly what's so good about it.

I love Terry's games and I always wanted to try and learn Godot. I'm in!

I like Godot and have been using it lately to make simple Oculus Quest games. Does anyone know if you can release a Godot game on the Quest store? I know you can’t on the PlayStation store because of the open source license.

Does anybody know if this applies to the Oculus store?

There's some confusion here. Godot's licensing is permissive; the only licensing issue is that the console SDKs can't ship with the Godot editor out of the box. It can be hooked up to them, but you have to do it yourself. This is a problem, but not an insurmountable barrier.

Or you could pay for some third-party company to port your Godot game for you. There seems to be a few if you Google them.

Thanks, that's good to know. Would there be any issue like that with an Oculus SDK?

You can publish on any store, it's just that you need help with porting your game because the engine can't do so due to ~the licence~ idk. There are several companies that do this. Even the Sonic Colors uses a modified version of Godot.

Godot is MIT licensed. Are you saying that none of the games on the PlayStation store have even a single MIT/BSD/Apache licensed library in them?

No, I only know that certain open source licenses cause issues, which is why game developer contracts usually give you approval of 3rd party software.

The distinction you are bringing up between MIT and GPL licenses is an important one that I now know I need to understand better. Thanks.

Yeah, most likely the only "open source" stuff that's got legal issues there would be GPL stuff - a large set to be sure, but not the full umbrella of "open source".

GPL requires providing of game source files to end users. You can just publish your sources on a server, e.g. GitHub, and be done with that.

My understanding is that the licencing of the console SDKs and their associated NDAs is so restrictive that you're not allowed to publish source code using their APIs. Depending on the GPL version you may be able to get away with publishing the source minus the console-specific parts.

Why is this still the case? What is the advantage for console manufacturers to have restricted APIs which you need an NDA to access?

Console manufacturers don't want consoles to be usable for general-purpose computing (e.g. web servers and supercomputers), because they're selling at below commodity prices (as a loss-leader) and making them usable for G-P C would just cause everyone to buy them until they raised in price to commodity levels.

This has happened previously, with PS3's OtherOS feature, so it's a very real concern.

There are technicalities that make it a problem, because the copy coming directly from the game store might have restrictive license terms attached, even though the source and more is fully available elsewhere.

with GPL it very much matters which GPL, since v3 is explicitly about restricting that.

You can get your game on the PlayStation Store (http://www.lonewolftechnology.com/- I believe it's by one of the founders of Godot), or the Switch, although the company doesn't port to Oculus.

Yes you can https://quest.vrworkout.at

We aren't on the official store yet but are working on it

Thank you everyone for the helpful information. HN community is the best.

Check out https://o3de.org if you're interested in open source game engines

This engine is not relevant to almost anybody interested in Godot.

Its a fork of the Crytek's CryEngine so its quite large and designed for bigger development teams rather than small indie developers learning.

Its very work in progress, barely supports some platforms, and has less documentation.

Thanks!

I'll wait for it to mature a bit , but this seems like a worthy competitor to Unreal/Unity.

Lua support is exciting

Reply on news.ycombinator.com