Is Godot the engine for me?

LWurld

Hi everyone,

I wasn't sure which section to post this, since I'll want to show what project I am (was) currently working on with another game engine I'm sure you're all familiar with (Unity3D). It's a 2D game called "The Legend". Very retro and pixel-graphics based. Here is a link to the latest youtube video (a bit dated I've added some other stuff since):

A little bit about myself: I've been working on this project solo for over a year. I am both the artist and the coder. My full time job is programming for another company. Despite that, I enjoy art and animation the most.

Since it's almost every week I hit another limitation of Unity, it doesn't look like this project is getting any further along. After trying to get help from other game devs on IRC (followed by being ruthlessly mocked and harassed for it), I've since decided to shelf the project and give up this pursuit, even though it's been a lifelong dream for me and I've sunk so much time into it already.

HOWEVER, amidst the overwhelming condescending rudeness of the people on IRC, one of them suggested Godot, which is why I'm here. As a last meager effort to hold onto this dream, I'm here to ask whether or not anyone here thinks the Godot engine would help bring my project closer to completion?

I'll keep my eye on this thread and follow up on any discussion. :) I appreciate any feedback or suggestions you might have.

Rayek

I would say: a definite "yes". Your game reminds me of the good old Amiga times, and the animations look really good. The core advantage of Godot is its solid 2d mode - in my opinion much better than Unity. Godot's 2d mode rocks (pun intended ;-)

Looking at the quality of your animations and pixel art, as well as the interesting take on a music-playing main character, I'd say to you "Rock On", and ignore the nay-sayers at Unity's IRC. This is your passion, and the journey is worth it.

Have a look at Dolphin's Island source code at Github for inspiration. https://aldiansolkai.itch.io/dolphin-island-2

_807_

Why don´t you finish the actual proyect? Is bad idea in the middle of a proyect to switch entire code, levels, etc... if you are a "one team army" time is all, energy and time are at same time gold and enemies for one alone designer.

But your question:

Unity: best performance, best "addons", more platforms deploys, fast "bug" fixes.... more editor functionalities but worse editor concept (slow edit for me). DirectX.

Godot: Best editor for one alone designer but prepared to team work and git, all integrated: code, animation and level design. POO design. Code editor: Autocomplete, syntax highlight, functions, variables and constants suggestions for the actual class, autocomplete sugestion for members of singletons scripts... but you can´t close functions like in notepad++ to see code "trunked". Open Source. Portable. 32 and 64 bit editor, executable with no administrator privileges, no dependencies, no instalation, fast deploy and code but you don´t have prefabs, you need to code save system and files read/writing (have classes for this), you need to code your "platformer" mecanics (not dificcult and you are a coder!) but you have psysics to do that. Best 2D editor, easy to placement assets, easy to animate (there is not mesh animation for the moment), but lower performance at same number of render elements or number of objects that Unity. GDScript is fastest languaje to write that C#, but worst performance (not much more, but for intense computation there are bottleneck´s) OpenGL ----> executable in all kind of system, integrated card´s included, but performance diferences (some operating system or hardware stutters a bit, other no, etc.....)

In the actual state Unity wins in a lot of things, and I´m a Godot-Ultra. 3.0 promisses an audio daw with buses, best performance, scripting to integrate native code and libraries, C#, Visual Scripting, and a lot of features...

So: Godot is worst in all at the same time that is best in all :D :D :D . I don´t change Godot for Unity. My pendrive got 7zip, notepad++,GIMP, Inkscape, my loved Reaper and Godot... with this pendrive I can do a game, a song, a drawing... in every system around the world, don´t need more, only creativity and a loooooot of work.

I don´t like closed-invasive systems like Unity but If you are agree with this kind of invasion, no- portability, one computer license, one million of license comprobation, one million of minutes of charge things that are not part of your proyect and excesive dependencies of a opaque decisions in a closed opaque code..... there is Game Maker too... very very worst editor that Godot but you have a lot of performance with yoyo-compiler and all expensive export options (consoles included) and if your game is frame to frame pixel animation probably don´t need a lot of skeleton animations, 3d objects,etc...

Rukiri

@807 at least game maker has a proper tile editor...godot is the absolute worst in that regard... The only redeeming factor of godot right now is the nodes.

Schuster

Welcome LWurld, absolutely....Godot engine is amazing, and the community is cool and friendly ....your game looks great...good luck!

LWurld

Thanks for all the feedback, everyone! :smiley:

