Unity 2D vs Godot 2D

That's good to know, thanks a lot! I'll wait for Godot 4 Beta then.

That's OK, the real truth will be somewhere in the middle I expect. At least he actually has seriously used Godot for years. If you'd discredit the opinions of our most vocal Unity haters just because they seem to be on a crusade, you'd ignore a lot of valid points too.
I don't really care about the philosophical and organizational pain points, but I want to hear about the showstopper engine limitations like lack of certain features etc..

 

That's the problem. He hasn't pointed to anything aside from the overall approach the developers are taking.

https://github.com/godotengine/godot-proposals/issues/575

 

Of course, and from what I've seen his technical knowledge seems solid. I was not suggesting you outright dismiss his views, just bringing some context to the table so you or any other person reading this thread has the full picture.

 

I get your point, and it is a good one, but that's not entirely fair either, since he did list some specific engine flaws. He mentioned the API:

Which I take as Godot might be missing convenient functions that I'm used to from Unity (there's a lot in the Math and Vector classes that I like). And limitations in the rendering:

Which has been acknowledged by trusted members of our own:

 

Having tinkered with Godot for a bit (Godot 3.4, that is), I don't really find it comparable to Unity/Unreal in its current state. Even for 2D, I think it's bit lacking.

I mean, this is not a bad thing per se. The basics are there (sprites, tile maps, particles, 2D physics and 2D skeletons) so if you want to make a simple game Godot is less bloaty than Unity, and there's less clutter to distract you. It may become a problem if your game grows over time and you hit a ceiling within Godot, since moving another engine would not be an easy task. Same could be said about moving out from Unity, tbh.

I'd say try both, make a small project to get a feel and choose whichever suits your style best.

 

Where specifically do you think one would hit that ceiling first in Godot with a 2D pixelart game? Shaders and rendering pipeline? Lighting? Having tried neither, the 2d animation and tilemap features looked more promising to me in Godot, based on videos I've seen. Same for the UI stuff, since Godot actually uses their own UI stuff to make... the Godot editor. So where is Godot lacking? A lot of people seem to think it does but seem to have trouble putting ther finger on specific examples.

 

In my opinion, the less developed part of Godot is rendering. Not only because of lack of features, but because what is already there is quite cumbersome to use (at least, for someone used to Unity). Keep in mind that I’ve used Unity for a lot longer than I’ve used Godot, so my opinion might be biased/outright wrong.

Based on what I’ve seen, tilemaps in Godot are very much equivalent to what Unity offers, and they’re used in a very similar way. There may be minor differences in features, but either engine’s tools are more than enough for most games.

About UI, Unity also uses its own UI system for the editor, you said this like it’s Godot-specific? Unity has 3 different UI systems to choose from though, the one used for Editor stuff is stateless/immediate which can be awkward for games (and not really a good choice for specific things, like 3D UI embedded in the game world). I don’t think UI would be a problem with either engine in most cases.

Performance in general is a big concern for me, though. As far as I know, there’s no memory profiler or frame inspector in Godot, all you get is a CPU profiler. You cannot profile a build running in the actual device either. Multithreading support is really iffy, you get very low-level building blocks and no robust way to write high-performance code so things like crowds (ala They Are Millions) will be challenging. Not that this is a problem for most games though.

 

Plenty of made with Godot games doing well on Steam, decent amount are also pretty advanced as far as depth goes: https://steamdb.info/tech/Engine/Godot/

I'd say the performance question is largely addressed by the engine being open source. You can write engine modules and C++ plugins to deal with any performance issues. And Godot's 2D performance is better than Unity's by default if I recall the benchmarks correctly.

 

The engine does not make the game. Games doing well on Steam should be attributed to their creators, regardless of the engine they used. It’s a bit like attributing the quality of Van Gogh’s art to the brush he used.

So can you in Unity, and in most engines. But extending the engine to do things that it can’t do should be a last resort. I’ve written an entire physics engine in C++ as a Unity plugin, then rewrote it using Unity’s job system. Performance of both was similar, but writing the C++ one took almost x4 longer, (not to mention the amount of tears shed).

You could write your own memory profiler, your own job/task scheduler on top of raw threads/mutexes, but if you can spend that time making the actual game why would you?

