Yeah, I am not a progammer (yet), but am getting ready to learn. But having looked at Godot, GameMaker Studio, and a few others, this seems pretty typical (that you have to create player input from scratch). For example, when I started to learn GameMaker Studio, I seriously thought that they would have a simple piece of code for pushing an object, an extension of their collision code or some such. Nope. Not at all. It's so basic and the basis for so many games. Instead, you had to do a lot of basic programming to get that simple function to even work. It was frustrating.

On the other hand, like you pointed out, you can create your code and save it to use whenever you like, making this a quick process for yourself. And because Godot allows you to attach code to objects/parts, you can easily create your code, attached to a part, save that part, and reuse as you please in any game. It's pretty easy to make a base player character, attach scripts to control it, and then use this as you base whenever you please, just swapping out the sprite or 3D model.

This is, for me, one of the things that attracted me to Godot over a system like GameMaker Studio ... and perhaps this goes back to my 3D GameStudio roots.

@All - I was going to ask if anyone had a good 3DGS test scene that includes the scene from a 3D modeler (I.g. 3dsmax or blender). I was going to convert it to godot and compare performance. I don't have a 3dgs key anymore and I don't know if I could make one before the trail expired.

However - I now think it's pointless! It's reasonable to assume Godot out performs A8. It's also reasonable to assume that Godot can out preform it even after using materials and features 3dgs dx9 doesn't have.

So I don't think Godot is the better engine out of unreal, and unity. But almost any newer engine is going to be better than A9 lol A8. And clearly every editor is better. I mean Wed-Med-Sed look like 2000-party over out of time!

I've not had the time to test Godot as I am currently involved in several projects, both work related and otherwise. Once I clear my plate a bit more, I plan to dive in.

Having said that, I would guess (and it is only a guess) that Godot would probably not perform as well as Unreal or Unity. But if that ends up being the case, I'm OK with that. Godot, for the most part, is a pretty well-rounded engine made for both 2D and 3D games. It's roots in 2D are very apparent, especially since v2 kind of had 3D as more of an "add-on" then a full feature. V3 changed that, though.

So, with Godot, we have a game creation tool to create most every game you could want ... and get it to just about any platform, too ... all for free. And if a part of Godot does not perform as it should? Well, it's open source. If you're a talented programmer, you could make improvements where you need. Neither Unreal nor Unity offer that ability.

Most of us are not going to create some massively online player game with zillions of polys for environments and characters. And if we are making things work in 3DGS, then we should have no issues with Godot's 3D. As you pointed out, the ceiling should be higher in Godot than 3DGS.

In any case, I am excited to find time to learn this engine. It looks like it has a lot to offer. And glTF support means I should be able to get more out of my 3D program and into Godot as simply as possible.

I'm slowly working through the Godot official tutorials (very slowly ... one must work, too, after all) and I am liking what I am seeing. I love their idea of a "node" based system. It just makes sense to me and it's something that's just a bit different than working in Unity or Unreal.

For example, you can nest nodes as children of other nodes and, thus, build your scene, your level, your world. Parents inherit from children. So, you could create a player node, create a weapon node, make the weapon a child of the player, and the player inherits the weapon's abilities, so to speak. You could also create your player node, create a wizard node (a node that has "wizard" abilities), create a warrior node, etc. Then you could easily create different players by making the wizard node a child of the player, or the warrior node the child of the player, etc.

I'm coming at this as someone who has extremely limited programming, and I am liking and beginning to understand Godot's programming. It's fun and makes sense. I like that I can work on one node, one thing at a time, save it, and bring it in as a child, an instance to my scene when needed. I like that I can open the node at any time, make changes, and those changes are passed to the instance in the main scene. It really helps to isolate issues and really helps with bug testing, too.

I can't wait to have more time with this engine and see if I can create something with it.

So, I've been testing Godot for a little bit now and I'm starting to really like it. It's super lightweight (i.e. an empty project actually feels "empty", without tons of crap generated around it by default) but still includes many of the important features and lets you easily extend most things with scripting to fit your needs.

As a downside, I'm not a huge fan of dynamic programming languages for game programming. I prefer something which is compiled and more explicit (not everything being a "var").
Their scripting language seems really polished, though and so far I've been getting around with it pretty nicely. Also, from what I know you can actually use c++ or c# for scripting, aswell. It's just not as convinient or easy to use.

In terms of performace I can't really say anything, yet. I haven't run into any issues so far. Then again, all the things that I tried weren't very complex.