Thinking about moving to Godot

I know I haven't done anything meaningful with Unity yet, so I probably wouldn't be missed if I decide to move.

But still, I've spent most of my weekends in working on a Unity project in last year while writing quite a lot of posts (for me, that is) in the forum. So I still feel a bit hesitant to abandon all that and start over with a new platform.

Since I heard Godot 3 beta was available with C# support, I've felt intrigued because I love the idea of working on a fully open source game engine. So, I finally gave it a shot yesterday and it (almost) convinced me to move on.

By the way, It's not really a 'pasture is greener' type post, and actually I found it to be quite the opposite. The meadow was a lot 'browner' there, if there was any pasture at all.

It took me more than a few hours just to launch the editor, since there was no binary and I had to build the source while dealing with various problems I encountered during the process. I managed to do it, with a help from custom package definition someone posted on internet, and applying some unmerged changes in the Github repository.

After that, I spent rest of the day to find out how to create an actual project in C# because there's practically zero documentation about it. With much struggling, I managed to write two sample projects for a test, a library and a game project that depends on it. I failed to make the library to work as an actual editor plugin, so I had to report an issue, along with some other problems I encountered during the process.

But strangely, I found that all the struggling I had also felt quite satisfactory in a sense. There's so many things that I'm used to in Unity were missing there. Probably the lack of any character creation asset like UMA alone would probably cost a year to reach where I was with the project I have in Unity.

However, I've been always more interested in writing API stuffs than creating an actual game, and the prospect of trying to fill some of those gaps and having some real chance of contributing to the open source community felt too attractive for me to pass by.

And again, I love working with open source projects. As I wrote above, I had to apply some unmerged changes to the engine source to make it work. And this morning, I found that they already fixed the problem and there were numerous comments on the issues I reported also.

I didn't like the fact that Unity chose to follow different naming convention (class members start with a lower case letter) than is widely accepted as a standard in C#, and I found it to be the same with Godot (platform methods starts with an underscore).

While I can't do anything about it with Unity, I found an open issue about the subject where many people actively participating in a discussion about if and how we should change the current implementation. That's part of the reason why I love open source.

Again, I'm not saying people should migrate to Godot today. If I was a professional game developer, I wouldn't even have considered Godot to be a practical substitute for Unity. Even though I'm utterly inexperienced in game development, I think Unity to be one of the best engines with afforable price from what I've seen so far.

It's just that I found the idea of working on an half finished open source engine to be more interesting and rewarding according to my personal preferences. To reuse the pasture metaphor again, it feels more like a desert in the 'Wild West' than any green pasture. And it's just that I found the idea of moving to the West to claim some vacant land to make my own little farm more attractive somehow.

I haven't yet decided to move though, so there's still some chance I change my mind. Even though it's still in a proof-of-concept stage and not really useful, my pet project in Unity has grown to 300+ classes system over the past 10 months, so I'm a bit hesitant to abandon everything and start over.

Considering the fact that I'll have to reinvent even more, and much bigger wheels in Godot, and that I'm still forced to work on it on my spare time, it would probably push my plan of making my own game someday from 'somewhat unlikely' territory to 'almost impossible' one. But I love the work itself, and who knows, if I could make something useful finally and convince enough number of people to help me...

Anyway, I'll probably still be lurking on the forum even if I decide to move. But I suppose I won't be writing as many posts or actively developing any Unity projects if I do.

So, happy new year, everyone. And hope to see you around!

 

Good on you dude!

 

Sounds like you don't really want to finish your game and just enjoy working on "games related tech", which I can understand. I think you need to ask yourself what your end-goal is and be honest about it to yourself. Maybe instead of working away on your own unlikely-to-ever-be-released game project, you would be better off just straight up working on the Godot source and improving that engine directly, or team up with others that have a clearer vision for their game and more focus on finishing that, so that you could contribute to their project and solve more clearly defined problems.

The possibility-space you find yourself in when making a game is almost endless, and it's a lot harder to feel like you're progressing in the right direction, than it is with implementing more technical "systems" with clearly defined tasks. I'm the same I think, I enjoy performance-optimization more than game-mechanic-prototyping, because at the end one has a number that says how well I did, and the other has mostly uncertainty about whether I'm even moving in the right direction or not, and it all gets somewhat subjective.

