QOTD: If you could go back in time, what advice would you give your past self before you started making games?

Do not fall into the "performant language" trap. C++ might run fast, but it also requires an unreasonable amount of work to get memory management right. You could spend that time on optimizing your algorithms instead, what will more than likely balance out the performance costs that come with most memory safe languages.

(There's of course also Rust, that is both, fast and memory-safe, but the Rust support in game engines is still in its infancy, and the fully Rust-based engines aren't really production ready either. Also, it's not available on all platforms.)

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

Choose your first game engine wisely. Avoid Unity as your first engine, because the first engine you will learn will be really hard to transition off. It may be a little bit easier to get into, and there's a ton of examples around, but after a few years, you will regret it. It being closed source means that you will eventually get into frustrating situations, and the company is going downhill every year.

While Unreal was building and releasing Nanite, Unity's headline news was acquiring a monetization company, killing Unet and firing 200 workers.

By this point, I've spent years working only in Unity, and even though I did try other middlewares during my gamedev degree, I never managed to actually transition. Learning your first engine is hard, but you will either give up on gamedev or get through it. Learning a different engine after you've spent several years getting used to another one is really, really frustrating. None of your workflows work, you now know how you would do that easy thing in another engine, but it's not taking ages and it's not intuitive. It's so easy to give up, because you also don't really need to use a different engine for your next project. I've never managed to force myself to switch, even though I'm starting to dislike Unity more and more.

So choose your first engine wisely. I'd even suggest rather than learning one, experimenting early and quickly with as many engines as possible - before you develop a workflow in one of them and get used to it, because then working with anything else will become really frustrating.

Another tip would be to look into DI as soon as possible. I haven't really decided whether DI is something that should or should not be used in games, but I'm now porting a project that's using Zenject, and I kind of like working with it, but it's a hard mindset to get into - and almost impossible to work into an existing architecture.

Go take modelling or drawing classes as soon as possible, while you still have lot of free time at school. Basics are enough, but it's a skill that is really useful, and it's something that will really help you down the line.

You are a programmer. You don't need to work fulltime right out from school to manage - you've survived part-time while going to college, so just keep on working part-time while living frugaly, but use that free time to make games and do your own hobby projects. My roommate did exactly that, while I went to work fulltime. While I had more money that I could use, he has written and organized a LARP, kept working on our game for dozens of hours every month, directed his own theater play and still had time to learn or for social life. While I only barely struggled to get the motivation to work on our game after work. But it's really hard to go from living comfortably on a higher income than you need to living frugaly, but if you are already living frugaly then you can just keep on doing that for some time after your school is over.

Do not, under any circumstances, attach your sense of self-worth to your games.

Never make game development your identity. Let it be a thing you do, not a thing you are.

Build a community outside of game development as soon as possible, even if you're an introvert. You won't understand why this is so important until the day you need it and don't have it.

:0 is there a story here?

Reduce your scope. I know, you already removed as much as you could to minimize the work to MVP, but seriously - keep going, you're about to drown in the overwhelming pile of "must haves".

Just pick an engine and stick to it.

@Ategon
When you think your game's scope is small, it isn't. Keep scoping as tiny as possible so you could finish your game in a week or two

What's the point of making such a small game?
- @bikesarethefuture
  That I'll actually finish it

DO GAMEJAMS!