The issue, of course, is most of the people using Unity are using it because they don't have the ability (or time) to write the functionality Unity provides themselves.
There will be higher skilled devs who are using Unity that are appalled by this business practice and will want to move to a more open platform.
Unless there's an incentive for them to share their contributions back to Godot (like a paid plugin store, of which at least one is in development) they won't stay.
I don't know why people are still using unity instead of UE4 except for historical reasons where users of the engine are hesitant to switch and have to relearn some things. Unity is not open source, it does not come with batteries included (so you end up buying a bunch of poorly maintained unity assets/plugins to do stuff that UE4 does out of the box), and I think they're struggling as a company more than people real…
For a lot of us we started with it, and once you know it, if it meets your needs, switching doesn't make sense. Does now though [walks into corner growling] :/
This is why I tend to shy away from proprietary tools like Unity-an event like this is sort of like an asteroid strike, it's improbable but there's no defense against it and if it happens you are wiped out.
Do that, and your game will never ship - because developing your own engine is a beast of a timesink. The open source offerings are toys compared to Unity/Unreal.
How is UE on mid-range and low-end mobile devices? I have the impression that's in increasing important chunk of Unity's end user base.
Unity is huge in mobile gaming. UE4 barely made a dent on mobile until the recent mobile release of Fortnite that is, which requires a fairly high-end device
Somehow I always had the impression Unity was a heavy C# moloch and Unreal was a fast C++ racecar.
This is why I tend to shy away from proprietary tools like Unity-an event like this is sort of like an asteroid strike, it's improbable but there's no defense against it and if it happens you are wiped out.
Do that, and your game will never ship - because developing your own engine is a beast of a timesink. The open source offerings are toys compared to Unity/Unreal.
There are GPL and MIT licensed engines to be had out there.
So right now we know the "what", but not the "why". What Improbable really has, or claims to have, is a way to scale massively multiplayer games where everyone is in the same world. They have a back end which is basically a synching system for small data elements between computers in a data center. Think of it as being like the way a shared memory multiprocessor synchs its memory system. Some data items belong to a s…
The "why" is apparently "so we can capture that revenue stream". They just launched an alpha of a competing service (autoscaling dedicated servers, on Google's cloud) and apparently want to nix the competition. https://unity.com/solutions/real-time-multiplayer/game-serve...
Improbable doesn’t have planet scale solutions. Their most touted title, Worlds Adrift, is explicitly discretized into regions. They use ‘creative’ solutions like ‘impassable storms’ to prevent crowding.
It's likely they have both. What they're shipping right now is the latter. What they're selling to investors is the former. Planet scale.
Why do you think that they have what they are selling to investors?
I think using Open Sourced Engines is the proper response to this. Why reinvent the wheel unless you have your own use case.
Open source engine suck big time, and I'm not even talking about the tooling part which is an even bigger problem, video game engine are usually not something you can do well on your own without large resources.
Oh, come on, how many compute-intensive things you need to do in a game scripting language? GDscript is fast enough for scripting, C++ is there for the compute-intensive tasks you might do (though most of them are already implemented by the engine). C# on the other hand, is to attract Unity users that are too lazy to put in 30 minutes to go through GDscript's concepts. It's OK that it's there, but personally I found…
Performance is a feature. If you want your game to have as large a playerbase as possible, it needs to perform well even on bad hardware. I strongly suspect that most people will write their entire game in an engines default language. Especially in this case where the much advertised best alternative (C#) gives you a warning on startup about not being production ready. Yes, C# is probably integrated due to its succes…
GDscript was created to better integrate with Godot's internals, there is a whole section in their FAQ why they didn't use another language[0]
Warnings for C# are there because it's new, and there is not enough resources to support it better. Also C# is not that easy to integrate as it doesn't have most data structures used in game development, so your own have to be made. In the end it changes so drastically that you might just call it a new language.
Godot is also behind the curve on content pipeline tools. I love it to death, but I would never be able to convince anyone outside hobbyists to use it because it has no goddamn FBX support, or an easy ECS framework.
Native FBX support is not compatible by license, you are free to make a module that lets Godot use FBX, just with a FBX compatible license. Traditional ECS doesn't fit with Godot's philosophy, but you can make behaviors into nodes and just add these nodes as a child for ECS-like behavior. Honestly, I find Godot's way more natural and extendable.
Without a stable and widely used model format making a game is impossible. You can drag&drop FBX into Unity and Unreal, and its mostly ready for use. Having a broken FBX importer is just a waste of time. You start with a model format, something works, you build a workflow, a system for producing content en masse, and then at some point you must consider throwing away the model format, the workflow and/or the whole engine, because the importer is unreliable. Or you try to rewrite it yourself, further wasting time. Some things must be rock-solid, open-source or not.