Also thanks for the info about your experience with Godot so far. I had considered to try it for something 2D some day, but it sounds like it would definitely not be the right engine for me and I'm reassured to stay with Unity. That might have saved me a few hours or days even, so thanks for that!

 

The tech lure is a game itself really. On Vita I rewrote as much of the Unity rendering as I possibly could and it's so good. Problem is I spent all my time on that instead of making a game and I cannot do both. Doing both is not practical for anyone in 2018. Or 2017. Or 2016 (you get the picture).

 

To clarify, the unstable part is specifically related to C#/Mono binding which will be released officially in the upcoming 3.0 version. Currently, it's available as a beta release and seems to lack many important features to compete with Unity in the 3D department so far.

However, I heard that it's quite capable when you develop 2D games with GDScript which the current stable 2.x release supports already.

I don't have much interest in 2D stuffs and even less experience in actually trying it on Godot, but from what I've seen so far its UI/2D features look to be quite polished actually. I especially like its UI system with built-in theming/i18n support and many useful components.

So, if you are interested in trying 2D game development with Godot, I'd suggest to try it. I don't want to bias anyone in either way with my initial impressions, which I acquired from just a single day of experience.

 

Could your current project in Unity be scoped down to be complete-able in a reasonable timeframe? Seems like a waste to leave it in an unfinished state - with all the time/effort you have put into it, but I'm a sucker for sunk cost fallacy - it gets me every time!

 

This thread reminds me of why I got into the Openmoko Neo Freerunner open source smart phone scene for a while, around a decade ago. There was something really rewarding about loading that half done OS they had on that half baked phone, where really nothing worked, and getting it to work on my own. Writing my own scripts to get the phone to actually connect to AT&T's data network, porting over a VPN client I needed, and writing my own battery level scripts to control the color of the power LED was more rewarding than it sounds. Everything I tried felt like I was breaking new ground, and everything I wrote and shared felt like I was benefitting a community.

In the end though, if you're trying to get a quality game done and shipped you'll have a far better chance of doing that starting from a solid base. If you're not trying to actually get your game shipped, go right ahead and have fun working with this open source engine. Just don't expect to actually ship anything that stands up to games made with the game engine leaders.

 

Simply put, no way The decision to move only made sense because I'm not really intending to make any commercial game, and I like writing API stuffs as much as creating actual end products.

As I wrote above, Godot currently lacks any sort of character customization library (like UMA) and there's no abstraction layer for animations like Mecanim in Unity. I wanted to make a sandbox type environment where you can build your own character, this alone would probably require me like an year to make something that's barely work as a substitue for them on Godot.

But important thing is, I will probably learn a lot in the process if I go that route and enjoy working on it, especially if I end up with something useful to other people with similar requirements.

For the same reason, I don't see work I've done for my current project to be a complete waste. Of course, it's not useful to anyone yet but at least I've learned a lot of things doing so. I didn't know anything about game development or C# but now I feel I know enough to write simple games.

I do agree, especially considering I can only work on weekends and I'm very inexperienced in content creation department.

I suppose the best case scenario for me to ever create a quality game out of it could be making it a popular game framework so I can persuade others to make their games with it. That way, probably I might be able to join their project or recruit those who have skills I lack to create a game I love to play myself. But either way, I realize it'd be a long, long way to go from here

 

I just had an interesting experience with Godot which I think might interest some people.

It could be a 'horror story', or an interesting case that shows how differently an open source project works than a proprietary one, depending on your perspective. So, please bear it in mind before reading it.

When I installed Godot 3 last this weekend, I found that I couldn't even read error messages in the console, because it showed details in a tooltip which exceeds boundary of my screen. So, a long error message basically showed like this:



Of course, displaying detailed information of errors in user scripts is so basic a feature that we can't imagine any commercial game engine would miss. So, probably I guess it could be one of the reasons people should think twice if they want to use Godot 3 to develop their next big games today.