@Rayek said: I would say: a definite "yes". Your game reminds me of the good old Amiga times, and the animations look really good. The core advantage of Godot is its solid 2d mode - in my opinion much better than Unity. Godot's 2d mode rocks (pun intended ;-)

Thanks! My first computer was a Commodore Amiga 2000, and a lot of games from that system are my inspiration. :smile:

@807 said: Why don´t you finish the actual proyect? Is bad idea in the middle of a proyect to switch entire code, levels, etc... if you are a "one team army" time is all, energy and time are at same time gold and enemies for one alone designer.

You are correct that switching game engines is a very bad idea. Unfortunately, I've been hitting roadblock after roadblock with Unity, especially when it comes to coding. There's a lot of internal engine stuff that the Unity devs just don't let you have access to.

In my case, I need something that can import/export tile-based maps. Tiled has been my preferred application up to this point, but Unity doesn't support it, and the tools available are very limited (ex: no animated tiles, limited importing/exporting options, unavailable parameters, etc.,).

@Rukiri said: 807 at least game maker has a proper tile editor...godot is the absolute worst in that regard... The only redeeming factor of godot right now is the nodes.

The Tiled map import plugin for Godot worked perfectly for me and using a scene for a tilemap actually sounds kind of clever. How does Godot handle isometric or hex grids for tile-mapping? (I might need them for later ideas)

All that said, I've hit a wall with Godot. Continuous Collision Detection (CCD) - A very important feature for 2D platformer games (works in Unity) - is currently not working in Godot. This inevitably means that tunneling will occur in my game (ex: When the player jumps and lands, they sink about 4-5px into the ground initially). It'll definitely break stuff as I port it over. I've already hit problems with corners now.

I've been searching for a fix, but it's already reported on Github, and folks on IRC are telling me not to hold my breath. I've been searching for a plugin, a workaround, anything that fix it, and found nothing so far. I dug into the github commits too, and from the looks of things, it's not a very high priority issue. It might not even get fixed in 3.0.

So at the moment, I'm stuck once again. Godot can solve one problem that Unity can't, but unfortunately creates another. :disappointed:

whooshfrosted

If you have the money perhaps you can pay someone to add what you want to Godot? There's got to be a good programmer out there, who wants to earn some extra money. Would be nice if there was a mini kickstarter type website where small groups of people could pool their resources to hire a programmer to do smaller jobs.

Schuster

You can use RigidBody2D....mode=static....there is a Continuous Cd 1.CastRay or 2.Cast Shape....use it just like StaticBody in tiles where you have the collisions with player character ....or it doesn't work?

LWurld

@whooshfrosted said: If you have the money perhaps you can pay someone to add what you want to Godot? There's got to be a good programmer out there, who wants to earn some extra money. Would be nice if there was a mini kickstarter type website where small groups of people could pool their resources to hire a programmer to do smaller jobs.

If I had the money, (or if I at least knew this game could turn a profit), I'd totally be down for that. :lol:

@Bishop said: You can use RigidBody2D....mode=static....there is a Continuous Cd 1.CastRay or 2.Cast Shape....use it just like StaticBody in tiles where you have the collisions with player character ....or it doesn't work?

Hm... Setting the RigidBody2D node on each tile? I haven't tried it. I will next available chance I get. Won't that be a big hit to performance if there are a lot of tiles? They're 8x8 pixels each.

Schuster

I never tried it....I'm mainly 3D artist....I'm learning GDscript yet...but it is worth a try. .....maybe use it where it is most necessary. ....normally are used StaticBody2D for collisions on the tiles but only RigidBody2D have CCD.

Somnivore

@LWurld I'm in the same boat as you, I was using Unity for quite a long while but decided to switch over to Godot due to dissatisfaction with Unity. In my case I was angry there was no possibility for a developer to have non-scene functionality, everything you code in the game has to be a component which exists on a gameobject that exists in some scene somewhere (at least until it can be marked to not be destroyed when a new scene is loaded), which is great for stuff that should be a component but for things like singletons and non-scene-related data (what Unreal called the 'game layer'), it's workaround after workaround. "Want a new input manager because Unity's input manager is basic and blackboxed? Add this component in every scene you want it!" What?! Why would I want an input manager in one scene but not another, especially when the vanilla one is a scene-less singleton? Also yes, I do acknowledge the Unity community being rather awful, and a lot of my game dev friends have observed this as well. I suspect the act of developing games to deliver people to advertiser or to sell people virtual nothings has a major effect on their attitudes towards others; that is to say, much of Unity's community is made up of mobile developers.

