Unity 2D vs Godot 2D

You could have all your lightmapping done by handing a baby print outs of your textures and giving them a crayon to draw on top, and it would still be better lightmapping than unity

 

This is... OUCH.

 

Dont put salt in the wounds (ops that was a swedish only idiom, it means
add insult to injury)

Though I think the PLM is doing a pretty good job on the actual lighting part, its on par with Enlighten at least. If they could just pack the lightmaps better, oh and also make sure to spatial group near by items so they end up on the same atlas. Now we need to tag objects manually which is a literal pain.

 

Well those are some pretty good reasons for me to continue not evaluating Godot. Thanks. You provided the "I used Godot so you don't have to" report. Much appreciated.

 

It's isn't just Swedish, we also have the same in the UK. What this thread proves is Godot should not be dismissed, it is worthy of competitor analysis. It has weaknesses, but there is much to learn from the strengths.

 

I understood it as well, it was close enough to make sense. I know its also common in Latin American Spanish.

100% agree.Though I haven't actually done any testing with it, this is why I tend to at the least keep tabs on the competitors. Things change over time, so its good to know what's happening elsewhere.

 

MDADigital is to derailing threats what Arowx is to not reading articles before posting about them.

 

Make a proposal, no?

It's grant you increase volume more max.

Nope. If you compile with less functionally for smallest size it can be useful.

On GitHub already this issue is.(Oh, make a bug report so hard...)

And in Godot 4 GDScript become more fast and stable...

Godot 4 fix it, and 2D in Godot faster than in Unity.

Oh... I don't know what say.

 

No.

People are looking for engines that work right now. An engine where you first need to "join the club" and then actively participate in its development and fight for having things you want accepted or implemented is something that right now is not quite useful.

 

It's also a completely arbitrary language compared to C#. Unity was smart enough to let go of UnityScript and let C# take the lead.

What does this mean? I see this argument all over the place. How is it faster? And why???

 

When dealing with 2d or pretty much anything, unity is going to have more middlemen than a framework written purely in C++. Basically, in terms of performance, you'd have something like Python > C# > C++ simply due to the choice of language, and compensating for that gets progressively harder.

Here's the kicker, however. By that logic, the fastest framework would be pure libsdl, and not godot, and trying to maximize performance woudl mean if you work with Godot, you wouldn't want to touch GDScript.

The other thing is that less flexible framework with less features tends to be faster.
For example, if you implement UI, you can implement layout mechanism to correctly resize it.
OR you could slap a fixed alpha-tested image and render labels at fixed positions. And that will be the fastest solution.

On related note random people angrily defending godot is the reason why I really don't want to ever touch this engine.

 

Exactly this.

I gave the engine 3 tries over the past years, and can't see any advantage over Unity other than it being open source. Yet people keep defending Godot and their insanely slow dev team with unreasonable arguments.

People are praising Godot 4 and the new Vulkan renderer since 2019, yet it's 2021 now and there isn't even any alpha version available today.

The C# support is still experimental and has many issues, inconsistencies and other shortcomings that it's nowhere near production-ready.

And there are also so many more smaller cases where Godot just falls behind.
Just take the missing DirectX support for example: DX11 applications will run on Windows 10 without GPU, as it has an integrated software renderer which works perfectly fine for Unity apps. This even allows you to start a fully rendered editor on server machines without any GPU installed. Good luck trying such things with Godot.
Or build obfuscation. Just use Obfuscar or a solution from the asset store to make your builds harder to decompile. There isn't anything close to this in Godot.

Where exactly? CPU? GPU? Both? Anything else?

Godot C# is about 10x faster than GDScript. And Unity C# with IL2CPP is still about 2x faster than Godot C#, so I highly doubt that Godot can beat Unity on the CPU part.

For the GPU part Unity has URP now, and even a specialized 2D renderer for it. It's a lot faster than the old, built-in renderer and supports many new interesting features. After testing around a bit it looks like Unity is pretty equal to Godot in that point, getting CPU-bound long before it matters, at least in 2D games.

