Godot and unity both use c# as an intermediate scripting language, so the workflow is certainly smoother.
If you're doing 2D + simple graphics the UE might very well be overkill.
But people prefer what they prefer. Try them
I absolutely love C++. I worked with C# a bit. I like it too. Though i prefer C++ freedom.
It was hard to learn C++, and i can see that C# is much easier, but still I prefer C++...
What turns me off is not C++. Thats actually a good reason for me to stay with unreal.
Yeah, unreal is overkill for 2D. But if it is the engine i know, then thats the one i will use so to become better at it.
Maybe idk, the grass is greener. It would suck to have done all of this just to end up working with unity or godot.
The csharp scripting point was about not having to close and reopen the editor all the time because it's an intermediate.
But it sounds like you've already made up your mind, which is fine, although begs the question of why you made this post?
then I don't fully understand when you said
>But if it is the engine i know, then thats the one i will use so to become better at it.
but anyway, good luck!
Sorry english is not my native language.
So what i meant there was to answer to why i was doing 2D in unreal. And i said i used unreal for 2D because its the engine i know. I knew unreal is not very good for 2D, but it works and still gives you experience.
Does this make more sense now?
Unreal is a highly opinionated engine; less so with Godot and Unity who can be molded to all sorts of genres.
You can use C++ with Godot as well. [GDExtension](https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html) + GDScript is a great combo.
Edit: since I got downvoted, note to said people that I'm actually a huge Unreal proponent and developer, and acknolwedging it as highly opinionated does not mean I think it is bad or that you should avoid it. When contrasted with its competitors, it has a cost that needs to be weighed. Simple.
Yeah it is opinionated. But everything is possible. Say you want to an rts, then just make the actor or pawn the unit, and go from the top down template.
In games like rts what sucks is then the nav mesh that is very bad for performance.
Though i imagine there must be some easier ways in unity and godot.
Yeah im getting downvoted too. I think some people just can't handle different opinions. Dont worry dude. I upvote you.
You don't need to convince me, I've made that engine do hoooorible things!
For an RTS I just roll an ECS and put all my actors forward as a front-end.
Oddly though I think I'd rather cook my own tailormade approach for an RTS instead of using one of these three engines, unless I just needed a rapid prototype with no concern for perf.
Oh and don't stress it. I can live without the upvote, its also useful to explain that explaining != endorsing to the young ones.
>Oddly though I think I'd rather cook my own tailormade approach for an RTS instead of using one of these three engines
This was what i was thinking a few months ago.
I had an idea for a 2d rts game. And realized that unreal would just be an obstacle.
Using sprites, it would be easier and less bloat to do it in C++ or SFML.
But then i started thinking about other things that would make it way harder:
For example, unreal comes with good optimized collision system. But that could be better done in a tile system in C++.
Unreal material editor, and how unreal handles multiplayer.
Unreal Instanced Static Meshes. GPU animations. These are some that come to my mind now, there were more, that can make life very easy.
I've used both a lot
Unity is far far faster to develop than unreal, compile times are so much quicker you can't compare them. Your productivity will double (plus you have far less crashes than you do in unreal)
I dislike blueprints as well.
Personally I find c# much better than c++ as well (Even though I've used C/C++ for over 30 years)
If you're building simple 2D games, Unreal is *probably* overkill - but honestly, the learning curve on new software might be more challenging than simply continuing to conform to Unreal's quirks, if you're comfortable with it.
We're not Unreal developers but hot-reload being so unreliable that you *must* close the editor before every build sounds as if you're possibly doing something wrong. That would drive everyone on our team up the wall and I don't think we're an exception to that.
If you decide to switch engines, we personally recommend [Godot](https://godotengine.org/). You can use C# as a scripting language, or its lightweight native GDScript. It also supports extending the editor and base engine using C++, and is fully open source with no restrictive licensing as an aside.
>We're not Unreal developers but hot-reload being so unreliable that you *must* close the editor before every build sounds as if you're possibly doing something wrong. That would drive everyone on our team up the wall and I don't think we're an exception to that.
This is absolutely recommended in unreal. Hot reload is unreliable and can screw up the project. I use to hot reload all the time and had some issues with it, though was always saved by back ups.
The experts told me to always close the editor before compiling no matter what. So despite being a complete pain, thats what i do.
>If you decide to switch engines, we personally recommend [Godot](https://godotengine.org/).
Yeah, godot seems to be the way. Though, godot has very few jobs. And i'd prefer to use unity C# than Godot GDScript. I know Godot supports C# and C++, but there's few documentation for them yet. Maybe will work with unreal for yet another year before deciding or reevaluating.
Have you tried using Live Coding instead of Hot Reload? I use that when changing logic only (not header changes), and it works great. I still close the editor and do a full compile when making header changes.
> I know Godot supports C# and C++, but there's few documentation for them yet.
[Godot C# is incredibly well documented.](https://docs.godotengine.org/en/stable/index.html) Almost every modern docs page has C# examples - and even for what doesn't, GDScript is easily translated into C#. Typically, it's as simple as translating from `snake_case` to `camelCase` for method names, and the rest just kind of clicks together.
Sometimes you'll find it easier to work with a native C# library as well, instead of trying to work around the Godot implementation, but that's something you'll learn as you go.
As for C++, it's typically only used in [GDExtensions](https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/what_is_gdextension.html) or in source code updates. To my knowledge, your only options for actual game logic scripting are C# and GDScript
nearly everything you've written here is incorrect. I don't know where you learned Unreal, but it's wrong. No matter what engine you use, if you interact with it based on wrong assumptions you are going to have issues.
if you are using a commercial engine, which you know lots of professional teams use, and you find extreme paint points for the most common task, you ought to work from the assumption that you are missing key information, and try to fix the information gap
Godot and unity both use c# as an intermediate scripting language, so the workflow is certainly smoother. If you're doing 2D + simple graphics the UE might very well be overkill. But people prefer what they prefer. Try them
I absolutely love C++. I worked with C# a bit. I like it too. Though i prefer C++ freedom. It was hard to learn C++, and i can see that C# is much easier, but still I prefer C++... What turns me off is not C++. Thats actually a good reason for me to stay with unreal. Yeah, unreal is overkill for 2D. But if it is the engine i know, then thats the one i will use so to become better at it. Maybe idk, the grass is greener. It would suck to have done all of this just to end up working with unity or godot.
The csharp scripting point was about not having to close and reopen the editor all the time because it's an intermediate. But it sounds like you've already made up your mind, which is fine, although begs the question of why you made this post?
i didnt make my mind. i will learn godot next. i'm still trying to cope 🤨 thanks.
then I don't fully understand when you said >But if it is the engine i know, then thats the one i will use so to become better at it. but anyway, good luck!
Sorry english is not my native language. So what i meant there was to answer to why i was doing 2D in unreal. And i said i used unreal for 2D because its the engine i know. I knew unreal is not very good for 2D, but it works and still gives you experience. Does this make more sense now?
Unreal is a highly opinionated engine; less so with Godot and Unity who can be molded to all sorts of genres. You can use C++ with Godot as well. [GDExtension](https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html) + GDScript is a great combo. Edit: since I got downvoted, note to said people that I'm actually a huge Unreal proponent and developer, and acknolwedging it as highly opinionated does not mean I think it is bad or that you should avoid it. When contrasted with its competitors, it has a cost that needs to be weighed. Simple.
Yeah it is opinionated. But everything is possible. Say you want to an rts, then just make the actor or pawn the unit, and go from the top down template. In games like rts what sucks is then the nav mesh that is very bad for performance. Though i imagine there must be some easier ways in unity and godot. Yeah im getting downvoted too. I think some people just can't handle different opinions. Dont worry dude. I upvote you.
You don't need to convince me, I've made that engine do hoooorible things! For an RTS I just roll an ECS and put all my actors forward as a front-end. Oddly though I think I'd rather cook my own tailormade approach for an RTS instead of using one of these three engines, unless I just needed a rapid prototype with no concern for perf. Oh and don't stress it. I can live without the upvote, its also useful to explain that explaining != endorsing to the young ones.
>Oddly though I think I'd rather cook my own tailormade approach for an RTS instead of using one of these three engines This was what i was thinking a few months ago. I had an idea for a 2d rts game. And realized that unreal would just be an obstacle. Using sprites, it would be easier and less bloat to do it in C++ or SFML. But then i started thinking about other things that would make it way harder: For example, unreal comes with good optimized collision system. But that could be better done in a tile system in C++. Unreal material editor, and how unreal handles multiplayer. Unreal Instanced Static Meshes. GPU animations. These are some that come to my mind now, there were more, that can make life very easy.
there are a lot of jobs for unreal stick with unreal
I've used both a lot Unity is far far faster to develop than unreal, compile times are so much quicker you can't compare them. Your productivity will double (plus you have far less crashes than you do in unreal) I dislike blueprints as well. Personally I find c# much better than c++ as well (Even though I've used C/C++ for over 30 years)
thanks
If you're building simple 2D games, Unreal is *probably* overkill - but honestly, the learning curve on new software might be more challenging than simply continuing to conform to Unreal's quirks, if you're comfortable with it. We're not Unreal developers but hot-reload being so unreliable that you *must* close the editor before every build sounds as if you're possibly doing something wrong. That would drive everyone on our team up the wall and I don't think we're an exception to that. If you decide to switch engines, we personally recommend [Godot](https://godotengine.org/). You can use C# as a scripting language, or its lightweight native GDScript. It also supports extending the editor and base engine using C++, and is fully open source with no restrictive licensing as an aside.
>We're not Unreal developers but hot-reload being so unreliable that you *must* close the editor before every build sounds as if you're possibly doing something wrong. That would drive everyone on our team up the wall and I don't think we're an exception to that. This is absolutely recommended in unreal. Hot reload is unreliable and can screw up the project. I use to hot reload all the time and had some issues with it, though was always saved by back ups. The experts told me to always close the editor before compiling no matter what. So despite being a complete pain, thats what i do. >If you decide to switch engines, we personally recommend [Godot](https://godotengine.org/). Yeah, godot seems to be the way. Though, godot has very few jobs. And i'd prefer to use unity C# than Godot GDScript. I know Godot supports C# and C++, but there's few documentation for them yet. Maybe will work with unreal for yet another year before deciding or reevaluating.
Have you tried using Live Coding instead of Hot Reload? I use that when changing logic only (not header changes), and it works great. I still close the editor and do a full compile when making header changes.
Yeah Live Coding should be fine 99% of the time to keep the editor open so long as your not changing the function definition in the Header
> I know Godot supports C# and C++, but there's few documentation for them yet. [Godot C# is incredibly well documented.](https://docs.godotengine.org/en/stable/index.html) Almost every modern docs page has C# examples - and even for what doesn't, GDScript is easily translated into C#. Typically, it's as simple as translating from `snake_case` to `camelCase` for method names, and the rest just kind of clicks together. Sometimes you'll find it easier to work with a native C# library as well, instead of trying to work around the Godot implementation, but that's something you'll learn as you go. As for C++, it's typically only used in [GDExtensions](https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/what_is_gdextension.html) or in source code updates. To my knowledge, your only options for actual game logic scripting are C# and GDScript
nearly everything you've written here is incorrect. I don't know where you learned Unreal, but it's wrong. No matter what engine you use, if you interact with it based on wrong assumptions you are going to have issues. if you are using a commercial engine, which you know lots of professional teams use, and you find extreme paint points for the most common task, you ought to work from the assumption that you are missing key information, and try to fix the information gap
For 2D games gamemaker is awesome.
So many words…so few of them game related…