Unity 2D vs Godot 2D

The reason why I'm saying this is because I've been there, done that. You can discuss other facts I posted directly in this thread that relate directly to this topic. Besides, I never claimed that I have proven something here. You provide one side, I provide another one. The point of having a discussion is finding the truth in the first place, again, by discussing facts.

I used to be in love with Godot. You can even see me doing awesome stuff with Godot in the past, like destructible terrain in 2D. It took me 6 months to achieve this result as a newbie at that time. And I'm pretty sure that I could achieve this much faster with Unity now, since I've noticed that Unity already has some packages to achieve something like this, instead of reinventing the wheel in Godot.

Again, if you truly want to believe that Godot has no major governance and leadership problems, that's your choice. But at least, I've done my best. I'm happy to discuss things about Godot, ask me any question. But I'm only interested in factual and fruitful discussions. Thank you.

 

A fact that is unknown to someone requires proof to be proven. I'd be fine with your statements on the community if there were sources available.

Spoiler

 

Facts are very hard to come by. Even if something can be proven to be a fact, different people will have different perceptions about it, and it's easy to get stuck discussing/nitpicking whose perception is closer to the truth.

I think it's healthier to accept that even though we might not be on the exact same page about something, it's possible to just get the gist of foreign opinions, then process those into our own decisions.

 

Well, by facts I mean something tangible, something that you can see with your own eyes. If we talk about Godot without ever linking to something externally, then what we discuss may only exist within our imagination. And I have provided a bunch of links to back up my claims about Godot here. My point is simple: if you really want to get to know the other side of Godot, you just have to deliberately search for it. I'm also a witness and provide my testimony, as someone who has spent 5 years working on the engine:



But I cannot discuss some topics here on Unity forums. Therefore, if you really want to engage with a free-flow discussion with me, I invite you to go to my Twitter (see my profile), because what we discuss here is frankly going off-topic.

Again, you have a powerful tool at your disposal. It's called "asking questions". I'm a 2D developer, so if you have any questions about 2D development with Godot in relation to Unity, just ask me. I'm learning Unity 2D myself, so your questions may help me to match my own knowledge to Unity.

"Facts are stubborn things" - John Adams

 

Yes, but personal perceptions are not facts. That's why I said facts are "hard to come by": when someone presents you something as fact, you have to assume it is not unless accompanied by clear evidence.

This does not amount to saying that all things you've said so far in this thread are not fact, it's just that they may not be and for many of them, we have no way of knowing unless experienced firsthand. I'm talking about things like:

This doesn't mean they're outright lies either, or that you deserve being scolded for sharing them. That's why I think some people in here should cut you some slack.

The Godot community may very well be extremely defensive, dishonest and cult-like, but unless we're part of the Godot community for some time and see this with our own eyes, this is just testimony, not fact. Fwiw, I appreciate your input about Godot and share quite a lot of your ideas.

Pretty much this.

 

Sure. Personal perceptions are not facts. But Godot followers will oftentimes dismiss facts like they don't even exist or pretend I've never mentioned them, and label facts as "personal perceptions", which is the core problem. This phenomenon is called gaslighting in psychology terms. You won't believe how many times I've stumbled upon gaslighting in Godot community. I'm also able to prove that a lot of people who replied to my messages here are associated with Godot on some level, which actually makes them biased (as much as I am). But I won't do this because I'm not on a personal vendetta. I cannot believe it myself that I experience the same thing on Unity forums. I didn't expect that ever in my life.

To make this more on-topic, here's an example of facts that I provided in this thread already:

This one definitely has some facts, I refer to Juan's tweet (lead developer of Godot) that he used Squirrel scripting language (before creating GDScript), if you look at screenshots in his tweet.

If you go to my post here and read the rest of my post, I also provided facts that Godot's built-in physics is actually based on Box2D. Compare yourself!

• Box2D-Lite physics source code (Arbiter)
• Godot physics source code (BodyPair)

To clarify: Godot does not actually use Box2D library, but it uses modified Box2D code for Godot's own physics system, because Juan has a tendency to not depend on others, hence Godot is a NIH engine, as confirmed by the guy from WinterPixelGames.