Anyway, I reported this issue on Github 2 days ago and this morning I found that someone wrote a comment with a mock-up screen to address the problem like this:



I said it looks great and about an hour later, he made a pull request with a working implementation which I'm planning to try on my build after I finish my work today.

I suppose that kind of close interactivity and sense of community is why I love open source projects so much. Probably it won't help you make your game faster, at least not at this stage. But if Godot ever becomes good enough to compete with big engines like Unity, I know that it will be only because of such contributions like that and I already feel good that I helped even a tiny bit in reporting the issue.

I won't probably be able to build my dream game with Godot any time soon. But I think I can reasonably expect to learn the engine enough to write some open source framework or addons that other people might use soon.

And I guess that could be a sufficient reason to make a move for me, because personally, I value the latter type of activity as much as the former one.

 

Most of my hangups with games comes when I make too big a deal out of them. If I just think about getting things to work, etc, I enjoy myself a lot more and feel more fulfilled. Godot sounds like a lot of fun. I've taken a quick look at it, but decided to wait for C#. I can't say I'm into engine development, though. I want it to be somewhat workable so I can get on with developing a game. Godot will be close enough when they get c# worked out. Trouble is, I'm just getting used to Unity. The best part for me is that, if Unity gets too pushy, I can always move over to Godot. Unity, though, has so many resources that it's a lot easier to get going on a project and find answers to problems. And you are pretty assured it's going to work on a lot of platforms without hiccups because there are so many people publishing games with it. Not that I care much. As long as I can post a game on Webgl someplace, I'm happy. Anyway, good luck with it and work out those bugs for the rest of us.

 

Godot may one day be good, but sounds like it needs more maturity and full C# integration. Whenever I look at an engine and see some made up scripting language I stop looking - C# is the one for me as it is so mature and skills could be transferred elsewhere.

(Actionscript 3 was not bad, an evolution of js and a lot better than the js mess that web developers have to deal with!
Used unityscript before, but it is a bit of a made up language and compile times go through the roof so glad it is going.)

 

I can relate, since a static type language with strong IDE support is something I find essential for me to enjoy programming. But I thought I'm on the losing side because I see more people preferring dynamic languages these days.

It's not related to the topic, but I predict that Javasript(or ECMAScript, to be exact) will come back to the game development world in next 10 years or so, and probably win over C#.

Back then when people still used Flex/ActionScript, practically everyone hated Javascript. But since then, it became such a monster and practically won the frontend technology war (and even threating the server side languages too).

It means we have a huge influx of programmers who regard Javascript as their first language. It will be only a matter of time they'll be writing browser based games in Javascript/HTML5/SVG/WebGL, and probably game engines will start to support them. If Unreal or Unity won't do that, there will be a new engine to fill in the gap.

And generally speaking, static typed languages like C# or Java are favored among business application developers, but game developers are not known to be a big fan of OOP or fancy design patterns. Many even call such languages like C# as 'script' and treat them as such, so I suppose they won't complain too much if they need to switch over to a real scripting language.

Sorry for derailing my own thread, but I found it to be an interesting subject to talk about.

 

If you like working on libraries and frameworks kind of stuff, I would beg and plead put your time into something more useful then another engine. We have several good ones, marginally improving something we have that works well isn't really even that interesting IMO. I mean if you are going to work on open source, make it matter, make a name for yourself.

If I had the time to work on another major open source project, I'd pick a popular engine to work in and create something that I thought the industry was just way behind on generally. Like terrain architecture nobody is doing that well IMO. Water isn't that far behind.

The need/opportunity in the industry is not more engines. It's secondary stuff that the engines don't usually put much time into, the type of thing that studios are duplicating over and over and not sharing. That's where the interesting stuff is IMO and the opportunity to actually have an impact.

 

Got to disagree and here is why:

In 10 years you'll find everyone is going to be using node graphs, more than ever before:

• cheaper and more reliable than average quality programmers
• can be trained within 2 weeks
• games simply don't require programmers, they require behaviour designers

Let Unity / Engine provider do the heavy programming for you.

