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.
Congrats on finishing something! That alone puts you ahead of probably half the game devs out there :) I've also done a few releases of smaller games to get "something" done, warts and all. Learn from it, do better on the next one.
A few months ago I had the idea to combine a bunch of mini games that I could make quickly with a defined scope that wouldn't send me down that rabbit hole, and package them together as a collection. I'm pretty happy with how it came out, even if it hasn't been a commercial success yet. Plus now it's easy to add another minigame or two as an update, which I'm working on right now. For purchasers, the value keeps increasing.
Have been playing it quite a bit and love it! Really fun :) interestingly enough i've gotten interview questions like this before. Keep up the awesome work! Also - just because I didn't see it. You should have a mailing list that I can subscribe to in order to hear about your next game!
Thank you for the feedback! We're in the process of putting some kind of website up, we'll add the option of subscribing to the mailing list when it's up.
As it turns out, a colleague of mine in charge of recruiting wants to use some puzzles for the next internship interviews.
Finishing projects is a skill on itself; the article is right on focusing on what is really important, but I'm not so sure all the points are as useless as the author is presenting them.
Have now beat most of the levels. Something else you could do is the max number of moves rather than the min. Especially when you get to more than 2 baskets. Identical game play just different stars awarded function...
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.
This looks quite good already. Nice work. I would love something to substitute for the drab experience of FM. Would you be offering Linux support in the future?
> Would you be offering Linux support in the future?
Answer can be inferred from my previous comment :)
Seriously though, thanks so much for the interest. The tech stack is C# and WPF specifically which Microsoft does not appear to be keen to port to any other platform.
If this version takes off when finished, I could be convinced to recreate as a web or Android app.
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).
> 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.
> 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.
It sounds like the lecturer did an effective job of convincing people how valuable agile can be.
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.
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.
Cough, ahem, if you and parent didn't read all the way to the end:
>Consume Less
>Reading 20 articles a day on game development feels like work. It is work! But it's useless unproductive work, it's not moving the needle.
>Better to spend less time on Gamasutra, TIGSource, r/gamedev/ (or where ever the cool kids hang out these days) and a little more time in your editor getting stuff done.
I'd be inclined to say that Ludum Dare and Twitch or itch or whatever are up there in the "where ever the cool kids hang out these days" list.
Game jams were the only way I made the two games that I have made. Without it, I guess me and my friend would be lost in stupid details instead of releasing a game.
Same. I've spent about 6 years doing gamedev as a hobby and have never released a game or have anything to show others when they ask "Oh what have you finished?" (because like many others I spend far too much time pursuing unnecessary things during development then end up abandoning and starting a new project).
I have however took part in many Ludum Dares and I have been able to complete 7 or 8 games/entries that, looking back on even the first entries, I'm quite proud of (and glad to show others).
Stupidity!? Handmade Hero seems to me to be a uniquely great resource for learning the guts of game development. He's made it clear from day one, and has reiterated often, that the aim isn't to make a game as fast as possible, and that there are lots of good engines available if you just want to make a game. Are you sure you're not judging it by the wrong standards?
Handmade Hero, day 325 ticket mutexes. Yawwwn.... Most of the stuff that he spends (wastes) his time on is really not relevant to a game development, at least not initially if at all.
I personally view it as an "exploration in NIH" under the ruse of "game development".
It does make up for an kinda amusing show tho. "Day 4524, debugging my shitty vector implementation" (;
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.
I think the point of article is to resist learning Qt while making a game, because you believe it would make you more productive some time later. If you already know Qt and can do lots of work quickly, more power to you. IMO, Qt is powerful technology with good future; getting familiar with it is a fantastic investment for young people in IT, just not so much in game development.
I mean obviously don't write a GUI if a CLI will do, and don't write a CLI if editing text files will do. But if you do need a GUI editor then I think Qt is the fastest/best way to get from zero to working GUI.
That can sometimes be a deceptive trap, though. What if there isn't a lib or wrapper for Qt (or whatever it happens to be, physics, networking, etc) in your language of choice? I've gone searching the net for solutions to roadblocks in the past to find "this would be perfect... if only it worked in my language." Do you write your own wrapper, try to use something else, switch languages, etc. It can be a vicious cycle that ultimately has you not making progress.
Or use someting like http://www.mapeditor.org/ and export to JSON. It could be more extensible, but a text property can have JSON, so you can kind of extend it like that.
Then process that JSON into whatever you need (I use python at that point).
I've been using it for a couple of years and it makes my life a lot easier.
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.
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?
For developing 2D games, I've found the combination of Love2D [0], Bump.lau [1], anim8 [2], and Gamera [3] to be extremely productive for me. This is a Lua game engine with additional libraries for collision detection, animation, and moveable/zoomable camera.
I'm an embedded C++ programmer by day so I've almost certainly done many of the things on the OP's list. It wasn't until I set C++ aside after 15 years or so and gave Lua a chance that I finally started making real headway on my Secret Agent Sam remake.
Unlike other environments where everything is an integration with yet another library or tool chain, DarkBasic is refreshingly monolithic. Everything is simply in the language.
This makes it really easy for beginners to get started. Take a look!
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.
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