• General Chat

  • Should I switch from Unity to Godot for 2D Android and iOS games?

Hey guys, I've been using Unity for 1 year to create 2D games for Android and iOS. Unfortunately i don't have much free time to work on my games since I have a full time job. I'm starting to feel comfortable with Unity, but recently Godot caught my interested. Apparently Godot is more intuitive and time saving compared to Unity, according to a few devs on YouTube. That actually sounds pretty awesome, if thats true.  But I'm not sure if Godot is the best Engine to port my games to Android and iOS. I'm worried about the performance, but also i really like how unity handles in-App purchases and Ads. I don't know if Godot can keep up with Unity when it comes to that. I would really appreciate your opinion before I invest a ton of time to learn Godot, just to find out, that it might not offer what I need. Thanks in advance :)

It depends. If you've already spent a lot of time building in Unity (and haven't released yet), you'd have to redo a lot of code to port to Godot. It may make sense to launch with what you have and just explore Godot for future projects. However, Godot is about the most productive I've been in a long time, even after trying Unreal/Unity and various other engines. It's very natural to work, and things mostly make sense.

I wouldn't worry about performance too much unless you are making a serious 3D game. Unreal and Unity do have the upper hand with realistic graphics (in 3D) but you can still make something nice in Godot with a little work. For 2D, I would say Godot is the best, it's very easy to work with.

You can have IAP and ads, but I don't believe they are included by default. However, there are several 3rd party plugins you can use, it shouldn't be too hard (though I haven't tried this yet). But that is one area where Unity may be more robust.

In any case, I would just recommend downloading Godot and trying a simple project like Pong. I think you will see it is very user friendly. The editor loads fast, builds are fast, you can test on mobile and edit things and see your changes on the phone in real-time. It's very nice.

If you've already invested significant amount of time in your projects in unity I'd see them through to the end in unity. Godot might however be a good choice for a future project perhaps. You should evaluate that in the pre-production stage of that next project however.

I played with unity for several months after choosing between it and unreal. C++ and learning C# was not much of an issue. But the demand of the editor/IDE of unreal was too much as I am mainly working from a laptop. 3fps was not tolerable. Unity nominally was much faster, but even then I suffered lagging performance.

The major reasons I switched to godot: open source extending engine easy fast editor was not a resource hog * in-engine scripting a lot less of a head ache than dealing with 2 IDE (godot editor and then Visual Studio)

godot will likely require a different mindset in your coding. nodes are very nice. gdscript however might seem provide OO classes but are not. The distinction is important but not limiting and in some aspects liberating.

One difference with Godot over Unity is all scripts run, even if the node is not visible. In other words, there’s not a way to disable scripts you make like in Unity, you have to instead add conditions to enable/disable your code from running yourself. Its not a huge thing (both have their pros and cons) but for porting code it may be something to note.

@dotted said: godot will likely require a different mindset in your coding. nodes are very nice. gdscript however might seem provide OO classes but are not. The distinction is important but not limiting and in some aspects liberating.

How is that possible? I mean how am i suppose to use design patterns if its not OO?

Under the hood it is OO but far as GDScript goes you are essentially just extending the preexisting classes rather than adding new ones via GDScript. At least that is my understanding of it so take with a pinch of salt...

You can always use godot via C/C++ and add extra classes in source then compile.

@Megalomaniak, @Iboshido

The scripts don't really define a new type in what we would think of as an Object even if 99% of the time thinking this way is just fine.

  • Assignment liberty: You can attach them to any subclass of the built-in node the base script extends from. This is why I say not limiting but somewhat liberating. They are a little more mix-in-ish than type-ish.

  • The scripts can be extended themselves and in this sense script inheritance is oo-ish, but these subclasses still 'duck-type' properties and methods onto the built-in object they are associated with.

  • Scripts can be dynamically changed on a node: Also you can dynamically change a node's script type, changing properties and methods available, by changing the script assigned to it.

  • Using class_name is not 100% like OO. Using class_name in 3.x isn't as always smooth as one hopes. If you define a class_name class A (Foo) and it in turn references class B by name (Bar) and class B references class A, the engine will complain of cyclic dependency issues. This I think is due to scripts being loaded and interpreted before being assigned, and not compiled in a batch then symbolically resolved like C++ etc.

I'm not sure about this. You can create a script class that is not attached to a node and instance that in code. As well as use inheritance. So I would consider this OOP. It is still dynamic, not as enforced as C++ as an example, but you can achieve similar results.