But for someone here, what I provided allegedly lacks sources. Do you imply that I provide no sources altogether?

Mind you, this is just an example. You may post-rationalize and move goalposts at this point by saying that "I didn't mean that". Due to this, I'd really like to imagine that people who responded to me here have positive intentions (wishful thinking from my part), but the way people responded to me here suggests otherwise, which means that they aren't interested in facts and would prefer to remain in the state of ignorance. There's no need to prove me wrong, I just wanted to shed some light to this. No offense taken.

Think about this.

 

I'm much more willing to take your statements on the engine itself at face value. For reasons including that we've had past discussions in this and other communities on the topic, that it's trivial to look up who you are and what you've worked on, etc.

It's your comments on the community that I have problems with because short of spending a long time with them I have no way of verifying the statements.

 

I already gave an example of what I consider to be personal perception instead of fact. That you've worked on Godot, it's fact. That Godot uses a modified version of Box2D, fact. That Squirrel was used before GDScript, fact.

That Godot's community is X, Y or Z, that's much harder to consider a fact since it's inherently subjective, so for me that's personal perception: your opinion on Godot's community, which is fine. I'm not instantly jumping on the "Godot people are a bunch of cultists that take no criticism on the object of their worship" bandwagon because you -or anyone else- say so, neither will most users present here. It may be objectively true that Godot's community is toxic, but given your testimony I'm sure we can find another one on the opposite end of the spectrum, and we have no way of knowing for sure which one is closer to the truth unless we become part of the Godot community ourselves and have an experience of our own. Call that gaslighting if you will.

My point is that we don't need to exclusively share and discuss facts. Opinions and personal stories are also valuable, and that's what I consider your core message to be.

 

Be patient, I'm not a master of Unity yet to give my extensive comparison on Unity 2D vs Godot 2D. But since you asked for it, let me provide my perspective on randomization.

Unity

Randomization as a static Random class. It has very useful properties and methods such as value, rotation, color, insideUnitCircle etc. Hopefully I don't have to explain why those features are useful because they are part of Unity core. But if you ask me specifically, I find insideUnitCircle extremely useful for a lot of things: shaking animations, spawning, explosions etc.

Godot

Godot provides randomization methods as built-in GDScript functions and via RandomNumberGenerator class, which allows to modify RNG state. I have personally contributed to this by exposing state property in RandomNumberGenerator.

The upside of using RandomNumberGenerator over built-in functions is that you can have multiple instances of it and ability to reproduce the same sequence of numbers given the same seed.

The downside of using RandomNumberGenerator is that it cannot be used as a static class, like in Unity. You may ask: why would you use RandomNumberGenerator as a static class? This is because RandomNumberGenerator provides more useful features not available in GDScript. This discrepancy leads to inconsistencies, so you just end up using RandomNumberGenerator for mostly everything.

Another downside is that RandomNumberGenerator doesn't provide convenience functions that you can see in Unity's Random class, such as insideUnitCircle. Due to this, I even proposed to add randv_circle feature in Godot, but they rejected it, because they are afraid to bloat Godot, as they say.

RandomNumberGenerator name is also too verbose compared to just Random.

Conclusion

While Godot does provide randomization methods, the convenience and feature set is inferior to Unity's implementation, so you'd have to write your own utility functions in GDScript (slow).

The above is an example of why Godot will likely won't match up to Unity's capabilities, but I oftentimes hear that Godot is comparable to Unity if we talk about built-in features, which I think is a misconception and miscategorization. You may respond to this with something like "this will be implemented eventually", but waiting for Godot is futile by definition.

So, even if we talk about technical things, my issue with Godot is not necessarily with the engine itself, but expectations. It's like they give out an impression that "it's going to be the next Unity but open-source", but I don't think it's fair comparison.

If you're concerned whether it's only me talking about this, you can read testimonies of others in Godot community, like what happened to ex-moderator of Godot Discord.

 

On the positive side, Godot will have movie maker mode, see a joke about this.