You're talking about the game development world. People don't care for more languages, they care for something that has a huge supporting presence on the web and with open source. C# is fast dominating along with C++ (for game development) so why would someone jump backward to javascript type languages which aren't supported with big money or big game presence?

• does not make making games any faster
• doesn't make it easier
• isn't even the bottleneck

Even LUA is falling out of fashion. It has it's uses but letting artists or designers graph out something is far preferable to using LUA or a javascript dialect. There are millions of potential hires that can be quickly and effectively trained to use graphs in addition to their core strong art and design skills... vs only thousands of low or middle competency programmers who will make more mistakes and have zero art and design skills.

Frankly the whole "lets make coding easier" is a fallacy. All you are doing with this is bringing more mistakes into your business, not designing mistakes out. I prefer to have very few high quality programmers versed in C# and C++, and have the bulk of game fleshed out by artists and designers and creatives - you know, the people who should be making the game.

Hardcore programmers should be making the nodes, the systems, the back end. That's my decision for my business and that's exactly what we are doing right now. I don't care about my own personal situation - being biased would hold us back, only what is correct decision for the business of making games.

 

I can definitely see something like this happening.

So much of so many games could be done through automation or reusable code.

For example, there are only so many ways to make an interface or have characters move.

Part of why Unity & Godot are popular is because creatives just want to make games. They want this trend. Granted the coolest projects need some talented engineers like Tarn Adams, those are probably 0.1% of games...even these days where innovation is high.

If it werent for the greed in our overly capitalist gaming industry, I bet we would have already long surpassed a significant portion of the need for programmers when it comes to making non-innovative games (99% of games).

It amazes me there isnt already just one perfect standard. Then again, that would require people to agree. And perhaps also stick to one language or one platform.

 

I didn't understand this comment. I don't recognise or see it myself. I just see the fact that the task has changed to be that we can no longer get enough good programmers and it would be stupid to try. Programmers (good ones) are a finite resource and hard to obtain.

The task has changed in the following ways:

• small developers want to tackle more/bigger content
• larger developers cannot source enough reliable programmers for even bigger content

So games are getting bigger and more ambitious but sourcing decent, reliable, experienced programmers has remained a constant challenge. You also do not want more programmers writing code that can potentially be unsafe. For ambitious projects, graph support is imho now a mandatory requirement, and Unity currently doesn't support native graphs for behaviour (blueprint etc).

I don't see any capitalism at play in this case... anyway going to stop derailing the OP's thread here! he did start this but I don't want to be disrespectful.

 

Thanks! I'm already regretting I started that

As to that topic, I'll just say that I really hate Javascript, so even though I stand by my prediction I honestly hope you were right.

 

The entire industry is effected by profit-motive philosophy.

In an ideal system, you would have cooperation, which would lead to innovation.

There are few quality programmers, so this is increasingly true when theyre further divided by NDA, copyright, restrictions, closed source, and obsession of profits at the expense of innovation.

In a more cooperative system, theyd collectively work to resolve problems in an open source way.

Open source + AAA quality professionals + Teamwork by hundreds of said pro's = Rapid advancement & innovation to allow creatives to create rather than work. Especially when nearly every game is just like the ones which came before it.

Unity is the best we have, and it is faaaaaaaaaar from perfect or optimal. So much so, we have 3rd party asset developers who, in their spare time, put Unity devs to shame with their high quality work & best-selling assets.

In an ideal world, Unity wouldnt exist because we wouldnt need a worse generic game engine that still requires too much reinventing the wheel. We'd have something more powerful than Unity, AAA standard, but with ease of use like GameMaker.

We would also have better games, as trash like Pay2Win or Battlefront2 paid unlocks wouldnt ever exist if quality was put ahead of greed.



Profit Motive Capitalism effects everything in nearly every way. Although there are the exceptions of Indies who dont partake in such greed. That's always nice.

Then again.......LOOT BOXES!

 

