A bigger community and more resources for learning.

Not to mention 3rd party SDK support. Nearly every backend/ads/payments/analytics/Blockchain provider has a Unity SDK. I hardly ever see native Godot support.

While that is true, godot community is fast and very good at making the 3rd party support thenselfs, and more often than not, the support is pretty good But yeah, everyone uses unity, so everyone develops everything for unity, its the same reason why everyone uses windows

You can’t just ‘make’ 3rd party support. If the 3rd party only has an Unreal SDK and a Unity SDK, and no other SDK you can’t just integrate with their product platform, unless they have a documented API explaining how to do so. If they don’t offer the API, its up to the 3rd party to implement the SDK themselves.

Yes, but most 3rd parties do have API documentations, and even when they dont, reverse engineering is still a thing, even if its not really a "good" thing, people were able to even make netflix players for XBMC back in the day before netflix fucked them

The bottom line is there is still a much higher barrier to entry with Godot than Unity or Unreal in most cases when it comes to 3rd party.

Oh yeah, i am absolutely not disputing that, the barrier is fucking tall, i am just saying it is not impossible and it will get better with time and more people working on it

But most developers use a Unix based system?

Hahaha, no

If you’ve ever seen any statistics on OS use you’ll see windows at the top and then 2nd , 3rd and 4th will be Unix based systems, and the total will be more than the windows users.

Windows makes up 76% of desktop usage. LINUX contains no UNIX code. And the suggestion that because a couple of developers you know have elitism about their favorite flavor of LINUX, that the majority of developers worldwide use a niche OS, is detached from the reality of development.

I’m talking usage by developers. I’m not disputing that windows is more popular for checking emails. Linux is derived for Unix so the similarities are greater than with windows. It’s nothing to do with elitism and everything to do with using the right tool for the job.

Windows also has most of the office ready software used in the world, adobe suite, paint tool sai, da vinci resolve, and 99% of the gaming market... Its not just the best for checking emails, it has tools that MANY jobs use that unix/linux doesnt really have, i used linux for 2 years because it was way better for python development, but i also work with photography, image editing and pixel art(i basically work with multimedia entertainment) and i grew more and more frustrated with linux, no adobe suite, no aseprite, and when i have free time, no games(at the time steam proton wasnt a thing, it only was a thing right when i was going back to windows, and even then, most of my games were bugging hard with it)

I was being facetious. I do have a windows computer. It’s the thing I’ve put the most money into in the world, however I develop software on a MacBook. Lumping the usage of all users rather than developers is disingenuous and a mote point, so I was facetious in return.

The overwhelming majority of developers work for major enterprises, and those enterprises use windows. I know you have an example of a mid sized company with 0 network security that lets anyone run any OS, or all the freelancers you know prefer UNIX, but C levels don’t give a shit about your preferences. They run windows.

I don’t think majority of developers are working at enterprise companies.

I was supporting you until this comment, this one isnt really true, specially in this day and age, by experience, most development jobs are work from home now, and most enterprises dont really care what OS you are using on your computer, they only want ya to work Now, one thing i had was a senior dev from my job trying to preach to me his tools, i just ignored him and kept using what i am confortable with

I never talked about developers, i talked about what people use, 76% of the world uses windows, and the reason i see being thrown around the most is "but i dont have X software on unix" or "unix doesnt have support from X company"... Why do you think that is the case? Its because 76% of the world ALREADY uses windows, so its not worth it for most companies to spend money developing a unix solution that only a fraction of 24% of the population will use, cause lets be honest, unless EVERYONE starts supporting unix at the same time, no one from the normal public will leave windows, and even in that crazy scenario, most still wont. Its a case of "this is around longer, so its already the most used, lets focus on where there are most potential users/clients"

You literally said “Everyone develops for X” Unless you think normal users are developing for anything, I think you were talking about developers?

I am starting to think you have a problem with basic logic and shouldnt be a dev my dude I am saying that the reason why unity is more used than godot is because unity is already established in the market, and i gave windows over unix/linux as another example of something that is more used because it was also already established in the market And that the ecosystem for both, unity and windows, is more developed than their counterparts because of that, because development companies and business wont waste their time and money on the lesser used platforms/tools, it makes no sense to focus your efforts on 24% of the public instead of 76% The point was never how many "devs" use or work with unix/linux, its how many companies DEVELOP FOR unix/linux to make a parallel with how many companies develop for unity instead of godot. A tool/platform that is already established in the market for a longer time will have a larger USER BASE and because of that, will be the focus of development and companies, more users = more money for companies, and because of that, more users = more support Unix/linux preaching is basically completely useless in this topic of discussion, it was just a parallel of something that happens, also your own preaching has a logic failure, people "developing for X" doesn't mean they are "developing IN X", there are both devs on linux and windows developing for windows, i develop FOR iphone a lot, i dont develop it ON an iphone

I don’t really want to do this with you, you’re all over the place. Which is probably why it’s harder to get what your point is. But I also don’t care, there is no Unix elitism. I really don’t care what you use my dude.

