Let's learn Godot together

[MorpheusKitami]

Ah, yes, there's nothing sketchy about the game engine made by a group of people with documented ties to the Chinese government./s

In seriousness, is there an engine that isn't sketchy in some way these days? Unity just tried to screw over developers horribly, which is an absolutely terrible sign for its future. The only other ones I can think of are based off iD FPS games in some way, (Doom, Quake, Cube/Sauerbraten IIRC) all of which have varying levels of sketchiness and require a lot of effort to do something beyond a FPS and maybe an adventure game. There's also Engine 001 or whatever its called these days, but that engine is such a shitshow that the one game off it that got any attention is basically unplayable.

[Mogri]

Has anybody managed to make a playable game in Godot yet? If your computer can run Godot 4 then it can probably run Unreal, so why bother? The people behind Godot are beyond sketchy and the code base is a giant bug.

I haven't heard anything sketchy (which obviously doesn't mean you're wrong), and I haven't noticed any major bugs. The great news is that if the Godot maintainers ever do something evil, you can always create your own non-evil fork of Godot.

To me, the advantages of Godot over UE4 (and, to some extent, Unity):

• FOSS means the terms of service can't change on you. You own your game completely. Unity has shown that this is an ever-present threat, even if it doesn't rear its head often.
• But even if it never does, Godot is free to use.
• I've heard UE4 and Unity do 2D poorly. I've been happy with both 2D and 3D in Godot.
• In particular, if you want a retro look, Godot lets you create a game at 1x resolution and then linear-scale everything at display time. It's impossible to overemphasize how much of a godsend this is, since it's very difficult to prevent pixel-shift even before you consider fonts and stuff.
• Maybe this is true of other engines, too, but Godot has a lot of community examples that are helpful in figuring out what you're doing. The documentation has been good as well, though I'd expect UE4 and Unity to have better documentation, if anything.
• Over Unity in particular, Godot has the advantage that the maintainers are using it to make games. Obviously, this is also true of UE4, though.

I don't have a particular horse in the race here. UE4 is clearly an excellent engine, and if it's a better fit for the game you want to make, then you should use it. Godot seems like a good option for indie developers, and I've played enough games made in Godot that it caught my attention.

---