If Unity takes you closer to your goal, use Unity. If Godot does, use Godot. No one really cares but yourself, so I’d say use what fits your use case best.

 

You're right, but what I wanted to highlight is that there's a difference between working with an engine that's fully open source and working with an engine that's a black box and out of reach for modification for most.

 

You can't change DirectX. Or OpenGL. Or OS (can't change proprietary, can't easily make your changes widely adopte with opensource). So there's always a black box.

 

I wasn't suggesting going to such extremes, just that writing an engine module accessing the core engine is possible with Godot, and not with Unity. The recent Spine integration was written as an engine module. It does require re-compiling the whole engine, but it's also a lot more performant than what Unity has with C# runtimes and it also feels native in usage and not bolted on like say most asset store products.

 

And with unity in majority of cases it is not necessary to access the "core engine".

Native plugins are a thing. Though they require C++ expertise.

 

I fail to see the advantage here :/. To write an engine module in Godot you need to essentially branch the engine and recompile the entire thing? In Unity you just write a shared library, which can be written in either C# or C++. No need to recompile anything but the code you wrote. Same performance advantage, but simpler?

I do understand that in some cases, you may need to reach into the engine’s innards to modify something that isn’t exposed trough API, or to fix a bug. But these should be relatively uncommon.

Again this depends on whoever wrote the plugin/module. Writing C++ won’t make it feel “native”, which I assume you mean better integrated with the engine’s workflow. Many asset store assets use custom editor windows, overlays, logo banners, weird fonts, no icons... with which the editor ends up looking like the frankenstein monster. If anything that’s a testament to Unity’s popularity, ease of use and flexibility (for the good, and the bad): anyone can sell libs/addons/etc, often with little aesthetic or functional cohesion with the engine and each other. This has nothing to do with native/plugin or managed/unmanaged code.

You could argue that certain functionality needs to be added very close to the engine’s core, but really I doubt anyone making a “normal” game would ever need to do that. You don’t need core access to write a custom format importer, a custom renderer, or even a custom physics engine.

 

You can somewhat do both but the runtime approach is far more limited.

https://docs.godotengine.org/en/stable/tutorials/scripting/gdnative/what_is_gdnative.html
https://docs.godotengine.org/en/stable/development/cpp/custom_modules_in_cpp.html

 

Doing well on Steam? The amount of games doesn't mean a thing since everyone can self-publish games on Steam.

There are barely a few games with a peak of over 1k players.
Please don't count the top position, it's a free demo

Half of the first 100 games don't even reach 100 players' peak. And a lot of these SKUs actually represent demos.
Is that even sustainable for a full-time solo developer?

Most of these games are rather simplistic 2D games that could be done in almost every 2D game engine? Nothing advanced or special about them, sorry. As player numbers confirm.

Generally, it looks much more than a purpose-built tool like RPG Maker. All that 8 years after Godot 1.0 release?
https://steamdb.info/tech/Engine/RPGMaker/

 

I played Ex-Zodiac last night and it seems pretty great. I'm interested in trying out Godot so I figured I should try out a game made in Godot, and Ex-Zodiac is pretty much all I needed to see to know that a lot of my ideas for games would be possible to make in the engine. Would they be better in Godot vs. Unity? Not sure yet, but at the very least I'm going to give Godot a try and see how I like it.

I'm not sure why the number of players playing Godot games on Steam would be an indicator of how your game will perform if it's made in the engine. Godot isn't going to affect your sales if you make a good game. Someone, at some point, is going to make a big hit in Godot, and the game's sales will not be any different if it were made in Unity or some other engine. The low numbers aren't an indicator of how well Godot games will do. I think they're so low because there just aren't very many Godot games out there yet. The engine only now seems to be reaching some level of maturity, and as a result I think there's going to be a huge spike in quality Godot games coming out in the next few years.

 

I think it might serve you better to focus on what sort of development teams are using the tools and what problems they are facing and try to figure out if you'll be able to overcome the same problems or workaround them or avoid them altogether.

If you are looking at only successful published games, you are viewing cream of the crop. It might have little bearing on how your own development goes.

 

Yeah. I'm not using Ex-Zodiac, or any Godot game for that matter, as the deciding factor for whether or not I should use Godot for future projects, that will be determined by actually trying to learn it in my spare time. I just wanted to try something made in Godot to get some idea of what it's capable of, more out of curiosity than actual research.

 