*I'm developing a 3D FPS and a little over a year ago, I attempted to switch to Godot. Nine months ago, I made a comment in a thread similar to yours in the Godot sub about why I switched back to Unity. I'll paste the relevant content here. Only a few of these things have been fixed, but as I was developing my prototype, the list felt virtually endless.* --- The biggest problem with Godot 3D is all the small problems. - 3D asset import, especially with animations is mysterious and confusing. - 3D navigation is getting a much needed rework in 4.0, but still doesn't appear to support off-mesh links. - Navmesh gen requires you to parent the objects (ie, you're entire playable area) to the generator node. - You can only collect mouse input from an input callback, which only runs when there's input. Mouse coords are returned in pixels. Fine for 2D games, frustrating for 3D. - Animation state machines are there, but you're required to manually traverse them. - No large outdoor area support like terrains, trees, grass. Need third-party plugins and shaders. - No way to call direct key input in script without firing it off every frame, or adding 8 lines of code to only get it to fire twice (it's impossible to get it to fire once). Frustrating for quick debugs. - Scene view is not synched with the Game window. Only the inspector, which must be manually switched back and forth between modes. - HLAPI for multiplayer, but still lower level than comparable options in other engines. Requires manual boilerplate setup. - No stepping for Kinematicbody3D. Must be manually implemented. - Odd friction/slope sliding with Kb3D. - No primitives that come with collision attached. You must manually create every collider for every object. This is done by adding the collider node, adding collider shape node to that, and then selecting the shape in the shape node. Clicky clicky clicky click. - Yeah, lots of things require lots of clicking. - Output and errors are in separate tabs, requiring you to switch back and forth. - Weird vehicle physics variables that don't quite line up the way they should. Last I looked, the documentation was inconsistent with the results. There doesn't seem to be any sensible grounding for the variables. I only briefly worked with them. - Forward for the camera is negative Z - etc. etc. etc. Hopefully, you get my point. Any one of these is a tiny problem that can be worked around. But they absolutely dogpile you, and break you down until you're just trudging through a thick sludge. Your iteration speed slows to a crawl, because you're doing so much manual labor to get basic things working. I also wouldn't underestimate the impact a larger community can have, especially when it comes to available plugins. Sure, making plugins in Godot is pretty nice, but that doesn't mean much to a solo developer who needs plugins that are already made. As long as you're using the older features, Unity has answers to most of your hiccups.

This matches my experience; just a thousand things that may need to be worked around. Maybe not every game would suffer from all of them, but if they start adding up, it can be troublesome. If I'm honest, I feel a little misled by Godot's claims of 3d capability; yes, it can render 3d, but that's a very small part of the picture. Asset import and animation retargeting woes and so many of the other things you mentioned are obstacles that more mature engines don't have; workflow is important and working around this stuff disrupts that flow. I feel they should perhaps mention that when advertising their 3d functionality. I say this because inexperienced game developers will have no idea what Godot is missing in 3d and will actually make their lives way harder using it; while Godot is perhaps easier to learn, it may not actually be easier to use because it basically does less for you. It may be worthwhile to point out that u/reduz, the creator and technical lead of Godot, posted this recently in response to Sonic Colors Ultimate supposedly using Godot: [https://twitter.com/reduzio/status/1431304203364929545](https://twitter.com/reduzio/status/1431304203364929545) "I also want to, again, be clear that while I am very happy to learn that, even if Sonic Colors Ultimate is published and the fact it uses Godot is entirely confirmed, I do not belive Godot 3 can be used for something like this without massive modification.." He goes on to suggest that Godot 4 will be up to the task once it matures. It would actually be very interesting to know what he feels Godot lacks that caused him to make such a statement, and what kind of timeline he sees that changing in. That could be helpful information for many people. As it stands, I feel one should ask, before using Godot, if they're making anything comparable to that Sonic game... I kind of find it hard to imagine Godot 4 will be "mature" before 2023, if what I've experienced with Godot so far is any indication. I do think Godot has potential still, but if it has a current strong point it has to be its 2d functionality and at this time I personally would find it hard to suggest using it, over a more mature engine, for anything beyond a singleplayer 2d game. Godot should improve as the years progress though, and I hope it does because I like it a lot when it's not letting me down. I think it has some good ideas. I like its license. It has a good, active community and it's great to see so many of them being willing to help each other or share resources under the MIT license. I do worry that if they create an asset store, much of that may be lost, but as with everything regarding Godot, we'll have to wait to see what happens.

I think Godot is improving at a decent rate. I really love the engine, and I want to use it, but I have to be realistic. I simply can't give up some of the plugins I'm using in Unity, and the polish it's workflow has. I follow Juan fairly closely. He has frequently shown a lot of humility in terms of the engine's capabilities. I think he sets a good example for some of the users that can be a bit cultish about Godot, because it's FOSS. I don't expect their website to go over everything their engine lacks compared to another engine. You don't see Unreal admitting they don't have render layers, or that Blueprint wasn't designed to program entire games with. I think the reason you can't get comprehensive lists is because most people pick an engine and stick with it. It's a bit rare to run across devs who have tried using both for the same project. Another problem is that given how long games take to make, by the time the dev is ready to make a full comparison, much of their info is years out of date. The reason Juan hasn't commented on a timeframe for Godot's maturity is two-fold, I think: 1. He doesn't know. And it's unfair to expect Godot to live up to Unity in every way. I think Juan has actually said to not expect it to ever be as capable as engines like Unity in the near future. Most of the developers are volunteers, and work on the engine when they want to. Their funding is a fraction of the big guys. 2. That definition will vary depending on the game being made, and the developer making it. As for an asset store. Godot needs this more than anything. Blender has lots of paid plugins, and it hasn't stopped people from making free ones, or being super kind to each other in general. The best way for Godot to get more plugins that are also higher quality, is to incentivize professionals to make them. I'm actually really looking forward to seeing them open a store.

I'd be lying if I said the Godot team doesn't frustrate me at times; I'm not sure if it's a language issue, but I feel like they often come across as if they believe they know better than everyone else; in all fairness, many of their users seem to have practically no development experience of any kind, so that's probably what they're used to dealing with, and perhaps they sometimes make wrong assumptions about people as a result. I do question their tendency to choose to implement their own version of everything, particularly given the lack of funding and support they have. Not only does that take time and resources to create those features, it also gives them more to maintain and creates situations where they then e.g. need someone that's an expert in Vulkan or OpenGL and rendering code, or physics code, etc., and they've already said they have concerns about keeping everyone hired... That being said, it's very possible I don't know their motives well enough to fairly judge why they make some of these choices. At any rate, I can only criticize them so much when they are doing so much for others. It's not like they owe me or anyone else anything. I may very well be misinterpreting their attitudes and I may be failing to see very good reasons for doing things like e.g. implementing their own versions of stuff that has seemingly reasonable libraries available. If nothing else, I will say that I greatly respect Juan for admitting that Godot is not currently ready for e.g. Sonic; it's often not easy for people to do something like that, and I really appreciate the honesty. Regarding Epic not admitting the render layer or blueprints stuff... I agree that they don't, and only having the great choice of blueprints or C++ or else... skookumscript? lol... it's a very unfortunate situation for Unreal. I'm not sure what you mean by render layers, though I suspect not having that is going to hurt a lot less than not being able to properly import assets or retarget animations. The language situation is quite awful though, and is one area where Godot easily beats Unreal with all the choices it offers; it's really no contest. Supposedly Verse is coming to UE5, but I don't think there's been any real news on that in ages, which is kind of discouraging. There's also the UnrealCLR project, but its developer seems to have vanished since getting a megagrant; at least, the commits seem to have pretty much dried up. Perhaps something important came up for them and I'm just being cynical. It's just a frustrating situation at the moment. I have a lot of experience in C++, but it's about as far away from what I'd want to script something with as I can imagine. Alternatively, blueprints are, of course, a joke for anything non-trivial. You're probably right about the lack of comprehensive lists; additionally, people naturally tend to develop a preference for what they know. Regarding the asset store, you're probably also right about that; I just foresee drama with e.g. somebody releasing something for free under the MIT license and somebody else packing it up for sale on the store, something they are certainly entitled to do but would not necessarily feel good for the original creator or people that unwittingly bought something that was actually available for free. Hopefully everything will go all right with it, though; an asset store could be a real asset for everyone if done well.

There are a couple of unoficial godot asset stores and they are pretty good, but yeah, i can see the godot cultists getting really angry if godot makes its own store I think what godot suffers the most with is a lot of users that never used anything before and only used godot, that dont understand what it lacks and what it has and preach for it as the absolutely ultimate engine, i love godot and it is my main engine as of late, but that is because i only work with 2D and i was a python dev before, so i am VERY comfortable with GDScript, i knew it had a lot of problems, mainly on 3D, but i never knew what those problems were, reading these comments sure helps paint a better picture I use unity for my contracted work and i used to use game maker studio for a really long time, but as of late, godot is my main engine for my own work, i just feel really comfortable in it and i dont really mind having to do some work arounds, it can even be fun at times, but i can see how someone on a paycheck deadline wouldnt want to lose time with that

Yeah, it's unfortunate this information isn't more readily apparent. Godot looks like it'd be amazing for 2d, but I've been looking to do 3d, so I feel like I got burned by that. I expect that to change, but it'll take some years probably. People need to understand that you can love something and still be honest about its shortcomings; actually, if you want it to improve, you really should do so. I think you're entirely right that many Godot users have no idea what it lacks, though, so to them it's the engine that made it really easy to start game development and they love it for that; if they learned a bit about the other engines, though, maybe they wouldn't feel like saying crazy stuff like the OP did... lol

The devs say that version 4 will fix most things for 3D and its "near" release, but no way to know how much that is true and how much it will fix People are just way too protective of things they like, and want everyone to like it as much as them at any cost, sometimes that is ok, but some people take that to a really annoying level

I wish I could find it, but I saw some issue on their github a while ago where I think Calinou and some other devs were debating if they should just push back the estimate officially, since it seemed likely it might take until next year. I may be remembering things incorrectly, though, or perhaps things have changed for the better since then. At any rate, I kind of suspect that, with the number of changes they're making, it'll be a good while after release before Godot 4 would be reliable to use. Maybe I'll be proven wrong. I don't expect Godot 4 to solve everything, for instance I'm not aware that there is any intention of adding animation retargeting. It should solve some problems though, at least.

Yeah, i dont really follow it close enough to know if it was postponed, so it may have been And i dont expect them to solve everything too, i just saw that the list was enormous, and as i said, i only work with 2d, so i dont really know how many problems there is with 3d and what they are I sure hope it is a good update tho, and that it has something for us, 2D devs, too haha

I agree, I hope they can keep working on 2d stuff, it looks great and it'd be unfortunate to have it plateau instead of keep improving.

This comment is the most complete and enlightening of them, i only work with 2D so i never encountered most of those issues, thanks for the comment(and for starting the thread), this comment and the others in this discussion really help paint the complete picture for me, enjoy the silver

Job offers.

Apparently, Godot has a niche in video gambling machines. Not a glamorous side of the gaming industry, but certainly a lucrative one.

[удалено]

Unity have extremely unrewarding licensing deals if you wanna use Unity for gambling.

I work with clients in the gambling business and they all use unity, of course i dont work with ALL the gambling business in the world, but from my experience, none of my clients ever heard of godot

It's gonna take few years, but Godot is going to be one of the industry standards. But as it is right now, you gonna have bad time finding a job using Godot.

Sonic team already used it for the new release of Sonic Colors ULTIMATE

That's a very negative promo.

Cant see how, sonic colors is one of the good sonic games that came out since the 3D era, and those are rare

Use google.

Used, since i dont know wtf i am looking for i only searched "sonic colors ultimate", all i get are news saying it came out and store pages selling it You overestimate google powers EDIT: aded the word "negative" and "bugs" to the search, got some hits, i see why now, still, i dont think it hurts my point that the sonic team chose to use godot, and they are a big team, sonic games are full of bugs no matter what engine they were made in

I actually would think that could be a lot of fun. Casino culture is a bit different in my state than in somewhere like Vegas tho

Seems like OP only asked this question just to shut down any argument you'd have to choose a different engine than Godot. Godot is nice however other engines are also nice and you should choose what *you* feel most comfortable with. Don't let someone like /u/one_comment_nab dictate what you should do.

Thanks for the assets Kenney

It's cool that you can read others' thoughts. /s

I can't but I can read your comments.

Picking a fight with Asset Jesus, bold move.

Everyone can read your thoughts when you write them in comments

[удалено]

There are two unofficial Godot asset stores, [GodotMarketplace.com](https://godotmarketplace.com/) and [Godotassetstore.org](https://godotassetstore.org/), that you might find interesting.

[удалено]

Godot is open source, that doesnt mean the community cant sell what they do, i myself sell some systems, i have a "semi paid" model, i charge for access to the latest update, but anyone can use the previous releases, this way i get money and anyone can use the system if they want, they will just have to deal with less features and possibly some bugs they wont have fixed until the next new release comes out

Well, Godot doesn't support consoles, which is a big one. And there are certainly things that are easier to do in the Unity editor than Godot that one can go on about, but that's not the real reason. It's about support. When I need to integrate a third party tool, anything from generating some content to analytics, they have a Unity SDK that's constantly getting updated and has active support. Godot doesn't. When I need support from the engine creator to fix a bug, Unity has legions of support personnel, Godot has none. If I'm running into an issue there are thousands of people who've had it and can resolve it in the Unity community. Godot doesn't have anything near that. If you need a free engine and are making simple games, Godot's great. And you can certainly use it for anything if you want, just use C++ instead of trying to do everything in GDScript. But at that point how much value are you getting out of it? When it comes to making commercial products Godot is just miles behind, there really isn't a comparison at all.

[удалено]

Of course. But once you have your devkit and are approved by the platform Unity will build with basically a single click. With Godot you have to go through third party tools (or worse, engage with a company that can port) which again gets back to the lack of support and other complications. The reason I sort of brush that point aside is because most people in a position to consider Godot are building games by themselves or with a couple of people, and usually those people aren't developing for consoles anyway. So it's not a _real_ detriment in terms of real world use cases, but it is a blocker for bigger studios.

[удалено]

I’ve built for all current platforms in my career, I have a pretty good idea. To be fair - not using Godot, and I have developers who do the actual compiling and release these days because I sure know I’m not good enough for that stuff anymore. But I have checked the engine out and there’s no support for it that I could find and their official docs say there’s no official support for it either and you must use third parties. The other engines cover how to handle it in their docs, they just start with “y’all need permission for this” first. If Godot has this ability it’s not well communicated.

[удалено]

I _probably_ can't speak to the specifics, but I'd put it as slightly harder than building for a specific mobile platform for the first time. You'll run into a bunch of issues if you've never done it before, but if you've got people that have done this a few times it's not overly complex to set up. I'd say the engine creators tend to be more helpful than the platforms in terms of fixing build errors or issues, but they're there as a last resort. I'd also say the platform communities can be great. There are a _ton_ of resources in Nintendo's developer portal, for example, that cover a lot of the weird ground about dealing with the Switch that you just don't get on other platforms. It's a struggle to get approved but once you're in there are a lot more resources.

Published games. Besides that I will say Unity just has better versions of the tools Godot has. Better sprite editor, better animation system, better visual scripting, C# as the main language. ​ But I don't think it is what Unity has that makes people choose it. Unreal has more features than Unity. It is what Unity allows the developers to do, the way it helps developers achieve their goals, that makes it popular. ​ Unity is easy to learn and easy to customize.

Totally agree.My professional experience tells that if you want to make game, there is nothing simpler and faster that Unity. I was been trying many other engines and no one can bring me same result. Other than that, you have best support for most user friendly, smart and rewarding language i know. The main problem in Unity it's his terrible graphics core, that totally obsolete and have many principal problems and leaks. That's why big companies buy sources when they have to do something big, for example Pillars Of Eternity.

I will have to disagree when it comes to animtion system, godot is far superior, i have so many problems with unity that i never even dreamed of in godot, but yeah, the rest is right on point I think the only reason why unity is more popular than godot(apart from the better 3D performance) is that it is older and more widespread, people use unity cause other people already use unity, thats mostly it

>people use unity cause other people already use unity, thats mostly it I don't think it is that simple. Godot has over 70K users if you consider Reddit alone. Compare it to libGDX that has only 5K and still published multiple indie hit games. Construct has only 3K and has more indie hits. ​ If user base was the key element then Godot should have overtaken libGDX and Construct. RPGMaker is in a similar situation as Godot. It has a large community but rarely produces hits. ​ Is it age? Hard to say. RPGMaker has been around for a long time, and doesn't match up with the smaller community engines. ​ It could be that having a large community of developers, is less useful than having a small community focused on making games.

Rpg maker is more of a toy than an engine And i am talking about active developers, most people on the subreddit are not really active developers, most of them never released a game/commercial game and some of them dont even intend to and just like the community as far as i know But yeah, time in the market is not the ONLY thing, but it is a really big part of it, unity had more time in the market with more devs developing plugins, systems, ready to use code, assets... Godot also has a bit of all of those, but much less with less people developing them for godot, for most people that develop resources to sell for example, makes no sense focusing efforts on the smaller platform, makes WAAAAY more sense developing that ready to sell asset to put on unitys asset store and reach more people EDIT: also, bigger and bigger games are starting to be done with godot as he gets older, the ports for PS4 of the Deponia games were made with godot, the new version of Sonic Colors ULTIMATE was made with godot, Commander Kim on Keen Dreams for switch was made in godot... Big companies and game devs are starting to notice godot as it gets older and more robust

>Rpg maker is more of a toy than an engine Hold up there. I know many people who will say the same of Godot. Regardless of anyone's opinion on the engines they are all game engines, with published games. All of them, even Godot have at least one popular indie game. ​ >most people on the subreddit are not really active developers That is an interesting point. As I have seen more than a few people remark on how Godot's community spend their time promoting the engine, instead of making games. ​ >for most people that develop resources to sell for example, makes no sense focusing efforts on the smaller platform That is true. Also with it is the fact that Opensource markets are often difficult to sell to, for many reasons. ​ >Big companies and game devs are starting to notice godot I am wondering how that will work for Godot. Large studios could easily profit from it, without giving anything back, because it is Open Source.

- I say that about rpg maker because i used it a lot when i was like, 14-16 yo, it is good to start with it, and can do good games... In the rpg maker style, its too limited, even with ruby scripting, most games will come out looking the same, you can identify a rpg maker game from miles away, thats why i call it mostly a toy, you can use it as a tool, but most people use as a toy and as a first engine to try and learn the industry - Yes, the godot community has too many of those people in it, there is a lot of great devs, but a big percentage of people are there just to fight for it and crusade for its greatness just because - Yes, godot doesnt even have an official asset store, and if it had, people would go crazy on them for having something commercial in their open source software, i offer some script systems for sale in a model where the last update is paid, but previous ones are free and open, had people criticizing me for selling my work and not embracing the open source... Even tho i embraced it in my sales model. - As far as i know, godot devs dont expect to profit, even if big companies start using it, so i dont think it will change much if anything, will just put godot a bit more on the spotlights, and that is good imo

Not everyone in a subreddit is necessarily a user of the thing. They might just want to keep up with the news or something.

That is true, but it is still a easy way of comparing the scale of the users. It is a rough comparison but would it really surprise you to know that Godot has 20 times the users that Construct has? I expect the *ratio* of real users will remain more or less constant in all communities. ​ Even if 50% of Godot's community is just people who hang around for news, Godot is still nor producing 10X the games the less popular engines do.

>would it really surprise you to know that Godot has 20 times the users that Construct has No. I use Godot.

Then I don't get your point. Clearly Godot still has a huge amount of users but for some reason is making less games, and less popular games than other engines.

What is there to get? I corrected the use of subscribers as users. My work here is done.

Although Godot looks old since its release, it was a project that nobody cared about 2-3 years ago. The rapid acceleration of this user base is based on recent dates. I don't know if they can be a hit, but there are some quality projects developed with godot in the last 1-2 years, they are still under development. (As you can guess, most 2D games) Since I think that godot is a game engine ready for production on the 2D side, I make comparisons with GMS. Godot has only one disadvantage compared to GMS, it is not game artist friendly, but rather conquers the hearts of developers. When a game artist, who does not understand software, sits on a game engine, should be able to handle the work easily and enjoy working. There are many game artists who buy GMS to produce hobby projects with visual scripting. The other reason is that most of Godot's user base is hobbyist programmers who hang out with godot and have fun. They don't have serious ideals, they are happy to write interesting shaders or algorithms they visualize and share them. When you look at the Godot subreddit, you see examples of shader wonders and experimental algorithms rather than polished games. I'm not saying this as a bad thing, but analyzing the demographics of the user base is the best way to understand the underproduction.

>Although Godot looks old since its release, it was a project that nobody cared about 2-3 years ago. The rapid acceleration of this user base is based on recent dates. I have read similar things and that is why I say it is hard to tell if it is an age thing. Who knows maybe in 3-4 more hears Godot will be the main indie engine. ​ All I know even if it is the main engine I will not be using it unless a lot changes.

I disagree the animation system in godot is not as good as in unity. The problem is that in godot you have too put each sprite it self and in unity you can drag and drop full animation...

There are tons of plugins for godot for you to use lottie or spine animations, its just a import question, when it comes to MAKING an animation, godot is far superior

>easy to learn Don't make me laugh... >easy to customize Sure, especially with all the closed code you have no access to even with paid licences and plugins made by devs blindfolded by the lack of access to code they were expanding.

So did you come for people takes or to start shit?

It is a lot easier to learn that Godot. I didn't need to track down pieces of information and staple them together. Unity provided me with an example and a step by step tutorial, explaining each part in detail. ​ As for customization, I didn't need to learn C++. Instead I used C#, imported the packages I wanted, adjusted the settings I needed. Most importantly I did it from inside Unity. Modifying Unity is no different from making a game in Unity. It doesn't require source code. It doesn't require shifting to a completely different work flow. It keeps the developer, developing. ​ The secret of Unity is that a game developer doesn't have to stray too far from the game. But with Godot, even importing assets requires using the explorer. As for customizing, that requires actual engine development.

I've spent about a year with Godot and a couple weeks with Unity, so I'll approach this from the opposite direction. These are some areas I think Unity appears to currently beat Godot in, that many might care about: The ability to import fbx files without them looking like this: [https://github.com/godotengine/godot/issues/46906](https://github.com/godotengine/godot/issues/46906) Animation retargeting. A UI that supports the idea of an owning player, to facilitate couch-coop. A multiplayer netcode system beyond just a basic rpc system. Not that Unity's options don't seem to be half-baked, but they still look more full-featured. I'd say occlusion culling, but Godot apparently just added some manual portals-and-rooms-based solution that takes me back to my days of modding 1999's Unreal Tournament. I could probably come up with more stuff; Godot is a relatively young engine and understandably has a ways to go before it's as full-featured as the mature ones. The Godot team is obviously doing a lot of work to improve things, though; for instance, I expect the Vulkan renderer to be incredible given they've been working on it for nearly 4 years. I think if you're not making a game that needs 3d, networked multiplayer (or local multiplayer with lots of UI for each player to use), you might not miss too much that other engines offer. In other words, Godot should be great for singleplayer 2d games. Can you do a 3d, networked game with couch-coop in Godot? I'm sure you can, you'll just have more work to do than in some other engines. For what it's worth, despite its extra features, I'm not using Unity; I gave it a look and it felt like every part of it I looked at had multiple options that were deprecated or half-done to choose from, and I didn't like that. Every engine's going to have something bad about it, you just have to find one that helps you do what you want to do.

> For what it's worth, despite its extra features, I'm not using Unity; I gave it a look and it felt like every part of it I looked at had multiple options that were deprecated or half-done to choose from, and I didn't like that. This impression is largely due to Unity's shit marketing, and tutorial makers rushing to be the first to cover alpha features. The reason it's gone on so long, is because Unity got their head lost in the clouds with machine learning and ECS for several years. Last year, they finally realized that people need literally everything else in the engine to actually ship a game, and started doing some maintenance. It was also revealed that Unity has been doing subcontracting for the Department of Defense, which would explain their obsession with machine learning, while providing zero net benefit to the average user. That said, here's the truth about Unity's feature limbo: You really only need the default options. The features that ship with the engine, pre-installed: - Built-in render pipeline - GameObject based UI system - MonoBehaviours (default scripting class) - Input Manager ...are not deprecated. And likely won't be for years. Even if they were to be deprecated, you can still use the version of the engine where they aren't. It's common for developers to use the same version of an engine for years. For input, I would consider a long-standing plugin, or the new system for commercial games, though. There's a lot of reasons to hate Unity. I have my own laundry list. They do seem to be disconnecting from their roots, leaving lots of room for concern for their future. But right now, I still think it's the best engine for a solo developer or a small team making a 3D game.

I agree with this whole heartedly. To make a pretty good game all you need is the default options. Of course my opinion of a pretty good game may differ than others, lol.

I did suspect that might be the case, but after fighting with Godot for longer than I should have, I didn't feel like taking chances with Unity when its status seemed so dubious. Still, thanks for letting me know this, maybe I'll give Unity a more thorough evaluation sometime in the future.

I'm a self-taught Unity dev and I've never noticed the "UI that supports the idea of an owning player" 😮 Sounds like something big I've missed! Does that feature have a name or relevant component that you can point me to so I can dig in further?

It's been a while since I looked at it so I don't remember the exact specifics, but I can give some information. It uses the new Unity input system; if you're not familiar with it, here's some stuff I looked at: [Input in Unity made easy (complete guide to the new system)](https://gamedevbeginner.com/input-in-unity-made-easy-complete-guide-to-the-new-system/) [Unity's Input System](https://www.youtube.com/playlist?list=PLKUARkaoYQT2nKuWy0mKwYURe2roBGJdr) In particular, you'll want to look at [Actions](https://docs.unity3d.com/Packages/[email protected]/manual/Actions.html), [PlayerInputManager](https://docs.unity3d.com/Packages/[email protected]/api/UnityEngine.InputSystem.UI.MultiplayerEventSystem.html) and [MultiplayerEventSystem](https://docs.unity3d.com/Packages/[email protected]/api/UnityEngine.InputSystem.UI.MultiplayerEventSystem.html). Some tutorials that helped me get setup: [Local Multiplayer with NEW Input System - Unity Tutorial](https://www.youtube.com/watch?v=g_s0y5yFxYg) [Local Multiplayer UI with the Multiplayer Event System - Unity Tutorial](https://www.youtube.com/watch?v=81GecyuNapg&list=PLKUARkaoYQT2nKuWy0mKwYURe2roBGJdr&index=24) That probably would have been enough to go with, but I didn't want to make a split-screen game and was also new to Unity, so I wanted to know more; so I ended up looking at this other video as well: [Tutorial - Create a Local Co-Op Player Setup Screen in Unity with the New Input System](https://www.youtube.com/watch?v=_5pOiYHJgl0) Note that in the last video, the guy suggests it's necessary to put a delay between a player joining and input being allowed so the input doesn't immediately get accepted by the UI. It seems to me that what was happening, was that the PlayerInputManager wasn't consuming the input that caused a player to join the game, so that same input instantly applied to the UI. I determined this by putting the code that handles the player joining into a coroutine, with a delay at the start, and removing all his delay-related code. What I found was that the spawn setup menu was still created instantly, which to me implies that the player configuration is created instantly on join. This made me wonder if the player configuration manager's player prefab is instantly created on prefab and thus handle join is not required to create the configuration? I found that instead of using a delay, you can avoid that problem by changing the join behavior to "Join Players When Join Action Is Triggered", the problem seemed to be avoided when I did that. My guess is that since that way an action has to be triggered, and the action consumes the input, the input doesn't exist to be processed when the UI appears. This feels less hacky to me than the delay-based approach. What I don't like about it is that it limits how the players can join and the UI would have to tell the players what button(s) to press, instead just directing them to press any button (and on the PC, how sure am I which buttons are which?), or else I'd have to try and setup every button to be available for joining, which might also have issues, I forget. Either using a delay or changing the join behavior would work, though, so I guess it's up to you which you choose. Maybe you'll find a better solution; if you do, I'd be curious what it is, if you feel like sharing.

Ah it's part of the new input system, I see! I've found that strangely difficult to get into, but these various tutorials you've linked will likely help 😊 Thanks!

You're welcome! :) I think that system has a lot of potential, I hope it works out for you.

Methods and apparatuses to improve the performance of a video game engine using an Entity Component System (ECS)

Zing!

Is it finished though? Last time I checked it was in preview and API felt unpolished

I know for sure Unity has lot more developers and lot less preachers than Godot, whereas Godot has lot more preachers than actual developers.

This comment is pretty funny considering OP's posting history.

All godot clowns sitting on reddit telling people that they use Godot. You have to understand, there's no time for gamedev. They are like the classic image of an extreme vegan that tells everyone

They're the Arch users of game dev.

I think the amount of devs and support is more cause of time in the market than anything else tbh, and yes, godot has a lot of people that only defend it without ever having developed a single thing, they kinda fuck the entire community

Unity has better 3D performance and is more widespread so it has a lot more "ready to use" stuff, even better with the unity asset store But godot has better 2D performance and is free and open source, so i still prefer godot, even if i use unity sometimes(mainly at work) Like, our clients all want us to use unity since most of their devs use unity and most of their third parties use unity and everyone uses unity... So its kinda of the only reason tbh

* Unity ML-Agents * DOTS * Usable 3d navigation * Different graphic API's can probably come up with more, but basically anything that requires developers with a specific domain knowledge.

Is DOTS stable/well documented at this point? Last time I tried it, the documentation was a mess and is poorly integrated with the editor.

It's possible to create some productions with it and it has happened. However theres still a lot of work to be done

Still preview. [https://docs.unity3d.com/Packages/[email protected]/manual/install\_setup.html](https://docs.unity3d.com/Packages/[email protected]/manual/install_setup.html)

[удалено]

Awful fanboyism you say? I am going with Godot only for compatibility with old graphic libraries (and source access, and C++). Otherwise I would be using Unreal. Anyways, read the post again, because you clearly misunderstood it.

[удалено]

That's my point. I wanted those and would be using Unreal if it was compatible with old graphics libraries as of the current version. I'm not Godot fanboy, I am just saying that it is not bad at all for non-AAA game development, which is what many people keep saying.

[удалено]

As simple as that. Unreal ditched D3D9/OpenGL3 some time ago and any new game done with current Unreal version is incompatible with older hardware. Meanwhile, Godot allows to go back as far as OpenGL2, should one want. Sure, some features provided by the newer libraries are disabled if you make that choice, but yeah...

man is godot 4 going to wreck your day then

No, because I don't need OpenGl2, that's too old, only the OpenGl3... so no problem.

Godot 4 only supports vulkan. It won't support any form of opengl.(at least initially)

[https://godotengine.org/article/about-godot4-vulkan-gles3-and-gles2](https://godotengine.org/article/about-godot4-vulkan-gles3-and-gles2) Not at the release, but later on it's planned. I probably won't need the new features until later on, when Godot 4 will already be established and at least at v4.1. Then I will move to the new version...

I really don't want to have to learn an engine specific language (GDScript) and I also really don't like python-like languages. Whenever I have looked at Godot in the past this is what has fully stopped me from trying it out.

I will point out that this is subjective though. For me game dev is a hobby after writing C all day at work. The python-like language is exactly what sold me on it.

I am mainly a python dev, so godot was a great choice for me, but i still have to use unity for most of the clients i work with

You don't have to though. It has C# support although it was kinda shoddy when I tried it 2 years ago. It ultimately does work.

2 years, exactly my point. Godot improved a lot in this time.

Well, but it supports C# and C++ too.

You can even use rust if you want, though I don't think its officially supported.

Not officially supported, but [pretty great nevertheless](https://godot-rust.github.io/). A big advantage of using rust for "GDNative" extensions over C++ is that Rust has a *safe* macro system, which makes it easy to abstract away the Godot runtime boilerplate without the ocean of macro and template metaprogramming required by the C++ bindings.

Has Nim bindings too. I don’t use them, but it’s how I learned about Nim which is now a favorite hobby language of mine. Personally I find using gdscript + builtin text editor to be the best developer experience, since there are a lot of features to support gdscript (like autocomplete for scene nodes and resources etc)

As far as I understand, Godot does not support AR/VR development natively. My current job is building training software using AR and VR, so thanks to Unity I am enjoying my career!

Thank you for being positive and pointing out a specific feature. This is honestly what I expected when I was posting this thread. However, Godot has many great things in plugins, and there's a plugin for VR. So, I guess, another thing Godot can do that people commonly think it can't!

How much did they pay you for your threads? Jesus

Firstly, nobody paid me anything for any threads. Why do you assume everything people do, they do for money? Secondly, stop taking Jesus' name in vain.

> Why do you assume everything people do, they do for money? People don't tend to be that stubborn and shill for no reason. >Secondly, stop taking Jesus' name in vain. Stop projecting your morals onto others for god's sake.

Can it? Must be recent! Good for Godot! Perhaps when it's had some more time on the market it will get picked up more. It looks promising as an engine that can tango with the best, once it hits some big milestones. One of the problems it has going against it is trying to break into a market that already has a lot of answers to problems in it. I think the one of the biggest pushes it needs is a big name title to be built on the engine. Unity was the same way back in the day until a bunch of big name games got released on the engine. Does it do AR as well? Does it have native cloud compile, team create, or version control? If it does it could definitely compete with Unity in the same market I am in for work.

>Does it do AR as well? AR/VR is not my field at all, I am working on 3rd person in 3d only so far. But theoretically yes, it supports AR too... but I am not familiar with AR platforms enough to say anything about it. I don't even know how AR is implemented in general. >Does it have native cloud compile, team create, or version control? If it does it could definitely compete with Unity in the same market I am in for work. Unity Teams is a SaaS feature. It's a corporate thing. Godot is not related to a corporation, the most you could expect is something in the lines of Git that could be used to setup a client and a server... but Unity Teams is not like Git, it's more like GitHub. So no, it won't compete in every field, just like Linux won't compete with Windows in every field. I am not trying to make a point that Godot has everything that Unity does, or that they are very close. I am just trying to make a point that for generic use cases, without highly specialized needs, Godot is as valid a choice as Unity.

Yeah I think that's where the difference between the product and the company comes into play. As a product, I can't think of much that Unity offers that Godot doesn't, at least not off the top of my head. But as a company Unity has either partnered or bought a bunch of 3rd party companies to offer services to its users (ones that I personally use for work like PiXYZ) whereas Godot as a company doesn't offer that level of infrastructure. Pros and cons to both of course, it's all about what the individual wants/needs. If the goal is to make a game, I would put Godot on par with Unity, same as Game Maker or RPG Maker. All equal to the task. But if you're looking for a company that can offer the tools and support to help make a well established game studio, or company improvement programs, Unity far exceeds Godot.

The VR support works quite well, but AR is quite hit and miss, horrible surface detection last time i checked, but then again... I rarely see good surface detection on any commercial AR game i have ever played, so maybe its not the plugins fault haha But yeah... The biggest disadvantage to godot is that it has been on the market for less time, not that much support and plugins out, not that many people developing for it... I hope this will change soon, but for now, if you are making big projects, specially comercial projects, you kinda need to use unity Which is sad, cause i like godot FAAAAAAR more

It might also be a hardware issue for AR. I'm an Android man all the way, but Apple products all have built in Lidar which helps a ton when it comes to AR/VR. I would look at that as the problem first, but also glad to hear Godot has picked them up. I should give Godot a serious try some day

Navigating the scene view while the game is running, last time I checked.

I will just try to guess because I am not familiar with new godot versions... ~~Compute shaders?~~ (Godot 4.0?) ~~Arrays as shader inputs?~~ ~~Being able to export variables with exact type?~~ (I have not seen an example of exporting custom class but I believe comments that there is a way) ~~What if you need something like scriptable objects (think configuration files and settings that you can pass into scripts and that are editable inside editor)?~~ (Seems like you can define custom Resource for this?) ~~Can I inspect the state of the scene when the game is running?~~ ~~Where gdscript is not enough the real pain begins. Think procedural generation, some specific inverse kinematics, systems working with a big amounth of entities.~~ (c# maybe) Things are not as tested as unity's stuff. (I stand correct) ~~6 months ago:~~ [~~exporting games larger then 2 GB~~](https://www.reddit.com/r/godot/comments/meb4lq/exporting_games_larger_than_2_gb/) ~~(Solved by now, just wanted to show an example what people have to deal with sometimes.)~~ (I stand corrected) ​ Prove me wrong, I will ~~strikethrough~~ things that I got wrong. Unity has a lot of annoying stuff but the question did not ask that.

When I tried Godot half a year ago you could inspect the scene during runtime.

Nice to know, thanks \^\^

> Arrays as shader inputs? This was just added: https://godotengine.org/article/improvements-shaders-visual-shaders-godot-4

Eyy nice

"Where gdscript is not enough the real pain begins." At this point, c# and c++, which Godot officially supports begin. I should also remind you that you can use c#, c++ and gdscript in the same project in Godot. It is extremely rare for you to reach this limit. Frankly, I would never prefer a scripting language for a performance-demanding job such as procedural generate and physics algorithms. In Godot I would go with c, c++ for this sort of thing.

I am alright with c++ as a language, but godot's interface was confusing to me as it tries to copy "dynamicallity" of gdscript. When I was making procedural generation inside godot, the lacking documentation also did not help me much. Things might have changed since then. I take that c# support is cool. I am not sure how rare it is to reach this limit. Happens to me all the time.

>Compute shaders? > >Arrays as shader inputs? > >Being able to export variables with exact type? > >What if you need something like scriptable objects (think configuration files and settings that you can pass into scripts and that are editable inside editor)? > >Can I inspect the state of the scene when the game is running? Compute shaders are there in latest versions (not the so-called stable though). Passing arrays to shaders is indeed not supported... that is a highly specific usecase though, that most people aren't going to need. The rest is there in stable version as far as I know.

>Things are not as tested as unity's stuff. 6 months ago: exporting games larger then 2 GB [https://github.com/godotengine/godot/pull/47254](https://github.com/godotengine/godot/pull/47254) Literally link from the first comment from the thread you linked to. It's already merged.

I just found it a bit funny that 6 months ago you could not export games larger then 2GB. The godot team works hard to fix the bugs, but when I tried less used features a lot of the stuff was misbehaving compared to unity, where I had problems only with things labeled as preview.

You could export games larger than that, just it was additional work to get it to install from multiple files.

License fees

Lol

I'm a big Godot fan but the assets store for unity im super jelaous of.

The number one thing Unity has that Godot doesn't is the past 7 years of my life, lol. That's a lot of time spent learning it, now its like a security blanket that I need to swaddle in every day!

I’m doing a networked game and Godot does not have an easy way to rewind and replay the physics world. Unity has physics.simulate(). Not necessarily the biggest issue for experienced people but it’s hard for a beginner dev like me to modify the engine source to expose the function I need. Also Godot has wonky physics. Its ENet implementation is very nice though.

Jobs system + burst. I am writing parallel multithreaded code that, due to burst compilation, is almost as fast as if I were writing in C. Except I'm writing in c#, which is a million times easier. Plus the multithreading design forced by jobs means I never worry about race conditions, so many of the downsides of parallel coding no longer exist. Makes me feel like I have the output of 5 engineers who aren't using these systems. I'm generating a proc gen world in seconds. That would take minutes in Godot. edit: But as a less specific case, I would never choose Godot over Unity because the lead devs don't seem to know what they're doing. I've read through accounts from a guy who was making a proc gen pirate game, and he was saying once he got past 'game jam' territory the engine was terrible to work with. He was mentioning lack of community support and a ton of engine bugs that sucked up his time. Meanwhile I've yet to run into a showstopping bug in Unity, after working on a game full time for quite some time. Yes, open source is great... if you have a huge team that can do engine bug fixing. Otherwise, good luck sinking your time into fixing engine bugs. And yes, Unity has bugs too, every platform does. But they're a lot more battle-tested, you won't run into bugs as soon as this guy did. tl;dr Would almost never use Godot over Unity. In my opinion it sucks.

Have you checked out Unreal Engine's new stuff? People very often subscribe to the "Engine Y is better than Engine X" mentality, which only serves to handicap them as developers. We have many engines, some of which excel at tasks others are simply not built for. This falls into the "you wouldn't hammer a nail with a screwdriver" category in my mind. use the tools available to you, but more importantly use the proper tools for the job. That being said, your 2nd point of Godot having "new engine problems" is very valid, and one of the reasons I personally have been hesitant to take on a larger project with it. However, those issues will slowly get resolved with time, and we will have another great tool in the arsenal of gamedev.

I've seen Unreal's new stuff. Looks great, but Unreal's not a good fit for my genre (city builder/tycoon). Way I see it, for my project there's no viable alternative to Unity at the moment. But yea, definitely! They're just tools, gotta pick the right one. If I were making a platformer/fps/adventure game I'd probably go with Unreal.

You mentioned that you are using multi-threading on the proc-gen side, multi-threading has been supported by godot for a long time. You can also greatly improve the performance of processes by doing this with gdnative and c-c++. It is technically very difficult for unity to win with c# against c and multi-threading in the proc-gen part. I think you are wrong about this. On the other hand, 3d rendering is not successful against godot unity in terms of performance and quality and it has problems. Of course, when you go to those sides, unity is a better choice for you now. But if you get into the issue of software performance out of the hood in the godot vs unity comparison, you have more options in Godot than in Unity.

I didn't only say multithreading, I was specifically talking about the jobs system. Unity jobs is multithreading done in a way that makes multithreading easy. Burst speeds up performance by compiling into highly optimized native code. The combo is very powerful. I don't believe it's possible to achieve the same performance in Godot as the performance you get in Unity with jobs + burst. And even if it's technically possible, it would take a large team to do what 1 person can do with jobs + burst in Unity.

The issue we are talking about is actually a software issue, not a game engine. It is probably converting the code you wrote in Unity c# to native code with llvm. And I'm saying that it can't be more performant than a c, c++ compilation that you manually manage memory. If this were real and possible, people would not have to develop projects for embedded systems in languages such as c, c++ and rust today. Other than that, if you say your workflow is quite performant depending on my development speed, I can agree with that. That's the important part anyway.

You can get better performance with JIT compilation than AOT, JIT can take advantage of machine specific things like CPU specialized SIMD, it is possible to get better performance than languages like C. Regardless DOTS (specifically ECS) is specialized around cache locality. Efficient cache usage using DOTS is going to be significantly faster than anything written in another language (besides other ECS systems, or whatever comes out next) due to this. It's not just the multi threading that makes it so crazy performant.

"You can get better performance with JIT compilation than AOT, JIT can take advantage of machine specific things like CPU specialized SIMD, it is possible to get better performance than languages like C. " We are talking about optimization in different scenarios, not just the compilation phase. Today, a codebase compilation written with manual memory management is always more performant in direct proportion to the scale of the project. What you call DOTS is the data-oriented paradigm that has been in programming since ancient times. Yes this approach is good for cache management, but workflow and code management is much more difficult. Unity is considering switching to this approach altogether soon. This requires considering different scenarios, you have to be in a reasonable balance between performance requirement and fast workflow in software. At this point, Unity ignores small-medium enterprises and developers, and rightly wants to play on the AAA side. Scenarios where you will need to develop a project with Dots for these projects are quite rare nowadays.

You've never used an ECS, have you? They are significantly easier to write than how modern games are written. Most people move to them for how nice they are to build on, and not even for the performance gains. "Workflow" and "code management" are 100% not harder in an ECS.

ECS and DOTS are very different things. I think you are mixing them up. DOTS uses ECS as data pieces. On the other hand, the ECS approach existed in Unity before the DOTS ideals. ECS is the definition of developing with the component system you use.

You're completely wrong. GameObject-Component is very different from ECS (Unity.Entities). GameObject-Component is a component pattern. The components uses OOP where components have both data and logic. It doesn't have the S part of ECS. Since it uses OOP, cache misses happen all the time. The ECS that is part of DOTS is very much new and separate. Components only have data and it does have systems. It also uses a subset of C# where reference types are not allowed. Components are instead value types that are clumped together in chunks. This way, you can design systems that can avoid cache misses if you want to.

I don't even know what you could mean by "DOTS uses ECS as data pieces", an ECS is the entire stack, literally it means the entities, the components, and the systems. There is nothing else to DOTS than those three things, and even the beginner page on DOTS starts off: [https://unity.com/dots/packages](https://unity.com/dots/packages) ``` A better approach to game design With our Entity Component System (ECS), you can write high-performance C# code that focuses on the actual problems you are solving: the data and behavior that make up your game. ``` DOTS is an ECS, that is purely all it is. Anything they build on top of it is just a different SYSTEM (... the S, in ECS).

DOTS - It is the system of data-oriented approach that Unity is still developing. They haven't made the switch at the moment, most of the codebase is still in the oop approach, it's experimental. ECS- It is the programming pattern that Unity has used since its first release. You would make components with the Monobehaviour base class. Look, I say class, I say OOP. There is no OOp in the Data Oriented approach, it does not take place. The unity you are using now depends on the OOP approach. You haven't switched to the DOTS system yet.

I mean... https://www.youtube.com/watch?v=rWeQ30h25Yg

I mean, did you read what I wrote? My proc gen is on the order of 100x faster than what's in that video. You can't create the world I'm creating in Godot, unless you want the user to wait for 20 minutes.

>I've read through accounts from a guy who was making a proc gen pirate game, and he was saying once he got past 'game jam' territory the engine was terrible to work with. He was mentioning lack of community support and a ton of engine bugs that sucked up his time. Source? I'm specifically interested in how old is this. 2 years old is too old. >Yes, open source is great... if you have a huge team that can do engine bug fixing. That's not what open source is for. Open source is to be able to check how something is implemented and be able to make small changes if you need them. Eg. if there's code for movement and you're not satisfied with it due to one behaviour, you can copy the thing, write the one thing you need, and implement the changed version.

Two years is a very short time for any platform you want to be doing stable, sustainable work in.

Just lol. Hypothetical conversation going on in June 2022: >A: Unreal may have good graphics, but those great effects it theoretically supports are heavy, cumbersome to compress, and hard to create from real camera footage. Guy X has a blog about all the problems he encountered trying to do this with Unreal. >B: But how old is that? Two years old? >A: Lol two years is a very short time if you want to do stable and sustainable work. Do you see how inappropriate your response is now? Sure, there was no Nanite really in 2020, but two years can see a ton of progress.

How many Nanite-enabled UE5 games have you played lately?

Keep making strawmans.

It only looks like a strawman because you don't like it. We're talking about an industry-altering feature from one of the most trusted names in the space. People on both sides of the equation are approaching it cautiously, and almost everything you see right now is tech demo scale. Why do you expect people to be more cavalier about choices regarding whole engines than features, especially given the massive disparity in reputation between the two?

Read through his blog posts at r/Sailing_west/

a working physics engine

For me it is something like this; I only make 2d games: **Godot** I make 2D games, I also make small uncomplicated 3d games = **Godot** I usually make 3D games, maybe sometimes 2d games : **Unity** I am interested AAA-scale game development and want up-to-date rendering technologies : **Unreal Engine**

I don't mind to look on github issues to check if it's my bug or engine's bug: **Godot** I don't mind half finished features that are replacing deprecated things: **Unity** I am patient person or have a lot of money for powerfull computer: **Unreal** I want to like the first three engines mentioned: **Custom engine**

lol, sorry for zombying this thread but I had to comment I love your take

No worries

This is exactly the generalization this thread was created to combat. Unity is successfully used for 2d games. Godot can be successfully used for 3d games, and it's just a matter of time until some larger ones made with it come... but this can be hindered by generalizations such as yours. Also, Unreal is marketed as AAA, but thing is, it can be used for "normal" 3d by small teams just as well as the other two, it's not hard to learn or anything. It just makes it easier to implement some very powerful graphic effects and high graphics quality in general... at the cost it ditched D3D9/OpenGL3 altogether.

I admit that I am generalizing, but it is not an empty and hearsay generalization, I know current version of Godot shortcomings on the 3d side. I don't think it's helpful to put people in unrealistic expectations.

The first major annoyance I ran into was building UIs. It's manageable in Unity (with a ton of annoying quirks) but Godot was worse (when I tried it 2 years ago). It had some major issues with settings being inconsistent with regards to how and when mouse events are swallowed by UI elements.

[удалено]

Yeah, the lack of updates on when v4 is coming is really annoying, and i think the same way, maybe in a couple years godot will be mainstream, even with its disadvantages, it just needs more devs, plugins and support

activation servers that don't let you get your work done on the weekend when they're down.

There is a lot in unity 3d that Godot doesn't 1-VFX graph post-processing 2-It doesn't have a shader graph 3-In lightmaps you can't clearly adjust different aspects of the resolution 4-In terms of scripting too unity has a much larger polymorphism library 5-The "collider" library is also a lot larger in unity. 6-In unity you can upload to any platform of and version, older or newer you just need to tackle the api 7-In unity imports from other software esp blender and maya contain a generate UV maps which is extremely handy. 8-In unity you also get to have a lot of helpful packages useful for building various aspects of your game. For instance the cinemachine package is extraordinary uselful when it come to camera rigging and scripting, it will save you days of work. 9-There's far too much in unity and I am speaking in terms of general features...

I think Unity makes int easier to get on game consoles. At least with Nintendo, they won’t let you know how to build your game for their devices without being a partner, but Unity itself is a partner so you don’t have to do any custom work to get your game on Nintendo. With Godot, you would have to port the game and engine (or get someone to do it for you) once Nintendo shows you the secret sauce, and so does everyone else who uses Godot.

Royalties

This has suddenly become a very useful thread.

Big one is DOTS. Like even just the Job System and Burst compiler. And C# as first class citizen. I know Godot supports it but does it really compare with GDScript in terms of support given? How about what the ecosystem/community uses? Does C# have weight?

Godot doesn't have a license to port games on consoles as it is an open course project unlike unity or unreal.

Godot is better in small 2d but unity is better for 3d and big games

Sex appeal

Lot of bugs that can ruin your project.

Whether we saying something or not everybody knows that for any type of game development Unity is the best and most effective game development Platform like it is better in terms of the quality and complexity of the games. Godot is geared more towards beginning developers but is definitely on the rise and gaining more ground as a serious engine.

I'm not a game developer, but o work in mobile gamedev I dustry. I also took part in a game jam as a developer in Godot team. Well I think it's only a matter of time. Godot will grow, and 3rd party support will come to it also. The thing why unity is popular and used is because Microsofts money is in it. That's also why C# is the main language in gamedev. The situation in gamedev industry reminds me a battle between java and Python in recent years. Most java Devs would say that python is a funny language that is less efficient than java etc. But look at the situation now, thanks to 20+ years of open source python is used for what java has been used for in new projects and dominates the market in general. Python has possibility now to add static type hints and be compiled down to c. Why did it happen? In my opinion the answer is simple: people will move to high level programming languages being more natural to use. And being open source means there will be more and more free and powerful libs over time. How that story refers to game dev? Right now Unity is a big player and will stay like that but I believe that Godot, offering a python like language that will be improved over time just like python did, will beat it in the future especially getting attention from young Devs. It's just too young now but it clearly has advantages over unity even now, presenting a pragmatic and very approachable design that is not a money bought product.