While I still have lots of ideas for the dungeon crawler bouncing around, I have a smaller project that I'd like to try, tentatively titled "Overly Complicated Spaceships." The idea is that you're piloting a spaceship whose controls are incredibly obtuse. Need to fire your laser? Pull on the chain to open the weapons panel, disable all of the safety switches, turn the flywheel to power up the laser (but don't turn it too much!), and then use the laser pump to fire. While you're doing all this, you have to make sure the reactor temperature stays within the appropriate range, or the ship will power off or blow up.

Toss in a few different ships and a dozen or so missions, and you've got a nice budget title.

[lennyhome]

I haven't heard anything sketchy and I haven't noticed any major bugs.

I really don't want to argue because I don't have any stakes anywhere either.

I just wanted to say that since my computer can't run neither Unreal, Unity or Godot 4, my only option for 3D is UPBGE. If you choose version 0.3 you have the option of designing the game logic with nodes instead of Python code like in Unreal, but I still prefer version 0.2 because the old rendering system is faster. If you're looking for community support and a list of games made in UPBGE you can look here (youtube) and here (blender artists forum).

Sauerbraten is not so great as a game engine because although it's scriptable, it's not very cutomizable. Over the years there have been some of attempts to put RPG logic into it, but it didn't work out. However, it's a great modeling tool because you can edit your scenarios in game, export them .obj files and re-load them anywhere else. It's by far the easiest way to make 3D maps. You should get it and get familiar with it no matter what.

[Bob the Hamster]

I heard one of the OHRRPGCE devs has ties to the government of the Hamster Republic. Cheek pouches completely full of sketchiness

The obtuse spaceship game sounds like a fun idea!

Did you ever play that game where you are a bear trying to drive a stolen car? Those are the vibes I am imagining

[lennyhome]

So it would be like a woman simulator but it's a spaceship.

[Mogri]

Did you ever play that game where you are a bear trying to drive a stolen car? Those are the vibes I am imagining

Oh, I think I remember seeing that in a GDQ! Great concept.

So it would be like a woman simulator but it's a spaceship.

Even giving you the benefit of the doubt, this is bordering on misogynistic.

[lennyhome]

this is bordering on misogynistic.

No, it's not. You're just upset because I called out what you had in mind. Lately with AI everybody is trying to do exactly those kinds of fuzzy controls that have been under research since the 80s and never worked.

[Spoonweaver]

I heard one of the OHRRPGCE devs has ties to the government of the Hamster Republic. Cheek pouches completely full of sketchiness

The obtuse spaceship game sounds like a fun idea!

Did you ever play that game where you are a bear trying to drive a stolen car? Those are the vibes I am imagining

Enviro-bear was great. Pinnacle indy gaming experience, imo.

[Mogri]

this is bordering on misogynistic.

No, it's not. You're just upset because I called out what you had in mind. Lately with AI everybody is trying to do exactly those kinds of fuzzy controls that have been under research since the 80s and never worked.

I honestly don't know if you were going for the hackish "women are complicated, amirite" or the problematic "women are bad drivers." How you think you called anything out is a mystery.

[Mogri]

Pull cord



This took way longer than I expected. I had two sticking points, each of which was extremely unintuitive and took ages to figure out:

Problem #1: Joints only care about the relative position of the two connected nodes at the time they're joined.

Repositioning a joint does nothing. My initial design was to put a joint at the top of the cord and a joint at the bottom, and the handle would dangle off the cord, easy-peasy. Nope! Because the rope's position never changes, the handle's position never updated. Of course, I could make the handle a fixture at the end of the cord, but then it would be unable to rotate independently.

The solution: Don't actually use a joint between the cord and the handle. Give the handle a StaticBody2D parent and connect the handle to the parent via a joint that does not need to move. Set the parent's location to the end of the cord on every frame when it's not being dragged. When it is being dragged, of course, you want to set the cord's angle and length to match the handle's position. But that led me to...

Problem #2: You can't just rotate a RigidBody2D.

Obviously. What kind of fool would just rotation = position.angle_to_point(destination) and expect that to persist? As soon as you stop setting rotation, the cord resets to its original rotation -- not whatever it was at before, but whatever it was set to in the editor.

This is a special property of RigidBody2D, which uses physics. Now, I could just use a StaticBody2D and apply my own physics, but that would be a lot of work just to get the functionality Godot is supposed to provide natively with RigidBody2D.

The solution: The rotation property comes from Node2D. RigidBody2D has its own internal physics state, and that holds its own rotation, among other things. To access it, we need to override _integrate_forces.

Code: Select all

func _integrate_forces(state: PhysicsDirectBodyState2D):
	if gravity_scale == 0:
		var old_origin = state.transform.origin
		state.transform.origin = Vector2.ZERO
		state.transform = state.transform.rotated(set_rotation - state.transform.get_rotation())
		state.angular_velocity = 0
		state.transform.origin = old_origin

"Hang on," you say. "What's the transform origin before you set it to zero?" It's weirdly 25% of the length of the cord. Again, it was not at all obvious that it would be something else, so I was stumped for a good half hour when the cord would gyrate at impossible speeds when it was being pulled.

What about gravity_scale? That's how I'm tracking whether the cord is being pulled. When we pull on the cord, we suspend gravity to prevent the cord from receiving outside forces.

--

Anyway, I'm super pleased with the result, even if I'm far less pleased with the process that got me there. The waggling handle will be extra fun when you're desperately scrambling to perform precision operations In Space. The graphics need some work, but that's a concern for another day.

[kylekrack]

Oh hey, cool. Haven't logged on here in a while, apparently. I've for the most part switched to using Godot the past year. Not because I don't also like the ohr, but it's just hard to work on two projects at once.

That being said, I livestream on Twitch basically every week, barring holidays and getting sick, working on a game in Godot. One of my main goals with streams is collective learning and being a sounding board for those trying to learn Godot or game dev in general. At the very least, people might learn from my mistakes instead of having to struggle alone. Stop on by if you ever want to chat about the engine or have a question. I may not have an answer, but I'm always happy to stop what I'm doing and try and find the answer together.
https://www.twitch.tv/onehundredthousand

Cool stuff with the joint objects. I've played around with them a little bit, in a way that can only be described as unwise. They're definitely a time sink to get working in the way you want. Your pull cord looks great.

[shakeyair]

I also haven't been on here in a long time and primarily work in Godot now. I put out one Ludum Dare Compo game using it: https://tattomoosa.itch.io/the-acolyte

I think one of the raddest aspects of Godot is that the Godot editor is just a Godot application, so you can do really cool things really easily with custom editor tools. For example an in-game character creation tool could be tossed in an editor inspector plugin and you could use the exact same tool to make NPCs very easily. And it's theme system means the same controls can easily look game-y in-game and like the editor in-editor but still be the same logic underneath.

I have a lot of experience with custom editor tools in Unity (I used to sell some on the Asset store) and after trying some similar things in Godot, Unity's way of having a totally separate editor and game UI/logic setup seems completely backwards. I think this is one of the reasons Godot has a decent number of released applications using the engine too, it's very versatile

I'm actually currently working on a built-in pixel editing tool addon with palette management/remapping/etc for Godot - because I really miss both the built-in sprite editing and the restricted palette I got used to from the OHRRPGCE. It's just gotten past the super fun proof-of-concept phase into the "oh no i'd have to build like every single feature someone would expect" phase so we'll see if I can power through that haha

Godot isn't a perfect engine but it's as close as anything else I've tried and moving even closer as far as I'm concerned. Open source, easy language with optional typing, generally very consistent design philosophy, and easy to work with pixels (!). Also, all the things on my wishlist are also either planned or at least in discussion: traits, namespaces, generic types