Be careful with this assumption. One of the main advantages of Godot is that you have full access to the source of the engine and if you need functionality that isn't in there you can do it yourself, but the alternate way to view that is you might not have a choice but to make those changes.

 

Right, but that definitely sounds like a plus to me. There have been several times working in Unity where I wished I could change small internal things here and there. Having the power to change the engine to fit my needs exactly would be great.

 

The problem with "truth will be somewhere in the middle" is that it could be seen as a logical fallacy. Also, you'll oftentimes hear that I'm on a personal vendetta against Godot, but that's mostly Godot fanboys who attack me using ad hominem arguments or making strawman arguments just to discredit what I'm saying. I know it sounds like difficult to believe, but that's exactly what happens in Godot community, people cannot speak their dissent opinion in Godot community without getting ostracized, and this problem alone was enough for me to abandon Godot for the rest of my life.

As I said, I certainly could talk about technical downsides of Godot as well. But that's Unity forums. Also, if Unity users were concerned by things like ironSource merge and CEO saying stuff, and that alone was enough to cause mass hysteria, I thought that those people don't actually bother with technical side of things.

I just wanted to clear this up, since my persona gets constantly slandered here even on Unity forums. Please, don't spread slander, always discuss facts (I provided many already). This is Unity forums, after all. But I couldn't stay silent after I noticed that secretely disguised Godot fanboys here were preaching the gospel of Godot here, on Unity forums, which is kind of ridiculous, don't you think?

Again, try to discuss facts, not people. Thank you.

