As a person who spent his last 6 years making EVERY SINGLE MISTAKE presented in this article, I have to agree: it's solid advice.

Unfortunately, I may not have accepted it 6 years ago. I justified writing everything myself by saying I was learning. I justified buying C++ books by saying I wanted to be a "true" game developer. Then I justified switching to another language by saying I needed faster iterations and prototyping. I spent hours and days trying to make everything work on both windows and linux.

Me and a couple of friends just released our first game on google play last week [1]. It's stupid and only our friends and family played it. We didn't monetize it (it's 100% free, no adds) and we didn't promote it anywhere. It was made in two weeks, spending a few hours each day. I'm not very proud of it, but I'm extremely proud of myself for pushing through and finishing it.

Hopefully, our next game will be something people will actually like.

1. https://play.google.com/store/apps/details?id=com.manabreak

As someone who has spent the last 3-4 years on and off making a Football Manager game (https://github.com/lifebeyondfife/Cm93) that started as a weekend project - I loved this.

I recognise so many of the bullet points the author recommends avoiding, and why they're so tempting, but ultimately it's all great advice. The last ones like this I remember considering were Steam integration, and database encryption to make cheating harder _shakes head_.

I'm determined to finish within 5 years, and never start another Duke Nukem again.

Ha :) "Or drawing UML diagrams (Here's a secret; no one does this.)"

Question: do they still insist on UML at university? I remember they did for me, and with ten years in IT I have never since seen a single UML document by anyone, much less created one.

Not sure what he meant by the XML bullet point, or the .NET under level editors. Using XML or JSON for a config file is trivial in most modern frameworks, like .NET (e.g. Unity).

That's why I recommend jams like Ludum Dare [1]. You're constrained to 48 hours. You can't waste time on writing an engine in that amount of time; you can't work on anything else than the game content itself.

[1] http://ludumdare.com/compo/

True words. There's so much YAGNI and NIH that people pour their motivation/time/effort into and end up with nothing.

Btw, Handmade Hero is really a prime example of this stupidity.

Personal addendum: https://github.com/ensisoft/pinyin-invaders

Mostly good advice, but I find test-first helpful even for personal projects. And Qt is superb for internal editor tools. Drag and drop the widgets in the designer, write a few lines of Python to wire it up as an actual program, done. It won't look pretty and it will waste memory but it will work.

This assumes that shipping the game is the primary objective. While that will be true for professional projects, when working on an amateur project my goals are:

1. Have fun coding

2. Learn new technologies

Actually shipping is way down the list, almost a side effect. If I wanted pressure and deadlines I would just get a job at a game dev studio.

From the url I thought this was going to be about homemade rocket powered grenades.

Most of the advices can be extrapolated to the other fields of development. Not only the software development. But the goal should be highlighted: making the things done. I think there is even a methodology for this: JFDI

These days using Unity is definitely the best bet for just about everything. Even low end phones are fast enough to use it, so there's just not much benefit to using something lightweight or writing from scratch.

Game development has changed a lot and now it seems that it is more about content curation and design, selecting the right plugins and models from the Asset Store and putting them together in a creative way.

The business model has changed as well, it's not so much about making a masterpiece with perfect gameplay anymore, but more about hitting the right niche at the right time with something novel. There are hundreds of games released every day on mobile, thousands of games on Steam Greenlight, and tens of thousands of free games on itch.io. Games have become YouTube, and the makeup tips and unboxing channels are bound to win out over Sundance documentaries, so finding the right niche is probably a good bet.

Could someone enlighten me what the problem is with automated documentation systems?

Have they stopped to "just work" in creating an overview of all global variables, functions, classes and their inheritance?

I found it very convenient to just drop a few documentation strings at the function/class definition for looking it up later in the autogenerated documentation. Of course you can overcomplicate these things and waste time. But in my opinion autogenerated documentation is better than no documentation at all.

This is a good list of what not to do. Can anyone recommend what to do to make a simple game? I thought I'd give Unity a try because of the vast learning resources. Turns out it's pretty kludgy to get things done. Unreal Engine seems to have a steeper learning curve but is of somewhat better quality. I had the most fun trying to write my own OpenGL renderer in C++ but of course that's a rabbit trail off of making an actual game. What is the most productive environment for beginners?

I've learned many of these things while participating in game jams. My issue now is how to make the leap from game jam game to full release. In my case it feels like all the fun stuff is already done once you have successfully submitted to a game jam.

vow, what a great article. Really enjoyed it, you've cracked me up at "SOAP -You are so far from the road of game development, you can't even see it." I've developed some small games, but never published them, only showed to colleagues and friends. Coding games is a like a hobby for me as I've my daily job as a web developer. I'd really like to step in indie gaming scene someday and I'll definitely follow the advice from this blog post.

I won't lie, I clicked the link to see how to build a rocket propelled grenade.

> Question: do they still insist on UML at university?

I had a course [1] where the lecturer insisted on UML diagrams. And, even worse, they insisted on using a specific proprietary Java software and submitting the diagrams in that program's proprietary format.

Fortunately, my TA (who actually graded these diagrams) was much more lenient, but we had to do at least those UML diagrams that went up to the lecturer.

[1] The course was about applied development practices. Students were split into groups of 5 and had to develop a simple web application. It was really horrible; the lecturer had never heard of agile and forced us into a waterfall process in which 60% of the time was spent documenting requirements and drawing bogus diagrams.

I find UML state diagrams useful for specific, localized bits of projects where it is not necessarily possible to hold the entire state machine in my mind while developing/interpreting the code. It acts as a spec to guide writing tests and tells future visitors to the codebase exactly what I was trying to do. I check the UML diagram into source control alongside the code, which contains comments pointing to the UML diagram.

The key is to use this sauce in limited amounts and only to guide the development of truly critical parts of your code. A utility library to convert dates? Eh. A core library that handles complex multiparty bid management for a market? Definitely.

UML would be handy at places where you would have drawn some kind of diagram anyway. Like an overview of components in a distributed system. Or a processing pipeline. Or an overview of a deployment environment. If UML delivered a useful set of constructs for those, it would be useful. Sadly, it focuses on class diagrams which I have never seen used anywhere. Sequence diagrams are somewhat used, but they are too complex and do not fit the average use-case well. (distinction between classes and objects? what about threads? loops have no break statement. Fragments are horrible. wtf.)

There are diagrams for component overview and such, but they are so strange that you just end up with drawing your own diagram type.

But yeah, the software engineering department still teaches UML.

I see and draw informal UML-lish diagrams on whiteboards and napkins. I'd say 90 percent of them are sort of like the class diagram in UML. The rest are sorta-collaboration-diagrams and maybe-sequence-diagrams.

We'd probably draw something similar even if UML never existed but I think it helped a bit in creating the common vocabulary. So I'd say there is some benefit to teaching UML at university.

The startup I worked in just after graduating (in dev web) last year used to work with UML diagrams. I then moved in bigger companies where it just disappeared.

In my software engineering class, were using a lot of UML diagrams.

I don't know what to believe anymore as it looks like it's rarely used in the industry.

I learned UML during my bachelor's in 2012. Now I work at a big company and the only UML diagram I've had a use for is a sequence diagram.