You're an aspiring game developer. You want to make and release an awesome game to share with the world. This is hard. Far harder than say, writing a book. It's an alchemic mix of art, personal taste, cold hard math, logistics and engineering. Few can make a game alone and it's easy to get distracted, very easy. Or even worse ... work on stuff that doesn't matter, it feels so good, you're learning so much, stuff is getting done but your game isn't getting any more finished and that's the goal. Don't forget the goal...
Experts
Expert problems are not your problems.
Do you follow cool people on twitter like @ID_AA_Carmack, @notch or @grumpygamer? Good! They're all awesome developers with successful released games.
Have you released a game? No, right? Then these guys problems are not your problem. You have a totally different problem that needs your full attention; releasing a finished game. That's it.
There's overlap with your problem and expert problems but it's a sliver, a tiny splinter of overlap. You should ignore most expert problems with extreme prejudice.
Expert Problems
Just wait I'm using GameMaker! I'm not a real programmer, this entire project needs to go in the bin! Time to order six books from Amazon about C++11.
Stop right there! Using smart pointers is not a problem for you. To release your first game you shouldn't be messing with pointers anyway. How are you going to deploy that game? How you are going to ensure it runs on someone else's machine? Game studios can barely manage this and they often have teams of hundreds of people. This is not your problem.
Experts have a lot of problems; internet hate, mild social pressure to be innovative, mild social pressure to release more of the same, large teams, the bureaucracy that comes with large teams, the special bureaucracy that comes with large coding teams (standing scrums, referring to employees as resources, meetings, arguing over the unwashed contents of the sink - expert problems).
Brass Tacks
Here are your problems in order of importance.
- Think of a game you can make and
- Some other people might like (and even buy!)
- You think you could make in < 1 month. That's right.
- Find an existing engine to use
- People have made commercial games in.
- Allows rapid development.
- Handles deployment.
- Ideally you're familiar with it.
- Finish the game
- Sell the game (or give it away)
- Promote the game
- Gather feedback
- Back to stage 1
If you can't use your engine of choice to create a clone Pong in half a day, that other people can play first time, you have made the wrong choice and will be eaten by a Grue.
Here are problems that are not yours.
- Writing an engine in C++
- Nooooooo
- Nooooooo
- Nooooooo
- Deciding to rewrite C++'s STL library so it doesn't allocate as much memory
- Soft sobbing
- Learning how to create multi-platform builds
- By learning make
- Then cmake (make is for suckers!)
- Then premake (cmake sucks)
- Then Jam (premake - pfft)
- and so, you venture deeper, ever deeper into darkness of the abyss. We know we'll never see your face again, you're gone to us, another child of Adam lost in the dark.
- Start writing the Vector class
- Hmm, better look in SIMD operations
- Then matrices, quaternions, the hell of integrating five flavors of OpenGL across 6 platforms, oh wait better make that a general abstraction layer to support DirectX too. And Metal. Got to get a nice intermediate shader language too!
- No tears.
- No pity.
- No hope.
- Arguing about stupid crap on the internet
- Language X is better than Y
- Library X is better than Y
- Platform
- Programming methodology
- If you should care about 60FPS (The answer is: No.)
- Learning shader programming
- Do you have a goal? No? Then STOP! Make a game.
- Have a technique in mind? Ok, you may proceed ...
- ... cautiously
- Automated documentation systems
- Doxygen
- cldoc
- You are dead to me
- Localisation
- Nooooo
- Nein
- Non
- ヤダー
- Like everything else worry about this after release.
- Optimisation
- Games are exploratory programming
- You're going to throw that code away
- It doesn't matter how fast it is at the bottom of the recycle bin.
- Fast comes at the end, or when it becomes too slow to continue
- Games are exploratory programming
- Writing a multi-page design doc
- Or drawing UML diagrams (Here's a secret; no one does this.)
- Test First Development.
- No.
- Creating a level editor
- Resist this hard
- When it's obvious it's going to save time build the LEAST possible level editor. Do not guess what you'll need in the future
- MFC (at this point you may as well get off the computer and just do the self harm with a razor. It'll be less painful.)
- Qt Noooooo
- .NET - no
- Plain text files, with dynamic reload in your editor
- Perhaps suprising but yes
- XML
- No
- Writing your own XML parser
- That handles namespaces!
- Nooo
- That handles namespaces!
- SOAP
- You are so far from the road of game development, you can't even see it.
- JSON, YAML, MessagePack
- No, no, no
- Boost!
- Kill us both. This is the end. Nothing can be redeemed at this point.
There's nothing wrong with doing all this stuff but you will never release a game like this. After several years of tinkering you'll have a nice toy-engine though and be pretty much back at square one; make and release a game.
Tips
How do we focus on our problems and make progress on the things that matter? Here's a few things to try.
改善 - Kaizen
Kaizen, isn't everything from Japan cool? Well thinking harder about it I guess there are some exceptions. Anyway, one thing that is surpassingly cool about Japan is Toyata. Yes the people who make cars! They're like the Henry Ford of the 2000s and develop lots of neat business innovations. And isn't that what we're all really here to discuss, the fascinating history of business innovation? Right?
Ok. Wake Up!
A cool method popularized by Toyota was kaizen; continuous improvement. And to poorly summarize the technique, it's changing your mindset to continuously search for areas in your development process to improve. Just 1%, tiny improvements. No revolutions here.
What's the smallest possible step you can take that makes your process better and moves you toward your goal.
When I think of kaizen and game development, I ignore the process bit, I just think of the method as "What's the small possibly thing that can be done that's going to push the game closer to release?". That might be building a level, or quickly building all the levels at a first pass level of finish. It might be getting a list of sounds that are needed and sending them to an outsourcer. The key is it has to move the progress meter.
Adding another page to the design doc does not move the progress meter, neither does a meeting with out an outcome. The things that move the meter are lines of code and megabytes of assets. They are the only things that move the meter. You might need to do other task besides these but you should always be taking small incremental steps towards release.
Start Small
Is it your first game to release? Oh the problems you will face.
Start small! Really small. Pong small. Get the smallest possible game you can make and go through the entire distribution pipeline. From this suffering you'll gain the first-hand wisdom that people toiling on their first game for years will never receive.
This is just an opinion but, it's also objective truth, you'll be a superior human in everyway to lesser mud-blood human's who never managed to release anything. Everyday they'll continue to toil away in the fields like Russia serfs, while you can skip past them like a wise and jolly Rasputin. (I've released exactly zero games independently, so I am too one of the serfs, with only homemade vodka and sweet dreams of a Bolshevik ruled future to keep me going.)
Choose Something That Excites You
Something that excites you but doesn't blow out the scope or massively increase the difficulty! The X factor for any game is you, your unique beliefs about game design, your view of the world and you should express that through the game where you can. Don't be afraid to add your own mark.
The more a project excites you, the easier it is to finish.
Finishing is a Skill
This is a super secret. It's like a cheat code. The more you finish, the more you can finish. That's not a tautology it's just the simple truth; do something a lot and you get better at doing it.
Finishing also increases confidence and lets you be ambitious in a rational achievable way.
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.
Give your own inner voice and guide a little room to breath!
Share
Share what you're doing, how your feeling, problems you're having etc. There's a lot of other developers in their own trenches who will shout words of encouragement. Also you get feedback and feedback makes you better.
End Notes
Stop reading and get to it!
Linkbacks
Not Your Problem: Or why you don't need to focus on stuff you don't need