Also, yes, I will certainly provide my perspective on technical side of things once I manage to port my Godot project to Unity (and C#, since I got addicted to GDScript that is only useful for Godot development, obviously), currently I have limited experience with Unity so I refrain to give my perspective on this for now (I'm mostly interested in 2D).

 

I think this benefit is overestimated, and the need for this is largely contrived. The more specific requirements you have for your project, the more the likelihood that you'd have to build Godot from source. And Unity, despite being called "bloated", provides many solutions out of the box exactly for the reason so that you don't have to recompile the engine from source just to have an extra feature that is performance-demanding.

Like I had to compile Clipper for my 2D game involving destructible terrain, which is written in C++. In contrast, Clipper is available in C# and could be adapted to be used in Unity without much hassle, all without recompiling the engine for many platforms.

I also used to maintain Goost (I'm also a creator), exactly because Godot lacks some useful features for 2D to be available out of the box. Making releases of Godot + Goost was a really tiresome process, especially when they constantly break things.

With open-source, you're all on your own. And it's equally painful. With Godot, imagine having to set up local Docker/Podman build containers, spend up to 48 hours building images for all supported platforms yourself (unless you have an expensive AMD Ryzen Threadripper). Not only that, if you want to do this properly, you must have a macOS machine because building everything from Linux means using OSXCross, and that's another can of worms to set up properly. For console support, you'd have to contact third-party to even port your bug fix. In case of Godot, that "third-party" is actually first-party, but they won't tell you this because it's against Software Freedom Conservancy mission.

Have I mentioned the fact that you just cannot fix a bug even if you have the source available (because you're not an expert, for instance, or you don't have the macOS machine available to reproduce a crash). So in all likelihood you'd need to contact a professional in order to fix a networking bug, for instance, and likely for money because this requires work, especially when Godot is not willing to support the older stable version of their engine, since they are already occupied with the Next Big Thing.

So, the above is exactly the reason why I ended up working on the engine rather than the game, which is sad.

Conclusion: you either pay with money, or your work. Even as proponent of FOSS myself, I say that there's no such thing as free software, I think it's a myth when we talk about maintenance and support.

 

work = time = money. So yes, In my experience this is accurate: you either pay someone else to spend their time developing what you need, or you spend your own time developing it yourself.

The problem with this false sense of empowerment "it's open source, so anything I may need I can do myself! the possibilities are endless!" it's that in many cases, you don't know how to do it yourself. And that means that you will spend a lot of time learning how to develop and actually developing the thing you need, compared to someone who already got the experience/skills. So in many cases it's actually cheaper to buy an existing, commercial closed-source solution (which is probably also better than anything you could ever write yourself).

Thinking out loud, within silly territory... someone that knows everything that needs to be known in game making, might be interested in the ultimate open-source project: the null game engine, open up some blank .cpp/.h files and begin writing your game from scratch!

 

Yep, open-source does not balance out lacking areas: if the engine is any good, the need to actually open up the hood and fix/change things yourself should be extremely rare. It's certainly good to be able to do that, but it should not be relied on as the universal cure.

 

i read somewhere recently that the amount of man-hours put into many modern game engines is greater than the amount of engineering gone into apollo mission to the moon.

Just something I read so apply the grains of salt but I think it makes point effectively anyway that modern games are simply too complex for one person to be able to knwo how it all works.

I think exploring curiosities is fantastic, but if intent is to make a game i think its better to try and get as much help as possilbe, with ideal goal of only having to put most of your energy into your core strengths/interest.

Now that is not possible, you'll have to do stuff you arent good at and dont like, but htat's the goal i work towards anyway.

 

Which is totally acceptable course of action as well, especially if you want to learn software engineering. It's like going through nand2tetris course. Depends on whether someone is genius enough if they really want to build an engine from scratch that way. Even then, people tend to fixate on building engines, not games, as a way of procrastination, perhaps.

Speaking of Godot, it's very NIH engine. They started with SDL, Squirrel scripting language, but then ended up doing everything on their own. You can read concerns about this NIH syndrome in Godot from WinterPixelGames (they work on 2D games currently).

I've also spoken to WinterPixelGames developers, they said that it required them to integrate Box2D instead of using Godot's built-in 2D physics for one of their games. At the same time, you'll even see that Godot's own physics code is shamelessly taken from Box2D-Lite and adapted to Godot.

Taking into account above, I'd say if you really see successful games made in Godot in the future, it would be mostly because of individual developers' incentive to modify Godot and/or by integrating third-party code, it's not really Godot's merit, but they will sort of "steal" or "cling to" that merit by saying that a particular game was made exclusively with Godot's built-in capabilities, which is certainly not the case.

So, I don't see the point of doing something allegedly from scratch, if you're just going to use code of others. Godot developers say that it allows them to achieve "freedom", or a compromise of "glue vs politics", as Juan says. Still, this is controversial approach, considering that I've been waiting them to fix a center of mass bugs for years! I don't think it's worth it, but it also depends on responsibility of developers to fix actual bugs...

 

Gotta pick one, buddy.

Once again, pick one.

 

Box2D is MIT licensed. Box2D lite is also MIT licensed.

https://github.com/erincatto/Box2D
https://github.com/erincatto/box2d-lite

So, "Shamelessly"? Allowing this sort of thing is the point of opensource.

 

Also, correct me if I'm wrong, but doesn't Unity also use Box2D for its 2D physics system?

 

Sure does.

 

You missed the point, I should've clarified, sorry. There's no problem with that specifically, but:

• Juan took Box2D-Lite code as a base for his own Godot 2D physics. But he never mentions that in the sources nor documentation. According to MIT license, adding the notice of MIT license is required. But Godot does not attribute to Box2D-Lite (namely, copyright of Erin Catto), to denote that Godot's 2D physics is based on that.
• Even if assume that Godot does attribution, then it goes against Juan's elitist claims that Godot is innovative and unique, as he always says on his Twitter, so his actions vs words makes Godot either hypocritical, or what he says is like a commercial marketing trick to get more users on board.

There's no problem that Unity uses Box2D either. That's great, in fact. Unity lists Box2D in the license text of third-party components. But Godot doesn't even acknowledge that Godot's physics is based on Box2D-Lite code, which is a problem.

 

it sounds like what you are telling us is that the guy responsible for selling/promoting the thing is less than perfectly forthright and honest, and you take issue with that.

Most people aren't gonna care about that kind of thing. If it bothers you, better off just doing your own thing. An honest person is probably one in a million or less.

 

Yes. this is one of the reasons: dishonesty, and it goes through a lot of aspects of Godot development, and I definitely take issue with that.

What staggers me is when Unity CEO calls users "F***ing Idiots" and that reason alone was enough for some Unity users to migrate to Godot. Sorry for crushing dreams, but Godot leadership is not any better, folks. But again, this is my personal experience, so you may take this with a grain of salt.

 

i think thats more like a straw broke the camels back thing.

unity has been behind on roadmap stuff for a long time and making it seem like it is going in a direction other than indie game development, which is what most the people here are interested in, at least as far as I can tell.

Anyway Ive got no problem with somebody blowing a whistle if you think its right, but i spent plenty of years being pissed off because people lie, cheat, steal, all of that. I won't work for any corporation or pretty much any team these days, but I'm lucky enough to have some measure of financial security so I can make that choice.

 

Yes, we know you take issue with it. It's literally all you ever post about.

 

Again, looks like I get an insinuation that I cannot talk negatively about Godot on Unity forums, even in a thread specifically designed to discuss Unity vs Godot. But for some reason, positive things about Godot on Unity forums aren't frowned upon on Unity forums.

May I get "political refugee" status on Unity forums as an ex-developer of Godot, please?

(j/k, this is irony)

 

you made your case, what else is there to say? DId you expect people to sign a petition or something to vow never to use godot?

a few people will read what you wrote and think something of it or not. What else can you do? If you want war on godot, probably should wage it on the godot forums.

 

He got banned from all Godot socials for calling Russian members fascists.

 

You could bring up issue regarding mit license attribution on the Godot bugtracker, however, the wording you used implies that using code of Box 2D is something shameful and should be frowned upon (even though it is MIT), but only when godot does it (becauhse when unity uses box2d it is great).

Furthermore you're using emotionally loaded language against some godot developer and apparently expect people to subscribe to that automatically.

Overall your every post gives impression t hat you're on some sort of personal vendetta against godot and are trying to rally people to, I don't know, overthrow it? Destroy it? Make developers sprinkle ashes over their heads?

Personal vendettas are not interesting. What interesting is unbiased information and unique point of view.

 

Sounds like you need to take your own advice. Because listening to the tirade of your political agenda is not fun or interesting. If I'm going to pass on Godot it's going to be due to it's own shortcomings and not those of the people behind it.

 

Discouraging someone from sharing their experiences in an open discussion here is not something this user agrees with:

Also, if he were to go to the Godot forums to criticize Godot (the same way people come to the Unity forums to criticize Unity), they could hit him with the:

 

@UhOhItsMoving you taking quotations out of the context and much bigger picture.

 

That context & much bigger picture being?

 

thats kinda fair except the difference is my post were actually about unity and problems i had in unity, so it is a little different.

i dont have any issue with xray saying their spiel though its up to mods not me what is on topic or not, i just letting them know that i think they are probably gonna fall on deaf ears the sort of thing they are focused on. i also think it sounds very much like general problems that exist anywhere there is a team environment. some people dont get along, they split ways - people promoting a product stretch the truth, and so on.

 

Back at you. No comments. Please decide whether you want to discuss facts and carefully read my posts starting from this one:

 

A Twitter post with no sources that you wrote is not proof of a forum post you wrote that likewise has no sources.

 

Also this isn't a debate club, logical fallacies don't lose you points as they don't really have much in the way of any relevance to an actual discussion about a person or their behaviour.

 

Corrected my post after I realized how it read.

 

I don't thing arguing about which engine is better or which community is holier does any good to anyone. No one is a saint, and "better" is a very relative concept: better for what?

Xrayez has had issues with Godot's community, and even though he may not be stating absolute truths, he has his opinion and his own subjetive feelings towards the engine, which are as valid as anyone else's. His takeaway message, at least for me, is: "you think there's dark corners in Unity, well it's the same at Godot."

And to be honest, I don't think this is hard to believe or surprising at all. When you spend enough time working with a tool, all its flaws become obvious enough that most alternatives to it (which you often know very little about) suddenly look enticing. I've worked with Godot, Unreal and Unity (ordered by experience with it, from less to more) and all 3 have good things, and bad things. I had "WTF??" moments with all of them. There's fanboys and haters in all their communities.

I've worked with 3DsMax, Blender and Maya (again ordered by experience) and it's basically the same. Worked with Cubase, FLStudio and Logic, again the same: depending on the task, you'll be at different comfort levels with each one.

If you want to know which engine is better for 2D, I'd say try them. I believe it's the only way.