Please, please, please pace yourself. Learn a few coding tricks, and then make the simplest game possible using what you learnt. After that, learn some more and make a game that’s just a little bit more complex. Your games are going to be shit, just accept that. The idea is to quickly make something, learn from it, and repeat. At this stage, the final product doesn’t matter nearly as much as what you learn from making it. Because of that, don’t be afraid to bail on a project that isn’t getting you anywhere. It can be easy to overthink your games, but try not to. Despite how frustrating it’ll often be, stick with it, and try to have fun with this phase of your skill development.

I know you’ve got some great, ambitious game ideas. That’s great, use those as motivation, but you aren’t ready to tackle them. Baby Steps. Also, know that those ideas aren’t as valuable as you think they are. We all have game concepts in our heads; ideas are cheap. You have no idea what works until you make it. Most games worth their salt are changed drastically from the original concept for the better anyways.

Here are some good resources that might help:

This is a video I found to be really helpful and inspiring. It’s in relation to storytelling but the advice applies to all forms of creativity: Ira Glass on Storytelling

I’m basically stealing this advice from these guys. This is a very good series of advice for starting with game development and sticking to it: Extra Credits on Making Your First Game

Also check out this fantastic Reddit post, written by people a lot smarter than I: A no nonsense "How to get Started" Guide

And recently I've been loving Yahtzee's Dev Diary series. As entertaining as Zero Punctuation ever was, but it also has a lot of good productivity advice from someone who's been a hobbyist developer for years.

That’s my advice. It’s what I wish I did when I started out. I heard similar guidance back then, but didn’t follow it. I had ideas I was too excited to work on, and I was too ambitious. For that reason the first 2.5 years of me doing gamedev were rocky; I was slow to learn because I was focused on getting projects done instead of learning.

On January 28, 2017, I set out to make a small game as a personal project- an energetic, arcade-style survival platformer. It wouldn’t be my first significant project, but it would be the first that I wasn’t following a tutorial for. I would be on my own for this one, no hand-holding. I had been thinking up this cool game idea and, despite knowing in my gut that I wasn’t ready, decided to start making it. I was just too excited not to. How difficult could it be?

The following project would take close to two and a half years of my life. I completely restarted development five times. Finally, on February 25, 2019, I had a finished product that was significantly cut back from my original vision and, in many ways, was unfinished. It was a terribly over complicated and inefficient process that resulted in a project that should’ve taken a few months at most, and a game I wasn’t really proud of.

What the hell happened?

I consistently made a number of key mistakes. Below I will retrospectively explore each of them Despite being an overall bad game dev experience, I learnt a lot from my errors and pitfalls. My process sucked hard, and I hope that I can steer you away from making the same mistakes.

Putting too much stock in ideas

The project was flawed from its conception. Before starting work on it, I would often think about the concept in my mind. I grew attached to my vision of the game, it's visuals and music. This is in contrast to Nintendo’s process: focusing on making strong gameplay and coming up with the theme, visuals, audio and everything else later. Never get attached to an idea, because once it exists you'll likely see just how bad it actually is. You need to be brutally honest with yourself to fix or even trash an idea that you once had confidence in, but it’s well worth it. In the future I hope to focus on prototyping gameplay first, and not get attached to ideas I only think will work.

Unrealistic expectations & overconfidence

Another thing that plagued my project from day 1 were my unrealistic expectations. Because I would always built up this vision of this concept in my head, I imagined a great game and wanted to make that. I had grand ideas for the visuals and music and gameplay which were way outside what I could reasonably do or even find help to pull off. I just couldn’t make a very good game. I should have kept in mind what I was actually capable of, and come to terms with the fact that this game won't be a GOTY.

Prototyping VS overthinking

My expectations for the game's quality lead to me overthinking the game a lot. I have pages and pages of notes, me thinking of every possibility on how to make this the best game it could be. I think I spent more time brainstorming the game than I did creating it! I don’t think any amount of overthinking will tell you if something actually works. Rather, it’s best to prototype and iterate as much as possible.

Unnecessarily complex systems

I had a tendency to overthink the game’s code, too. I remember making a hazard calling system that took me a lot of work because I felt the need to make it as flexible, variable and featured as possible. It was much more complicated than I needed; no playtesting ever suggested I needed to add so many features. Not only was making the system difficult, but customizing this highly customizable program was slow and tedious. The final version of the game used a hazard calling system made up of only a few lines of code.

Getting in over my head

I had a project with a bunch of buggy, unfinished systems, tons of ideas I hadn’t even prototyped yet and all for a game that I couldn’t make into an engaging experience. At this point, the weight of the project makes itself apparent. I realized what an undertaking it was, how unprepared I was to make this game. But I couldn’t just give up on this game I’ve already poured so much time into. That damned sunk-cost fallacy had me.

Restarting

Because of unrealistic expectations, I had a terrible habit of restarting the project. This was the the biggest detriment to the game's development. The first two iterations of the game, V0 & V1, were just experiments that didn't take long. V2, V3 and V4, on the other hand, were all multi-month long developments. I was a fool to restart production even once. I wasted a crazy amount of time working on in a Unity file only to start a new one. I even started to like where the game was going in V2. V2.16 was a breakthrough, finally, this build felt like that energetic, involved platformer I envisioned. If I had kept going from that point, I bet I would have had a finished product much earlier. So why did I keep wiping the slate clean? Largely because I like simplicity. As a Unity project file progressed, it became cluttered with a bunch of systems. Systems that were messy, complicated, interlocking, and sometimes not-quite-working. I guess I'm better with starting from scratch than fixing what I've already got. I liked the simplicity of restarting with a new, clean Unity workspace. The other major factor was how quickly I was getting better. My coding skill constantly improved throughout the project. At certain times I would look at my current project and say 'I can restart this, but make it better.' It’s true, each version of the game had smoother controls and better code. Obviously restarting a project I had already spent so many hours working on was a terrible idea, but it was one I kept making. If I want to be successful at this, I can't do that anymore. I need to get better at fixing my existing work.

Eventually, it came to head. I didn’t care so much about how good the game was, I just wanted to get it done as quick as possible. I decided to dig through my files and to find V3, since it was the most complete version of the game. Instead of restarting yet again, I took what I had, fixed and improved it. I rewrote the code that was outdated and improved everything. At this point, I didn’t care so much about the quality of the game as I cared about just getting it done and released. And I did. 2.5 years after I had started, the game was complete. The game is Death Chamber, if anyone is curious.

This is a repost of a postmortem I wrote on r/gamdev awhile back. It raised a very interesting discussion in the comments, so check that out if you'd like. Thought I'd post it here, so it will hopefully find more people who will take it to heart. I've already learnt at least one good lesson from my current project, and I'd love to dive into it here if you guys are at all interested.