Does Unity have anything like this?

 

At the moment I need to filter out majority of your content, because you use every opportunity to insert your personal feelings against godot and try to make people feel specific way about them so they support you.

And dealing with this is tiresome.

For example, here you do that again:

"Godot uses opensource code, therefore person X is a bad person, how shameful". At this point you could go further and add "like and subscribe if you also condemn this reprehensible practice".

It would be better to discuss technologies and not grudges.

 

I would recommend you just disengage completely from all the discussion "about you" and "about the godot community/leadership" here (including this recommendation of mine, it needs no reply), and exclusively focus on engines and gamedev. You'll have a much better experience here, trust me! I bet everyone who's arguing with you would rather have some good faith tech talk, so lets please get back to that everyone!



Do you see anything standing in the way of implementing the following in Godot/Unity (would love to hear replies from our 2D Unity experts as well):

Hypothetically... I'd want to be able to at runtime: load, edit in realtime, and save a tilemap in my own data format that is translated by the game into a stack of tilemaps and sprites over several layers that each may have different blend modes (blending the whole layer content in that mode as a whole and NOT just each individual tile or sprite set to that blendmode) and are organized something like this (top to bottom)

-interactable sprites
-[additive] background light fx sprites (glows etc.)
-[multiply] background shadows
-[alpha blended] background decals
-background tiles with transparency
-background tiles without transparency

I have some ideas about level editing workflows that I might want to test, that wouldn't make sense with in-editor tools that are designed to build simple-tilemaps. Are there any hard limits on how big such a tilemapped level could be? Is there anything that would suggest it's not practical to make the whole playable area of a tilebased 2D game into one big level loaded in at the same time? Does the Engine do a good enough job culling out offscreen content from the rendering? Are slowdowns to be expected from just having a large number of "things" in the scene hierarchy?
What does the Engine offer in terms of Pathfinding for tilemap based layouts and can this easily adapt to runtime changes of the level layout?

 

Unity works more like general-purpose framework, so in theory you can make anything with it. That is going to be limited by your programming skills. If you deviate too far from what engine can do itself, you'll end up rolling out your own solution, which will grow progressively harder, the further you deviate from engine capabilities.

In your example, you can approximate layers with z-order which unity supports. You'd need to investigate the way of implementing "light fx" on a static background, and once this is done, you'll be left with implementing a simple 2d tile based editor. Which should be very doable

 

Most people would consider this an opportunity for self reflection.

 