Physics maybe? Godot has Godot Physics (2D and 3D) and Bullet (3D), while Unity has Box2D (2D), PhysX (3D) and some new DOTS options I didn't test yet. (Unity Physics and Havok?)
Unitys Box2D implementation has (experimental) multithreading support, making larger simulations possible.
PhysX seems to be GPU-accelerated and is faster than both available options in Godot. (At least on my machine with a Nvidia GPU)
Another argument on physics that comes to my mind is the simple fact that you can easily mix 2D and 3D in Unity. You can use full 3D rendering and simple 2D physics components for slightly better performance in Unity. (This works the other way around as well, if you need 3D physics for 2D rendering for some reason...)
Godot simply can't mix them, and has completely different coordinate systems for 2D and 3D space, creating artificial limits and making it less universal.


In conclusion (and to get back to the actual topic a bit): If you just want to play around, learn more about engines or whatever, feel free to take a closer look at Godot and how it works.
If you want to make a fully functional (commercial) game right now however, use Unity. It's simple, well supported and has a big community. It's a lot more universal, fits almost any usecase and takes a lot of work away from you automatically if used correctly. In the long term I'm pretty sure that you (and even more important: your players) will have a much better experience if you just use Unity.

 

https://github.com/svprdga/godot-vs-unity-performance-benchmark about 2d performance

 

Whaaaat.

 

[QUOTE"DiamondStudioGAMES, post: 6711826, member: 3706688"]https://github.com/svprdga/godot-vs-unity-performance-benchmark about 2d performance[/QUOTE]
I simply don't understand how that user got 6,100 3D cubes until a frame rate drop and then a mere 1000 bi axial objects. There isn't a separate engine for 2D in unity. Not to mention that really isn't a valid test I think. Nobody should ever have so many rigid bodies in any scene rendered at once!

Honestly, considering the games that have been made using unity: Hollow knight, cuphead, dragon quest 8 for smartphones, ori and the blind forest etc. Made me want to just stick with unity since those are the kinds of games I wanna be making.

 

This test barely tests instantiating simple but separate objects: draw calls (eventually dynamic instancing) + simulating thousands of dropped physics objects.

It's far from any proper performance benchmark...
What about compositing a scene with many 2D layers? Performance of skeletal animations, lighting, particles, transparent objects? Comparison of tools used that artists/designers might use to construct and optimize scene?

 

Spoiler

 

Thats a really inconclusive test, and pretty much proves nothing as others have said.

Also, the fact that you were surprised by unity having a specific 2D renderer, makes me think you should not be defending engines vs other engines. Its best to do that if you know all the facts, to prevent spreading of further misinformation.

 

Just ignore it. I spent a couple minutes checking out the code and it's very amateurish. It's simply instantiating a prefab repeatedly until it reaches the point that it isn't capable of maintaining frame rates (on a related side note frame rate itself is a poor way to determine performance - you should be using frame time instead).

Game objects in Unity are resource heavy which is why if you need large numbers of them (without resorting to extreme measures like DOTS) you should instead have ONE object that acts as a manager that calls the following API to do the rendering of the objects its managing. With this approach you would very easily get into the tens of thousands if not more.

https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstanced.html

 

I submit proposal, maybe they add it.

 

Ok we may use Godot Servers. https://docs.godotengine.org/ru/stable/classes/class_visualserver.html

 

See, this is one of the reasons why people aren't in a hurry to try the engine. "proposal" and "maybe".

This kind of feature should've been in the engine starting in the very first version. So someone who needs this feature will be forced to make a fork, and then spend time getting their patch accepted into upstream. And given that the project is non-profit and community driven it can be easily be turned down for weirdest of reasons.

So, why bother with this kind of hassle when competitors already have this available?

 

That's pretty much the only performance test I can find relating to godot vs unity

It's definitely an interesting point to make. Even that "performance" test, there's a video about that on youtube and almost everyone there is pretty much "This isn't fair we don't know what his settings are, Godot is much better than unity" mentality. I saw a couple comments saying the opposite. Really makes me curious lol what's there to gain, or could it be exactly what you said, so community driven that they desperately need developers to think it's the best tool around because they need more hands on deck to get things done? Unity definitely doesn't have that problem.

 

Just be aware that Godot's VisualServer like Unity's DrawMeshInstance is very much the simple solution that has limited application. While it may have added complexity Unity's DOTS is far more powerful and can create insanity like the Unity MegaCity demo which has millions of objects, hundreds of thousands of audio sources, and can be run on mobile devices. To my knowledge none of the competition has an equivalent to it.