Anyway: I'm sorry to say but Godot is not a magic solution to Unity. It has its snags much like any other engine, and I've been getting snagged a lot on various physics-related things (although much of everything else has been relatively smooth.) Thus far by using a KinematicBody2D for the player character I seem to have gotten a very smooth experience out of movement, not sure if that would still cause the sinking issue you're talking about, but I'm using high-resolution graphics so maybe it's just not noticeable on my end. In a similar vein, I had tried for a few days to get the 3D KinematicBody to work, and I'm convinced it's just broken. A lot of Godot is buggy. But it's open source software so the expectation is that someone should go in and fix it if they want it fixed; this is the price we pay for non-proprietary software, it's now everyone's responsibility to make Godot work. I'd rather just pay 50$ for Godot and let someone else take care of making Godot function right but alas: whether it's proprietary or open source, there's a price to pay for software. Luckily Godot does have some smart guys working on it, but the point remains, they can't do everything at once.

Godot is still a bit of a wild west. There are games which were developed with Godot but none of them have reached critical acclaim AFAIK, not in the same way that XNA/MonoGame has what with Fez, Bastion, Terraria, or Unreal with Bioshock Infinite, Final Fantasy VII remake, the Unreal Torunament series, or Unity who has Yooka-Laylee, Kerbal Space Program, and Ori and the Blind Forest. Godot has nothing on this level of acclaim, it has little to prove its worth. It's still young, it's not time-tested by tons of people, you're a trailblazer by using it. You should expect there to be problems with no obvious solution. If Unity and Unreal are big cities with huge recognizable skylines, Godot is a village out in a hilly, grassy area. You're going to have to jump over some hurdles to get Godot to work the way you expect, and there's some common sense quality of life stuff Godot ought to do but doesn't (its file manager is particularly awful, on the level of awfulness of Unity's input manager; just don't ever move anything once a dependency is formed and you'll probably be okay.) There's not a lot of community to fall back on, and not a lot of tutorials to learn from; Godot's documentation is OK, but it doesn't document everything, at worst you'll get a list of functions with no explanation as to how it all works (for example: animation trees. No documentation at all, just figure it out yourself.) If you can manage this, you'll be rewarded thusly:

Your engine will be completely open sourced, with no proprietary systems involved (unlike, for example, UE4, which has an open sourced engine but uses proprietary components like PhysX)
Your game will be yours: you won't need to pay for a license or pay royalties on your game
Your engine can run on all major desktop platforms (particularly useful if you're interested in Linux)
Your engine will be very lightweight and without any installation
You will have greater control over your game's hierarchy via Godot's node/scene system (particularly nice when you're fed up with Unity's way of doing scenes and prefabs)

LWurld

Thanks, @Somnivore.

That's disappointing to know that Godot doesn't handle asset references like Unity does. Unity's documentation suggests you should always work within the editor for managing assets, even moving them around is okay. But if Godot can't manage that, well... it definitely will lead to setbacks down the road.

It is pretty frustrating that with all these problems in Godot and Unity, people can make 2D platformers. To a degree, they're very cheaply put together, probably because to be a successful game dev, you have to make shortcuts and compromise the overall quality of your game. (no wonder there's so many bugs in new game releases)

@Somnivore said: What?! Why would I want an input manager in one scene but not another, especially when the vanilla one is a scene-less singleton?

This is probably where we differ. I don't use singletons. I try to avoid them where necessary. What's funny is I avoid them for reasons you've already described. You can't work "outside of a scene" in any of these engines (except UDK u say, which I have yet to try). Once a reference to the singleton is lost, Everything breaks. My method of testing (which remains quick and efficient imo) is to rely on static definitions -- after all, are you going to need more than 1 Input Manager? Probably not. And at least with static classes and functions, you will also be maintaining a reliable reference to your Input sources. (Even Unity's crappy Input manager)

Despite this, I've worked with other coders, and they prefer singletons, so I've put one in my root scene and play scene. But the expectation is that a reference must ALWAYS be checked first, and the scene can never be fully dependent on the singleton. When Unity loads a scene, it loads all the resources that are attached to that scene, so you almost never have to make use of that silly "/Resources" path unless you are designing your game to progressively load assets (ex: seemingly endless worlds). I never really checked how Godot does this, but I would hope it works similarly... but I might just be getting my hopes up there.

@Somnivore said something like: Thus far by using a KinematicBody2D for the player character I seem to have gotten a very smooth experience out of movement, not sure if that would still cause the sinking issue you're talking about, but I'm using high-resolution graphics so maybe it's just not noticeable on my end.

I'm using Rigidbody2D. I know, I know, you're probably gonna think that's absurd because 2D Platformer physics are not rigidbody physics -- but they can be! For the most part, when you build your own platformer physics, you emulate a lot of what the existing physics engine already does. -- although usually the existing physics engine has a working continuous collision detection setting. :disappointed: I will probably have to just use KinematicBody2D and roll my own physics... despite not wanting to. :weary:

NeoD

There is an official platformer demo who use a Rigidbody2D for the playable character. So it's not totally an heresy. You can read a comment in the player script who explain the possible issue when you use a rigidbody.

Somnivore

@LWurld

I agree with you about singletons being an anti-pattern essentially, but there's some things I genuinely only want one of and I also don't want to have to throw around a reference to all the time. Both Unity and Godot use singletons, particularly for Input but for other nifty things as well which can only be described as game-wide logic. It's seemingly inescapable without making things massively inconvenient. By working outside of a scene I refer to Godot's ability to separate level geometry (which I refer to as scenes as in Unity, confusing I know) from everything else, so if I wanted to have a super-scene which has some content not related to a particular level, it's easy, but in Unity it's not quite so: scene's are intended to hold level geometry (prefabs are certainly not very functional to work with in this regard, not to mention Unity's prefab system is the most basic compared to the big three, though I suppose it's technically possible.) I'll explain myself a little here:

I was attempting to make a 3D RPG in Unity before I got off that train; the problem I was facing is that I had some top-level content such as player inventory, the player party, multiplayer input handling, etc., that I didn't want associated with any particular scene: after all, once I load a new level, I'll have to figure out how to get all this logic and data to work with the next level, and then the next level, and then the next level...which seems more prone to bugs than even a singleton. Because Unity has no concept of this, the first solution I came up with was to first load a master scene, which stored all my top-level content, and then additively load my levels. So far so good!--until I realized the level I additively loaded had no lighting data. It's a known bug with Unity but it stopped me in my tracks, I couldn't have my top-level scene paired with my game levels, I had to use some weird methods to make it happen. Not to mention, multi-scene editing in Unity doesn't transfer over to a build which necessitates you load exactly one scene (which, unlike Godot, cannot have more scenes inside of it), requiring even more excess workaround logic to make work right in the editor and a build. Alas, that's programming with Unity: figuring out how to work around Unity.

RigidBody actually isn't a bad thing to use, I wound up using that for a 3D first person controller in Godot using its custom integrator; essentially the custom integrator makes the RigidBody do nothing except respond to friction and surface normals (maybe other stuff I hadn't noticed), giving you a lot of control over how it moves. I'd give that a shot before trying the KinematicBody.

LWurld

@Somnivore, Yah, Unity does have some limitations when you try to load a scene additively.

The continuous CD is my roadblock currently, only because I have to take the time to implement "something", whether it's a cheap hack, or writing a simple prediction-check for terrain, or writing all of my physics manually. I don't like cheap hacks, and the latter two options take quite a bit of time (learning GDScript adds to that time).

This weekend I will probably figure something out... maybe. I'm stubborn when it comes to development and I don't like cheap workarounds to get stuff done.

LWurld

Turns out... Godot does not support animated 2D tiles in their tilemap editor.

There's no way to win with any game engine it seems. :disappointed:

Rukiri

Game Maker literally is the closest thing to a what I'd call perfect 2D engine but it has it's snags to, it doesn't use vectors by default and a vector2 is way better than simply doing x/y checking... or use their physics which solves the vector problem but adds physics to the mix. Also data structures in GDScript are handled better than GML I believe "haven't done a comparison" so can't comment too much on that regard.

@LWurld um...you can use, oh wait nvm. Doesn't the TileD plugin support animated tiles? Don't know if it actually shows the animation in the scene editor once imported tho.

I'm surprised that Godot doesn't use Box2D or Liquidfun from Google for physics, the default physics in Godot are well...they're decent but not great.

whooshfrosted

@LWurld said: Turns out... Godot does not support animated 2D tiles in their tilemap editor.

There's no way to win with any game engine it seems. :disappointed:

I just searched on it and found 3 links saying you can do it with shaders. No good?

https://www.reddit.com/r/godot/comments/45rvwa/animated_tiles_in_tilemap_is_it_possible/

LWurld

Thanks @whooshfrosted . Using a shader is probably the best way.

@Rukiri , no. The Q&A on the plugin says that since Godot does not support animated tiles, it does not import animated tiles.

Rukiri

@LWurld well that sucks... using a shader for animated tiles seems more of a hack, maybe they'll add animated tiles in GD3.1?