I dont think I'd put it like that. Firstly not all assets are done in peoples 'spare time' and I dont think the great stuff some asset store devs make puts unity devs to shame - some assets put particular features of unity itself to shame but I wouldnt pass that shame on to unity developers. Because when things dont go well enough or quickly enough there are many reasons, things that may inflict upon unity as an organisation issues that smaller entities have the luxury of avoiding. eg legacy issues, management issues, scale issues, priorities, culture, mistakes made, mistakes learnt from, mistakes repeated, etc.

 

Are you ashamed when you shop for groceries?

 

I sometimes am when I bought things like pepsi and pringles, while the other persons at checkout bought fresh vegetables and other healthy stuff.

 

Fine, I'll be more direct.
Would you feel ashamed buying something you could not produce?

 

There's nothing wrong with looking into another engine. I've dappled in Godot before, it's pretty solid. And some developers may be more comfortable with an open-source project that they know they will be able to edit and re-compile as needed.

I would caution against committing to using another engine based on future developments and features, though. Changes like those always tend to be unstable. It's better to weigh an engine based on its most recent "stable" version, or an acceptable stable build a few releases prior to the current "stable" build. It's just a much better idea to target one of the more stable, established versions of a software package for production purposes. In the case of Godot, I would not be waiting for the 3.0 release and the promised C# integration for developing a game. I would target the current version for that.

Of course, if all you want to do is experiment with the tech, then that's a different matter. If tinkering is your thing, tinker away.

 

I checked Godot game showcase. 99% of them are tiny 2D arcade games. There is not a single big 3D title in their own showcase list.

 

Were you seriously expecting anything else? For the most part companies want an engine they can hire people for, both contracted and actual employees, and purchase support contracts.

 

Simply put, it's not ready for any serious 3D games and even less so if you want to write them in C#.

So, if you just need a feature rich and stable engine to develop your 3D games today, it'd be better to stick with proven engines like Unity.

Probably, it could be a good alternative to Unity when it comes to 2D games. I don't know much about 2D games, but I can see how some of things like animating images or creating UI elements could be easier in Godot.

So, it might be worth while to try it if you mainly develop such games, but if you don't want to learn another script language, probably you should at least wait until C# support will be stabilized.

The only reason you might want to try making 3D games in C# with Godot right now would be if you feel adventurous and want to do some experiments, or if you want to build its ecosystem together with other community members, for its almost the only viable open source game engine at the moment that has even the slightest chance of becoming something that can compete with commercial engines in future.

On a side note, the issue I mentioned above has now evolved into this, after much discussion among other members of the community:



So probably the right question to ask would be what do you want more, something you can rely on right now, or something you can participate to make it better.

 

What are you talking about? I never stated people should be ashamed for buying assets.

I complimented the asset store.

Ah, I think i get it. By Unity Devs, I didnt mean developers who use Unity. My bad.

I meant Developers of Unity. UT employees who work on the engine. They are put to shame by third party developers who dont have Unity's source but manage to outshine UT engineers. Even the amateur asset developers seem to be able to.

The normal users who buy from the asset store should be proud theyre using Unity's best feature. The asset store is very powerful!

 

UT is not a very well respected company in the dev chatrooms I frequent.

Have you ever seen their source code or explanation of Unity handling Transforms? It is beyond mind-boggling.

Then again, some of the engineers have to work with legacy code that is arguably beyond repair.

While UT does have problems that third party developers dont have to worry about, that is countered by the fact they are fully paid, well experienced engineers with full source code access and deep knowledge of Unity.

There is never any excuse for poor quality in a product. You can excuse them all you want and try to justify Unity's flaws or bugs or horrid performance. It is inexcusable IMO when third party developers with limited access to the engine put UT to shame with a fraction of the resources, closed source, and less experience with the engine.

Any beuracratic problems is the company's issue of incompetence. It isnt an excuse or justification, it would just be a cause or explanation. Part of being a competent company is not letting clueless superiors or corporate nonsense get in the way of quality. Understand your product, your employees, and your consumers.

I have no doubt UT suffers from problems they create themselves, like management issues. However that isnt an excuse. That is just explaining the incompetence.

I dont know anyone who respects UT as a company. The engine? Yes. Certain people in the company? Sure! UT overall as a company? I hear nothing but quite the opposite from others.

 