https://unity.com/megacity

 

(opinion)

When you're in your teens or relatively young, participating in an opensource community can grant feeling of belonging/camaraderie/etc. You're doing the right thing/making the world better, etc.

That can be addictive.

Also it may result in you being attached to the project, which is a bad thing.

Spoiler

source: https://theoatmeal.com/comics/design_changes

The problem is that if the project is driven by a core group, and that group got attached to it, the project might stop being a tool and turn into some sort of object to be protected. "How dare you to imply there are flaws". Basically, that's tribalism.

Likewise, changes brought in by an outsider that hasn't been approved into the inner circle can be turned away simply because the person is not the part of the circle. "He's not one of us, he's trying to corrupt the project, he is not worthy" .

Mind you both of those examples are EXTREME scenarios at the level of exaggeration, and they're by no means common. And it is not like you'd get exactly this wording. But similar thing happens.

One example of a project community being extremely defensive is Godot. No idea why. Or why godot is even special. If someone wants opensource, there's Ogre framework which has been around forever, then I think Irrlicht isn't dead, and if someone can tolerate full GPL engine, ID software released all their past engines, I think even including Quake 4. Xenko also made an appearance a while ago. Apparently it is called "Stride" now. There's also cocos2d... or whatever it is called now.

One example of a project where core developers are acting weird is Makehuman. Those guys are on crusade against perspective camera, even though it is an extremely useful tool when you're trying to match model against photograph (Basically, a photo is made with a perspective camera, and you need to spin the head in perspective model while modeling, and make sure it looks good at all angles. Trying to match ortho projection with a photograph may result in box heads and alien faces with widely set eyes). Then there's voodoo with license requriements of produced models.

I think those kind of behaviors are part of some inherent human trait. Forming a "tribe" around something than fending off the enemies.

The thing is those traits are incredibly annoying to deal with.

At least that's how I see it.

 

You can already implement MegaCity in UE4. Especially if using instanced static meshes which you would use either way to easily manage such an amount of meshes in a huge, procedurally-driven city
Although UE5 promises that we can have hundreds of thousands of draw-calls as it would be processed on GPU. No bottleneck on CPU-GPU communication

"hundreds of thousands of audio sources" just sounds nice in marketing. No game would use so many active separate audio sources as it would be insane to mix it and... pointless. The rather project-specific audio manager would play a limited number of audio sample types around a listener. Just moving audio sources for these samples would be enough.

Managing hundreds of thousands "target points" in the world is totally doable in any C++ engine where you can use a data-oriented paradigm anytime. Obviously, DOD is nothing unusual in C#, but perhaps the performance of raw C# sucks?

-----
Anyway, I guess people love Godot because it's open-source... Although it gives them zero advantage. Any public engine provides full source code, some of them don't even charge for it.

While open source license makes it difficult to include proprietary code right in Godot... This itself eliminates Godot from professional use if someone does work on anything different than mobile 2D.
https://docs.godotengine.org/en/3.2/tutorials/platform/consoles.html

And part of their explanation there is so silly...

LOL, creating games for PC and mobile also requires specialized hardware... "Regular individuals"? So hobbyists and "true indie" that don't even own a company allowing them to easily ask Sony/MS for devkits?

Probably no problem for guys who founded Godot. I heard one of them owns a porting house which now helps you with porting Godot to consoles. For money
Although I can't find confirmation for that info now...

 

Open source projects rarely come out of the gates guns blazing. Blender, for example, spent years being seen as a mere curiosity by most people, but the project just kept on chugging and now has become a noteworthy contender in the content production space. Will Godot follow a similar trajectory? It's hard to tell, but right now it's still far from being competitive outside from hobby projects.

 

Godot's license is MIT, meaning you can mix it with anything and can turn it proprietary, if you're so inclined. Now, you won't be able to DISTRIBUTE it with a proprietary part (but only if proprietary forbids emebdding/redistribution, though), but you can fork it and link with proprietary code and keep it.

