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.<p>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.<p>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.<p>Hopefully, our next game will be something people will actually like.<p>1. <a href="https://play.google.com/store/apps/details?id=com.manabreak" rel="nofollow">https://play.google.com/store/apps/details?id=com.manabreak</a>
As someone who has spent the last 3-4 years on and off making a Football Manager game (<a href="https://github.com/lifebeyondfife/Cm93" rel="nofollow">https://github.com/lifebeyondfife/Cm93</a>) that started as a weekend project - I loved this.<p>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_.<p>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.)"<p>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.<p>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.<p>[1] <a href="http://ludumdare.com/compo/" rel="nofollow">http://ludumdare.com/compo/</a>
True words. There's so much YAGNI and NIH that people pour their motivation/time/effort into and end up with nothing.<p>Btw, Handmade Hero is really a prime example of this stupidity.<p>Personal addendum:
<a href="https://github.com/ensisoft/pinyin-invaders" rel="nofollow">https://github.com/ensisoft/pinyin-invaders</a>
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:<p>1. Have fun coding<p>2. Learn new technologies<p>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.
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.<p>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.<p>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?<p>Have they stopped to "just work" in creating an overview of all global variables, functions, classes and their inheritance?<p>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.