If I have seen a little further it is by standing on the shoulders of Giants. - Isaac Newton

Sure, there are plenty of valid complaints about Unity. That does nothing to change the fact that their product is continually used to get all sorts of stuff done, successfully, and gives many people and teams capabilities that they wouldn't otherwise have.

If you had the time and resources to do it all yourself then could you do a better job? Maybe. But you don't, so it's moot. Plus, a part of the reason you could maybe do a better job is that you can learn from Unity's mistakes from hindsight, which is something they couldn't do when they built the thing in the first place.

And while you were doing it knowledge would march along, new people would learn new stuff in part based on your work, and some of them would disrespect you for not having known it before you started.

That all said, there's definitely benefits to the Epic method of starting again every few years. They don't have nearly the baggage that Unity has, and they get to periodically take advantage of that march of knowledge.

 

Unity's proving that it's not really necessary to start all over again. Mutating with pus-filled sacs that occasionally burst, slow creeping tendrils that fuse and cocoons all prove it's possible to change with SRP and IL2CPP etc. And Epic didn't really start all over again.

 

Nurgle, please...

 

I didn't intend this thread to be an occasion to bash Unity and I hope it could stay that way.

 

Unity is not perfect, but it's THE BEST. Every single time when I stumble upon some kind of problem is Unity there is a good, elegant way to solve it. Sometimes you have to work "around" Unity's quirks, but it always can be done.

Note that you can always create your own abstractions on top of unity in C#. This means that if you don't like something, you can always "morph" it in your code to fix it. That's because Unity is a relatively low-level engine. For ex. it has meshes, textures and shaders, but it doesn't have models or characters.

 

I'm just saying that Godot is no competition for Unity or Unreal. Nothing amazing has been made with it. Using Unity people made for ex. Hearthstone and Cities: Skylines. This clearly proves to me that Unity is very capable.

 

I think we are all here because we think Unity is very capable.

I'm pretty sure Godot's 2D performance will be less than Unity's especially with physics 2D in 2018 and C# jobs. Some reasons I see people wanting Godot is to completely control a 2D engine or begin building their own 3D engine, but really if you're going to do that, just do that from the ground up - in C# or C++.

Massive modifications to engines aren't why you use engines. You use engines because hey, it's got most of the job done. So people asking for source in Unity typically are wanting to do something Unity cannot do. And there is very little it cannot do. For UE4, source is still not what most people want from that engine. They want the blueprints, the animation physics, C++ or whatever really. Source is for when the engine isn't doing what you want.

If you want to change huge amounts then rolling your own is faster than modding Godot or UE4.

 

I don't think Godot's (and also Unreal's, if I'm allowed to borrow some arguments from another thread both of us participated) main advantage would be it's easy to massively modify them on the source level.

Of course, you can freely fork Godot and modify it to your heart's content, and even contribute your changes back to the community if you like, since it's completely open source. But it's not really a game engine that only engine developers should use. If I ever gave such an impression, it wasn't intended and maybe because I emphasized the open source nature of the engine too much.

Godot is doing many things differently than Unity and some would feel them to be an improvement over the way it is in other engines. It has an innovative scene management system, and its ability to create and apply animations on the fly on various elements. And it has more comprehensive and easier to use UI components than what Unity has with uGUI currently.

I'm sure it has many shortcomings also, but the point is, it's not really different than any other engines in that aspect, so I think it'd be better if you measure pros and cons of using it compared to other engines, rather than simply setting it aside as some toy project for game engine hackers.

 

But for me, this is where it falls short the most.

I haven't seen you list anything that requires source access in Unity so far, nor anything that would actually execute faster on hardware, or be quicker to author. So I don't think Godot actually has any advantages at all except for costing nothing. Sounds horrifyingly fanboy of me but I'm not. I don't have engine loyalty except for my own purposes.

I prefer camel over Pascal, and I understand why Pascal is adopted - you want to know what might be a parameter vs a local variable vs a property, but this is definitely something best left to a house style and not really a factor for engine choice.

It could be you're not that familiar with Unity's capabilities yet.

 