Opensource licenses that cause problem are viral ones - namely GPL, and CC-SA.
For example, using opensource Quake 4 engine in a commercial game would be quite complicated, because it is GPL.
Likewise you would have hard time using Adobe FBX sdk in blender, because Blender is GPL too.
And you'll be unable to use GPLed code in proprietary projects (Unity/Unreal)

However, MIT/BSD/ZLIB licenses are compatible with pretty much anything.

By the way, blender was originally a proprietary commercial software.

 

Godot too.

 

There's no mention of that on wikipedia.
https://en.wikipedia.org/wiki/Godot_(game_engine)#History

In comparison, here's Blender history:
https://en.wikipedia.org/wiki/Blender_(software)#Release_history

Started in 1994, made shareware, then rights for it bought out by Blender Foundation.

 

Have any source about this?

 

No. Blender was originally developed to be a commercial product before the company went out of business and sold the project to the open source community, but Godot was simply an in-house game engine that was never available commercially outside of the company.

https://www.blender.org/foundation/history/
https://godotengine.org/article/first-public-release

 

Sorry, get it.

 

I think, Godot may be better than Unity in 2D. But, in 3D, Unity better.

 

You can think that, but it doesn't make it true.

 

Yes, that's why I use "maybe"

 

I'm weird too. how is Godot faster? What is the evidence?
I before to like Godot too, but not now. I have to admit, Unity is better than Godot.

 

Well, Unity (contrary to what is popularly said) is mostly a 3d engine than a 2d engine but even with that in mind, godot is far behind unity in 2d. Also, you do not have to worry about the future of unity, it is a strong company with the bigger comunity in game devs. This days are not the best for unity because they are trying to change their path to something (i believe) more useful for everybody and they are having some hate from their own community (mostly for user who think made games is very easy) but i think unity's future is very strong, do not worry, keep working on your project with patience and of course always use creative ways to solve your problems

 

Godot is mainly developed by two people (Juan Linietsky and Ariel Manzur), and Unity is developed by the company.
So it's normal for Godot to be behind.

 

The fact Godot is often discussed vs unity is probably a sign of an incoming shift in the market if Godot happen to mature correctly and solve the pain points of unity.

People often misunderstood how fast market shift can happen:

 

"If".

The graph applies to situation where technology is successful. The graph also works the same, if the target market is small. For example, ten people.

 

Personally I judge a product's success by the quality of value its service provides. Unity's community, UI, workflows, tutorials etc. are just a lot more advanced than Godot. Unity also wasn't in the business to compete with other game engines - they are focused on a lot more than just Games, which I believe is their true quality and over all superiority. Just comes across more professional and organized than Godot. I felt like Godot's real competition was Game Maker.

 

Godot 4 in a year or two might boost its usage once their C# implementation gets fixed up and they polish up their new systems to a production ready state. There's a small but dedicated community already. And Godot devs are fixing real game developer problems at a decent pace. Progress in Unity land is ever so slow.

And Godot has a real advantage of having one tool per thing instead of 3 or 4 text engines, 3 UI systems, N amount of graph tools each with their own UI/UX, etc. The editor is incredibly easy to extend for your own tooling.

And it also has source access. The benefit of not having to pay for the source access or expensive seating licensing eventually is bound to win out for smaller teams. Although you still can't export to consoles and need a publisher for that, so the financial gains sorta level out if you want to target those platforms.

So Godot could end up being a real Unity competitor (at least in 2D space). But in those couple years, Unity's many forever in preview packages might finally get stable releases and existing "production ready" packages might finally get basic frequently requested features. Only time will tell. Unity's been dropping the ball on their 2D feature set, especially 2D lighting. The 2D teams seem to be understaffed in general.

It also remains to be seen how many packages lose any kind of development effort like Probuilder & Co. Unity might end up being a wide graveyard of "supported" but basic skeleton packages that can't be used past the prototyping stage.

 

Exactly. Whenever these discussions come up the people favoring Godot will often point towards the potential that it currently has and the future of the engine but they almost always fail to mention the potential of Unity. Two devs simply can't compete with hundreds of developers.

 

In the light of the recent Unity news of various kind, I took a closer look at Godot.

