Thinking about moving to Godot

News & General Discussion
1

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! :slight_smile:

7 Likes
2

Good on you dude!

2 Likes
3

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!

6 Likes
4

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).

6 Likes
5

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.

1 Like
6

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!

2 Likes
7

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.

2 Likes
8

Simply put, no way :stuck_out_tongue: 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 :wink:

9

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:

1919×198 19.2 KB

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:

880×406 21.8 KB

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.

4 Likes
10

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.

1 Like
11

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.)

12

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.

13

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.

1 Like
14

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.

6 Likes
15

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.

16

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.

2 Likes
17

Thanks! I’m already regretting I started that :slight_smile:

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.

1 Like
18

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!

19

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.

3 Likes
20

Are you ashamed when you shop for groceries?