You can have as many TileMaps in Godot as you like. Those can be sorted by either z-index property, child order in the tree, or even on different CanvasLayers (but don't expect blending to work between CanvasLayers). However, synchronizing changes between TileMaps that are used as layers may be slightly problematic, because you must make sure to have consistent cell IDs between those maps.

There are some limitations in Godot for large TileMaps. Namely, if you have cell_size > 15000 you'll start to get `map_to_world()` and `world_to_map()` accuracy issues. See comment by Godot's project manager on this. It's not documented limitation.

You can also assign CanvasItemMaterial to each TileMap, using different Shaders, and it will work globally for the entire map.

As far as I'm concerned, Godot does cull out offscreen content for the most part. But here's the catch: if you zoom out with Camera2D, you may get severe drops in FPS. I'm not sure if that's specific to Godot. I'd assume that Unity would handle such cases via LOD/mipmaps or something like this. This limitation may be certainly real if you use polygons a lot. There was some batching fixes in Godot that may help this as well.

Due to all above you may need to stitch several TileMaps as chunks for both accuracy and optimization purposes, which may be a hassle.

Not sure about pathfinding. It may be static in Godot for TileMaps, I haven't used it myself, as I relied mostly on custom solutions that overcome those TileMap issues when it comes to dynamic changes.

Regarding the load/save part, I think you're on your own here. You can create custom resource importer/exporters in Godot, but it depends on whether you plan to make your game to have user-generated content. I have written a proposal on this at Godot proposals, called Allow to import and load external assets at run-time. The stance of lead developer was expected: he doesn't see the feature valuable to have in core, which is unfortunate considering existing user requests.

Regardless, you can create custom EditorPlugins or simpler EditorScripts in Godot to edit TileMaps to automate any of this.

 

Thanks a lot you two! I just had a quick look at the Godot documentation for the tilemap class and the same in Unity. I can see what you meant with Unity having a "richer" API. Godot's tilemap class looks quite basic in comparison. Based on some of the denied feature requests that you've linked, it looks like Godot is in some areas "barebones by design". Would you say it's fair to say that Godot is best used with a mindset of working strictly withing the existing limitations, and neither expecting missing stuff to be added in the future or it being reasonably painless to add yourself, because it's simple by design? And Unity may have a higher barrier to entry and friction at the beginning because there's usually multiple ways to achieve something (and half of them are probably deprecated and poorly documented or need to be purchased on the assetstore) but if you want to do something advanced, you have less hoops to jump through in Unity because it's more flexible by design?

 

I'd say pretty much yes. I just wouldn't set hopes high. With Godot 4.x, I think they are aiming for even more barebones approach, and they may choose to port built-in features to many GDExtensions (GDNative in 3.x) at some point. If they do this, they'd also need to remain the out-of-the-box experience Godot currently has feature-wise, otherwise I think they're going to make a mistake by forcing users to download essential plugins manually (I've seen some Godot users were speaking against breaking Godot into first-party plugins).

Here's my review on Fedora apps I've made a year ago about Godot.

 

Because it is an opensource engine with fewer developers, no income and less funding, it is expected to be more barebones compared to a solution like unity..

There are more barebones solutions available. For example, there used to be Irrlicht, there used to be Ogre3d framework (used to ship majesty 2 and early version of Scrap Mechanic), if someone wants to go lower, they could see if OpenSceneGraph is still alive, and past that there's libsdl which is a very thin wrapper between OS and the programmer.

 

There exist numerous factors. I think FOSS lacks proximity between users and developers in general, and even between developers themselves. Godot could definitely get more professional developers on board without funding, but their elitist attitude tends to push professional developers away from the project, unfortunately.

Example: see what the lead developer said to one potential contributor who managed to improve Light2D performance and engine's performance in general. People were so amazed by those improvements that some expressed willingness to use his fork, even though what he did was mostly for proposal purposes. There was no hostility from the guy who made and proposed those changes, but the lead developer interpreted constructive criticism as a personal attack...

Another example of such elitism in Godot: someone proposed to add bgfx as a rendering backend for Godot. Even the author of bgfx itself shed his perspective and explained various technicalities and feasibility around that when he noticed a proposal was made by someone else for Godot. But then again, the lead developer said that they should stop pestering them, because he has more than 25 years of experience, so they better believe him... The problem is that there was no pestering in the first place, as commented by another member in Godot if you read further.

So, I'd say leadership definitely plays a crucial role. Look at Blender, they do much better in contrast to Godot in the open-source arena nowadays. I mean, sure, you can say that Blender has been developed for a longer time. I may be wrong. Lets see where this goes in 10 years from now. I bet that something else will appear that will replace Godot, likely a fork. They must be able to take criticism gracefully if they truly want to succeed in the long run.

 

And here we go again with you trying to undermine the devs.
This happened 3 years ago, and Godot being opensource you can just fork it and implement whatever you want. In time your fork can replace the original and this is what opensource is about. This sort of thing cannot be done with Unreal or Unity.

Also, if you look further into the thread, there's this:

Posted by the fork developer himself. Which is a very solid reason to avoid it. Counter arguments provided by reduz like Vector<> not being an equivalent to std::vector also sound sane (see QString vs std::string for example).

I would personally prefer if you focused on something other than "person X did Y therefore person X is a bad person". People and their attitudes are nearly irrelevant, when you can clone the project at any time and make it yours.

 

One more thing.

I'm not sure if you realize it or not, but people aren't stupid. At the point, it is incredibly obvious what you're trying to do. Your goal is to spread negative impression of Godot in order to get back at its developers, because of your personal beef with them. In order to do so you're not above doing things like cherry-picking and similar tactics. Reading 2 or 3 of your posts is enough to realize that. The thing is, this sort of behavior, does not create negative impression of godot, it creates negative impression about you instead. Also the reason that led to you being kicked out of godot community isn't helping.

Have you considered, I don't know, spending your time in more productive way? Somebody said "our enemies would've been ecstatic if they knew how much time we waste thinking about them". Same applies here. Why not fork Godot or make your own engine?

 

You completely ignored all technical posts of mine here about Godot, by the way.

There cannot be any kind of undermining of the developers if what I say is backed up by others in the Godot community. My goal is to tell the truth about Godot, and not to create negative impression for the sake of it. Godot fans will say good things about Godot here anyway. But it's equally important to shed light to aspects such as this as well, because not a lot of people will see this unless they research this issue themselves, and I wish I knew about this when I just started contributing to Godot like 4 years ago.

No offense, I'd like to think that you have good intentions, but it's painfully obvious that you're having a personal grudge against me. Your attitude towards myself will only make me move away from Unity. Perhaps you identify yourself as a lead developer in other projects so somehow you get offended by me criticizing leadership in general. You even said that you had negative experience with "Godot prophets" on Unity forums, so I find it difficult to understand your position on this. I see you <redacted> your initial message there. But I recall the original one where you said that my experience "matches your assumptions about Godot community", or something along those lines.

If you immediately changed your opinion about me under some peer pressure and/or because you read slander about me, again, that's because scapegoating of former Godot members (like me) is very real in Godot community (and elsewhere where Godot fans reside, like here, on Unity forums). I'm probably the first one who got victim to this...

I'm very good at pointing out contradictions. When Godot leadership ignores to acknowledge or rejects that those contradictions of "words vs actions" exist, then we're talking about hypocrisy here. But of course, Godot does nothing wrong on the surface, as I said, it's mostly "words vs actions" which creates a problem. It's extremely important to be explicit about project's intention and vision, since Godot is publicly declared as community-driven. But in reality, it's community-informed, not community-driven. I could expand on this thesis, but this is not the place for that. But occasionally, yes, I will mention more general things about Godot, because I'm a whole person that enjoys synthesis as well as analysis.

So, for some reason, instead of asking more questions, you choose to misinterpret what I say and fixate on how I conduct my reasonings, appealing to my emotions that are even impossible to read from the screen. These are all logical fallacies. But I'm not saying that you're wrong either, I just want you to focus on facts here. You're free to filter out what I say of course. But you're also free to ignore me completely, if what I say bothers you to the point of making you tired. Perhaps you get tired because you receive information from me that doesn't get in alignment with your own mental image of the world and you experience cognitive dissonance because of that.

No need to reply to any of this, I'm going to ignore your comments if you keep fixating on me, and not the topic, I just wanted to clarify this to you and the rest of the readers here and refer to this post in the future. So, please, I don't want this discussion to be about me. People keep discussing Unity CEO here and get no comments about this. But when I discuss Godot leadership, again, on Unity forums, I get attacked for some reason. This is ridiculous.

Again, no offense. I get responses like these all the time, mostly from overzealous Godot fans. Are you one?

Because of conversations like these. I decided to try and use commercial game engines now, and see how it goes. But I cannot just move on and be silent about this. Imagine working on the engine for years, voluntarily, and get treated like trash. If we don't challenge toxic leadership (real term), they will rule the world.

You propose to fork Godot. Well, overzealous Godot fans react quite negatively about this. They will say some things like: "you want to sabotage Godot". I'm not sure whether it's worth it, having to deal with never-ending hate by Godot followers. You can read my topic at Godot Forums titled The Future of Godot.

Godot contributors don't really want to make a fork of Godot. Most people in Godot community would like to prevent division. And now, Godot core developers get angry at me that I created Goost (which is not a fork, more like an extension). This highly repulsive attitude is what made me completely abandon Godot, and not the other way. And that's probably another reason why you won't see much Godot forks, because people don't even want to deal with Godot because of this community response: "you should not criticize Godot".

Preventing division means writing development philosophy. Godot developers refuse to write it, therefore division and difficult-to-resolve conflicts are inevitable in Godot community. Even if I create a fork, I'll be attacked for maintaining one. This is not healthy.

I also think that one reaches some level of expertise when Godot does not interest you anymore, I don't know. I have skills to make a fork, but when I'm looking at other game engine alternatives, I think to myself... "Wow, I've been missing out". And this is probably why Godot won't have many forks as well because people with greater expertise will choose to work on something more sophisticated and/or just go straight for using low-level libraries, like SDL and have the freedom to create any game imaginable.

Peace, and long live Unity.

 

If people do not respond to something, that does not they didn't see it.

Your life, your decisions. If you want to move away, do it. For the record, I'm not on a holy mission to promote or undermine anything. I do share information I deem useful, but that's the extent of it.

And? Such is life. Putting effort into something absolutely does not mean you're ever going to get recognition or special treatment for it. Even if it is a lot of effort. Those things happen all the time, everywhere. However, the right idea in this scenario is to move away and stop wasting more time on the project.

In your case, however, you were kicked out due to the way you communicated with another developer. Choices and consequences.

A small opensource project has no power to rule anything.

The time wasted on challenging something is the time that could've been spend building a better alternative. Because you aren't creating while trying to destroy. Why fight leadership when you can replace the project?

Like I said. It is opensource. Fork it. Make your own leadership. Attract people. Replace the original. Better plan than what you're trying to do right now.

Why is that even supposed to matter?

If they're angry, they still cannot do anything about it.
If someone "would like prevent division", then there are still people who would be interested in an alternative.
Competition is supposed to be a good thing.

And how do you expect yourself to "fight leadership" if you worry about someone else's opinion so much?

Why would you care about what people will say? If you're implementing the right idea, people will flock of to it. No matter what you do there will always be at least one person that will love it, and at least one person that will hate your guts for it.

I'm of opinion that software is supposed to be about solving problems, and "writing down development philosophy" is a good way to cause division and endless bickering while solving no practical problems in the process. Nevermind that there will be people who disagree with development philosophy and that will create division anyway. Engines are tools. And a hammer does not really need a philosophy.

 

Please do

 

I think this is exactly the core difference between our opinions. While development is mostly driven by solving problems, division is inevitable exactly because we tend to solve different problems slightly differently. And division is inevitable in either case, but a project which has development philosophy written down will build better expectations for all contributors around the world and relationships between people, so this will naturally minimize the chances of division. One fellow from Godot explains this better than me, why having development philosophy is crucial for open-source projects.

Due to this, I see no point in answering the rest of your questions here, because our disagreement lies deeper than what we see on the surface. But thanks for sharing your perspective, so lets agree to disagree, at least.

 

Earlier you were using "wishes of godot community" as a leverage for your arguments. "Community does not wish division", etc.

However this proposal of yours did not attract community's attention, as number of people commenting on it is incredibly low. Which can be interpreted as lack of community support for your proposal.

In which case there's a question - why are you trying to introduce something that community does not want?

Basically either you listen to everybody and try to do what people desire, in which scenario your proposal appears to be unwanted.

Or you try make yourself the leader then make your own vision come true regardless of whether anyone want it or not. In which case the way to do it is making a fork.

 

Hmm, to put it in a really provocative way: If your project does not have a defined development philosophy you stick to, you might be tempted to aim for something entirely different after a few years - like ads in Unity's case
(not my personal belief that Unity does that actually, but some people perceive it as so)

 

Why not?

See blender.
polygonal modeling, sculpting, video editor and 2d animation suite. All in the same package. You can also make clothes in it, though it is a bit awkward.

 

This forum will no longer discuss Godot vs Unity. Instead the recommendation is to try them both out.

Please report any posts of people trying to wage wars or start trouble, so I can give them a temp or perm ban. Because these forums are for the development of software in Unity.

It is not illegal to compare if it's an innocent question, but we will not tolerate anything that creates discord, or attempts to control the narrative.

This forum really is about progress and development. Nothing more.