It's C# support for gameplay logic is solid now, but editor support is far from Unity's level. Can't export any custom C# types to the inspector. You have to use Godot's custom resources, which are still dynamically/loosely typed and have to be selected from a long list manually. Custom resources also only support base types. Extending the editor from C# is also practically unsupported. And while Godot can serialize a dictionary (also C# dictionary) to the inspector, unlike Unity, that dictionary is still loosely typed without the ability to enforce strong typing as far as I can tell.

The profiling tools are also piss poor and you basically have to rely on external tooling such as Rider. It's very hard to locate non-obvious bottlenecks.

There's a lot to like in its simplicity, lightweightness, common pre-built tools like a ready-made tweener and (limited) hot reload. But it's not there yet, not even close. I can see why the engine is popular for gamejams, but shipping is a different matter. It's not impossible, but Unity is in a far better place right now if you want to ship commercial products under strict timelines.

 

I'm planning on taking a look at it too but I'm waiting for Godot 4. Last I looked at it was in the early days of Godot 3 and like you I wasn't at all impressed. If the next major version fails too I'll likely just ignore it for good.

https://godotengine.org/article/dev-snapshot-godot-4-0-alpha-1

 

They do this via so-called "third-party" company which ports Godot to consoles. The problem is that Godot co-founder (Ariel) is the one who does these so called "third-party" ports of Godot, so I find it impossible to say that they are "third-party", but actually first-party. Ariel is part of Godot PLC (Project Leadership committee) who manages all donations coming from Patreon and other ways, which goes against Software Freedom Conservancy mission. Having said that, Ariel must not represent Godot PLC for this to be truly legitimate.

So yeah, I'd say that you'd likely have to invest a lot of money into Godot if you're going to use Godot to develop games for consoles.

As for 2D, Godot looks like an attractive tool to use at first. I've been working on a 2D game with Godot for almost 3 years straight, but figured that Godot's architecture is too simplistic for my task (imagine making a clone of Worms: Armageddon). Simple example of such limitation is Godot's custom shading language. It's very difficult and in some cases even impossible to do multi-pass shaders (for terrain and such). Rendering to a texture is cumbersome since you have to create a Viewport, attach it to the SceneTree, then create a ViewportTexture for it etc. I have not much experience with Unity now, but my presumption is that you could simply use RenderTexture which is very handy.

So, looking through the Unity API, it's quite rich compared to Godot even for 2D. I have no clue why I haven't picked Unity in the first place. I guess the only reason why I picked Godot was due to my inexperience and the permissive license. The fact that Unity uses C#, I think I'd become a better and more valuable programmer on the market by now. Honestly I got tired of waiting for Godot (I've been waiting 5 years, can you believe this?!)

And this "simplified" architecture in Godot is what limits Godot to become on par with Unity. So I honestly think that these two engines are not really comparable. They say "eventually", but that's only to attract Unity developers to Godot.

 

Yeah, Godot's render texture workaround is notoriously hacky and is also a primary contributor in why working in post processing is so bad. On top of that, because of how it's set up, trying to implement features such as dynamic motion vectors and other things that might rely on render targets is basically an exercise in futility.

 

I mean you are comparing amateur to heavy weight champion.

if you just want to get work done go with the champ(s).

If you want to build and contribute to a growing thing that may someday become champion, that's awesome. But making an engine and making commercial games I doubt anybody has time to do both.

 

Exactly. I used to believe in Godot propaganda, unfortunately. I've learnt a lot with Godot but it's time to move on. The problem is that I see people suggest to switch to Godot here on Unity forums as an reaction in the recent events with Unity, which is ridiculous, so I decided to bring my perspective into this. Do not fall for hype, I've learnt this the hard way. I'm actually an ex-contributor of Godot itself so I know exactly what I'm talking about.

I mean, I'm not against open-source or FOSS ideology in particular. But with Godot, the idea of FOSS gets exploited, so people waste time and energy on a product for free with unclear vision and development philosophy. If you really want to pick Godot, I suggest to stay away from Godot's developer community at the very least, because Godot is the most hypocritical open-source project I've ever seen out there in the game development field.

As I've been working on my 2D game with Godot, I've found myself contributing to the engine rather than working on the actual game, and I slowly abandoned the development of my own game, which is really sad. It's fine to help others, but not at expense of your own goals (unless helping others is the ultimate goal in your life).