I'm also sure its not unusual for peoples Unity pet hates to occasionally reach a point where they are motivated to look at the alternatives. Fair enough, but that alone is only one small part of a potential journey, and often various reasons not to switch quickly emerge.

 

It could be, but it also could be that you don't know much about Godot either.

By the way, I think I know quite a bit of the both GUI systems that Unity has because I wrote a wrapper API for them. I did it to add theming and i18n support that Unity currently lacks, and also partly because I think it to be quite cumbersome to work with them.

Godot has built in support for those things and provides more components out of the box. Probably, lack of immediate GUI or C# events might be considered a disadvantage, but Unity's phasing out the former for in game GUI anyway and I don't think many would find the latter to be such a big deal and it's easy to solve by adding another layer.

I respect your opinion, and I'd like to emphasize again that this thread is neither an attempt to persuade people to switch over, nor to bash Unity.

But if you claim Godot literally has zero advantage over Unity, or I'm saying otherwise because I don't know much of Unity, I have to suspect you might be partial in this matter.

 

You're right it's likely I'm not familiar enough with Godot. I only checked it out when it became a thing a fair while back, so it could be things have moved along. Regarding Unity's UI - I don't like it at all, so I built my own wrapper in a day. I've stuck with it ever since so I feel properly caught out there

 

Well, if you would like a meaningful pro-con between Godot/Unity fundamentals, I would simply point to the underlying structure of each engine.

Unity is component-based. Godot is hierarchy-based.

Now, neither of these are hard-and-fast rules. There is wiggle room in both engines for both approaches, and often times plug-in developers seek to get around the general structural "thrust" of each engine. But the core principles remain, and are an ever-present influence of design. In Unity, most everything is dictated by a component approach, and going along with that approach usually makes things smoother. In Godot, most everything is based around hierarchal scene management. Just like in Unity, things go smoother when you roll with that inherent design philosophy.

So a persons inclination for one approach over the other is usually what determines how they are going to respond to the engine on a fundamental level. If you can jive with the component architecture, it is easier to get into Unity. If you like the hierarchal approach of Godot, that may be more your jam.

For my part, I like how the hierarchal structure of Godot lends itself to building out detail in smaller, compartmentalized chunks. You can start off with very small details, and work your way up from there. As someone who appreciates polishing elements one tiny bit at a time, this jives with my approach to world-building. At the same time, I recognize that the component structure of Unity is VERY conducive to rapid prototyping and testing. It's great for fiddling with gameplay elements on the fly, and fine-tuning them in a very flexible way.

 

I agree it could be the single most important difference between the two engines. And I think you are also correct in saying that it's a matter of personal preferences more than anything else.

Having a programming background, I found the idea of actually extending a camera rather than attaching handling scripts to it more natural and intuitive, for instance. And it's quite convenient also, especially with the feature that allows you to take any such arbitrary hierarchy and develop or test it on its own.

I'm not too sure at this moment if it would allow me as much flexibility as Unity does though, as a component based system is often regarded as having certain advantages in that regard.

For now, I lack sufficient experience or knowledge of Godot to judge objectively, so I can only say that I agree it's indeed the most noticeable difference that better be considered when comparing pros and cons of the two engines.

 

Some unity components can be extended in the same manner, NetworkManager for instance.

 

Yea, you want Unity source to do what Unity cannot do.

Like achieve a stable, smooth 60fps (which requires Source access).

I trust the INSIDE dev team more than anyone in this thread.



