Don’t use frameworks, jump straight into a game engine.
I’ve wasted a loooooot of time wrapping my head around creating games with frameworks and while I did get some experience there it was ultimately a pretty frustrating experience. I tried all the popular ones like MonoGame, Love2D, HaxeFlixel and while Haxe was pretty fun to use it ultimately felt like I spent ages reinventing the wheel and never really had time to… Well… Make the game. It didn’t help that I wasn’t very good at programming at the time.
At some point I threw my hands up and just went to Unity and now Godot and it was suuuuuuch a good decision. Now I can quickly prototype and have a much better workflow without all the spaghetti. It’s more convenient, and chances are the end result will be way better and more optimized than whatever I was hacking up in frameworks at all. I’m sure a lot of people disagree, though.
Pretty smooth, actually. The workflow isn’t too different from Unity and I got used to things quickly by reading the docs. After getting the basics down it’s mostly a matter of finding the things I’m looking for (for example Tags in Unity are called Groups in Godot). I was impressed by how smoothly everything ran and how tiny the engine itself and its files are. Unity feels like a bloated nightmare in comparison.
There are a few pain points in Godot though that people need to be aware of before getting into it though. Godot 4 has big issues with its web exports making them not very viable, and there still isn’t an official way to port your games to consoles. Some of the features in Godot 4 are also somewhat experimental and aren’t nearly as “battle tested” as Unity, so if you’re super serious about game dev it may not be the best engine for production.
You can use either gdscript (think python) or C#. C# used to be a bit of a second class citizen but from what I see it’s nearly on par with gdscript for support, and it’s getting a lot of attention from the devs.
Yeah there is post-processing and shaders as you’d expect. I forgot to mention that I use GDScript, it fits in with the engine way more intuitively, not to mention C# support is lacking in a few things.
I kind of disagree with this. When I made my first game while in highschool, I’ve started with XNA because I don’t think Unity was available at the time. I only wanted to make a simple platformer, and it was an amazing learning experience - I had to build a game loop, collisions and physics and animations by myself, which isn’t really that hard for a 2D platformer - especially since you don’t have to deal with rendering thanks to XNA - but when I then discovered Unity, it wasn’t just some kind of blackbox but I understood what’s going on in the background because I had a hands-on experience. And I was also really greatfull that I don’t have to do all of that by myself again.
Sure, I would not try to make a bigger game in such a framework, but I think everyone should at least once try building a simple 2D platformer in XNA or a similar framework. I don’t know any of the frameworks you have mentioned, jugding by the name it may be something more than just a rendering framework, and I can imagine that being frustrating. XNA was perfect starting point because it gives you ways how to get input and render a sprite on screen, and that’s it, so it’s easy to use.
And in addition to that, although that may not be relevant to everyone, but it was the moment that OOP finally clicked with me, after a few years of programming courses at school (I mean, I was like 13 at that time) where I mostly copied code around without really getting it, but it was that experience of having to build a game loop where I finally got it and it clicked. I’d say that game loop with is the most clean example of OOP principles.
Don’t use frameworks, jump straight into a game engine.
I’ve wasted a loooooot of time wrapping my head around creating games with frameworks and while I did get some experience there it was ultimately a pretty frustrating experience. I tried all the popular ones like MonoGame, Love2D, HaxeFlixel and while Haxe was pretty fun to use it ultimately felt like I spent ages reinventing the wheel and never really had time to… Well… Make the game. It didn’t help that I wasn’t very good at programming at the time.
At some point I threw my hands up and just went to Unity and now Godot and it was suuuuuuch a good decision. Now I can quickly prototype and have a much better workflow without all the spaghetti. It’s more convenient, and chances are the end result will be way better and more optimized than whatever I was hacking up in frameworks at all. I’m sure a lot of people disagree, though.
How was the jump from unity to Godot?
Pretty smooth, actually. The workflow isn’t too different from Unity and I got used to things quickly by reading the docs. After getting the basics down it’s mostly a matter of finding the things I’m looking for (for example Tags in Unity are called Groups in Godot). I was impressed by how smoothly everything ran and how tiny the engine itself and its files are. Unity feels like a bloated nightmare in comparison.
There are a few pain points in Godot though that people need to be aware of before getting into it though. Godot 4 has big issues with its web exports making them not very viable, and there still isn’t an official way to port your games to consoles. Some of the features in Godot 4 are also somewhat experimental and aren’t nearly as “battle tested” as Unity, so if you’re super serious about game dev it may not be the best engine for production.
Is there post effect processor? Do you use c sharp in Godot?
You can use either gdscript (think python) or C#. C# used to be a bit of a second class citizen but from what I see it’s nearly on par with gdscript for support, and it’s getting a lot of attention from the devs.
Edit: and yes there is a post processor
Yeah there is post-processing and shaders as you’d expect. I forgot to mention that I use GDScript, it fits in with the engine way more intuitively, not to mention C# support is lacking in a few things.
I kind of disagree with this. When I made my first game while in highschool, I’ve started with XNA because I don’t think Unity was available at the time. I only wanted to make a simple platformer, and it was an amazing learning experience - I had to build a game loop, collisions and physics and animations by myself, which isn’t really that hard for a 2D platformer - especially since you don’t have to deal with rendering thanks to XNA - but when I then discovered Unity, it wasn’t just some kind of blackbox but I understood what’s going on in the background because I had a hands-on experience. And I was also really greatfull that I don’t have to do all of that by myself again.
Sure, I would not try to make a bigger game in such a framework, but I think everyone should at least once try building a simple 2D platformer in XNA or a similar framework. I don’t know any of the frameworks you have mentioned, jugding by the name it may be something more than just a rendering framework, and I can imagine that being frustrating. XNA was perfect starting point because it gives you ways how to get input and render a sprite on screen, and that’s it, so it’s easy to use.
And in addition to that, although that may not be relevant to everyone, but it was the moment that OOP finally clicked with me, after a few years of programming courses at school (I mean, I was like 13 at that time) where I mostly copied code around without really getting it, but it was that experience of having to build a game loop where I finally got it and it clicked. I’d say that game loop with is the most clean example of OOP principles.