One of the biggest reasons people like Godot is because there is a common theme in UNITE videos for professional developers to basically say Unity sucks (and here's how to workaround it).

As another example in the UNITE talk about "How To Make Multiplayer Games In UNET" as you read in the comments, the answer to that question is "Dont."

Unity is currently working on fixing its hideous Transform code, but that is not yet an update.

Godot is zooming past Unity for a very valid reason. Its highly recommended 2D and low bloat is one reason why. Developers are excited for 3.0.

Give it a few years to update past 3.0, and I can easily see it taking over a big chunk of Unity's share of the dev pie.

Unity has some architectural problems that are difficult for UT to overcome because old code (bad code) can be difficult to fix or replace entirely. I assume that is why (it is not incompetence by choice or gold rush). I can see UT scrapping Unity for a more competitve version of Unity (built from the ground up, reusing newer features & component basrd code) whenever Godot begins to become too big of a threat. But by then it will be too late. Unless that is already in the works with their new "every feature should be a choice you download". New engine but reuse all the new features.

Godot 3.0 is a big deal because it is the start of the end for Unity. Remind me to come back here in 10 years.

 

Doing some things much better than Unity is not the same as zooming past Unity. There are many future possibilities and I certainly see nothing at present that ensures a 'beginning of the end for unity' narrative will be accurate.

Unity got quite a big share of quite a number of different sorts of game development, and quite a large head-start when it comes to the variety of platforms supported. I do consider it somewhat inevitable that it will lose some share in areas where the competition come up to scratch or exceed Unity, but in other ways Unity is entrenched and predicting its severe decline is about as easy as predicting Microsofts - including lots and lots of room to fail and fall and yet still retain significant clout.

 

You don't need source access to achieve a stable 60fps. I'm 100% certain the team working on Assault Android Cactus didn't have it and I'm currently optimising for 60fps as we speak, no source access required.

 

I agree, but also think it depends on the specifics of what you're doing. To hit target frame rates in my current game I re-designed some things to avoid stuff that Unity isn't particularly good at. I have no problem doing that because there is no way I'd be making a game of this scope without something like Unity, so the "compromise" still comes out far and away ahead of what I might otherwise have achieved.

 

As to the possibility of Godot's 'zooming past' Unity, I'd equally guard against being prematurely optimistic or pessimistic of the prospect.

Godot is moving blazingly fast indeed, so there's a good chance that it would 'zoom past' Unity when it reaches anywhere close. But that is, if it can ever reach that point in foreseeable future, and it's just a mere possibility at this point.

Godot is gaining momentum too fast to simply dismiss it as another toy project, but the gap which lies ahead before other commercial engines like Unity or Unreal is too big to be sure of Godot's ever catching up on them.

Personally, I'm on the optimistic side, especially after witnessing with what energy the community is improving its various features and what it has achieved with 2D workflow already.

But it's undeniable that it's quite far behind Unity at this moment (at least when it comes to developing 3D games), and it will certainly take much time before it can catch up. Anything can happen during that time, like key developers leaving the project or some other commercial engine going open source, and so on.

So, probably it'd be best to keep eyes on the project for now, and maybe try it out from time to time when a new version is released without making too hasty a judgement in either way.

 

Godot is not another toy project. But like Ogre3D, our expectations of it must remain soundly grounded in reality. There is a lot of mobility with a single graphics API and limited platforms. To grow it will have to slow down quite a bit. And to be Unity's performance with 25 or so platforms, it gets a bit tricky. You end up needing to hire grunt programmers - unsung heroes that go in the trenches and get the day to day tasks done that absolutely no champion of open source really has time for in reality.

I do not believe it is possible to match Unity without at least a billion dollar's funding. You could beat Unity at very specific things almost for free though. And Godot seems to be doing that.

 

As I wrote in another discussion with you, open source projects tend to rely on quite different conditions for success than their proprietary counterparts.

Donations and fundings from companies surely can help open source projects, especially when they are lead by a very small number of people, but normally the code frequency or number of issues reported by the community is a far better indicator of how much chance a certain open source project might succeed and remain competitive.

Ogre3D project has 163 forks and about 300 issues in total, that is 10 or so new issues per month. Compare that with Godot, which has 2,723 forks and over 9,000 issues so far which include 3 new issues in last hour alone.

So, personally I wouldn't predict how successful Godot could be in future by assuming it'd be another Ogre3D in the long run, as it has surpassed that project by quite a large margin already.

In fact, the project metric of Godot is already comparable or even surpassing that of many sizable commercial projects that I know of.

I have no knowledge of how big Unity's development team currently is, but I'd be surprised if they are doing even just twice many commits daily than what non paid hobbyists of Godot project are doing at the moment.