I'd like to discuss what it takes to see the development of games through to the end, and I'll try to give some advice along the way (which you should take with a pinch of salt, or an entire tablespoon for that matter). I've got a fair bit to say though, so I'll split it into 3 parts:
- In the first part, I'll paint the "big picture" for a completed game, leaving out all the small, (yet still important) details.
- Next, I'll discuss scoping. Basically all the small, but important details I conveniently avoided discussing in Part 1.
- Finally, I'll discuss little things you can do that may help you stick to your schedule.
The "Big Picture"
Firstly, I should admit that I've never really finished anything major - with the exception of a little Android puzzle game called Cubez. That said, I do intend to let Control Shift be the first game that I can call (mostly) finished, according to these criteria:
- It should be subjectively fun.
- It should be pretty well polished.
- It should be accessible and well optimized.
- It should be recognized as such by the community at large.
Secondly, before I go diving into the details of these, it's worth noting that seeing the development of a game through to the end is not inherently a good thing! In fact, you should probably abandon most of your attempts if they don't seem to be going anywhere. If you fall too in love with your game, you might end up wasting time on something that no one besides you will ever want to play.
That said, finishing a project is not simply "more of the same". You'll go through different stages of development, and learn new things and be exposed to new challenges. It's all about scoping really. Don't take on tasks that you definitely can't finish in a reasonable amount of time - unless your goal is to learn. I've written another article that also touches on the importance of scoping, and I'll like write a follow up on this matter too. It's an important topic, and knowing when to call a game "done" is hard. So let me take a crack at it!
It should be subjectively fun
Adding the word "subjective" before "fun" is a bit redundant in my opinion, but I'm doing it anyway. Not everyone is going to enjoy your game - the question is just, how many players are you content with? That one you'll need to think about long and hard, and answer it for yourself. You'll need to work hard to get others to play it, and you'll need to learn how to respond when people don't like it.
Of course, the goal of making a game is for entertainment, and it would be a bit of a failure if it weren't fun. Well, that's a bit of a lie - many successful games aren't fun! They could be challenging or interesting, and still be good games. In the case of Control Shift though, it should be fun and it should be competitive. If I manage to get others to play my game, and manage to make them yell at their friends in excitement / frustration, it would be a success for me!
Anyway, the thing you need to take away from this one is that your game will never feel complete if it's not fun, and this is something you'll likely need to sort out sooner rather than later. Prioritize this step, and make sure your game is fun early on. Adding more complexity to your game won't make it more fun, it will make it less fun!
It should be pretty well polished
No, it shouldn't be pretty well polished. You should polish it so damn hard that your fingers begin to bleed. Doing this is hard though, and something I'm still learning to do. This is typically something that you should do after you have a game that is fun. Polishing a game won't make it any more fun, but not polish a game can ruin it.
Polishing isn't just about making things pretty, it's about making things easier and less frustrating to use. Though not completely done, I'm currently working on Control Shift's level editor to make it as easy as possible to use (left: technically usable, right: much better already!)
This process will involve thinking and designing a UI, menus, sparkly bits, endless tweaking of lighting and materials parameters / colours, etc etc etc. It helps if you have team mates you can bounce your ideas off of. Also, join some communities (both online and offline) and ask for feedback.
It should be accessible and well optimized
I won't go into much detail here, but I'd really like my game to not require the latest graphics card to run at 60 FPS. Not every part of the program needs to be optimized though honestly. If your game performs well even with badly optimized code, why waste time trying to optimize? Rather work on making the game more fun or polished!
It should be recognized as such by the community
This one is very important as well. If you are the only one who thinks your game is fun, polished and well optimized - you are doing it wrong! Personally, I'm going to use Greenlight to determine whether or not the is the case for Control Shift. We already got some positive feedback from other players from expos, and have had a couple of reviewers make Let's Plays of the game, but this is not enough. Control Shift might never become that popular, but getting Greenlit would be a good start!
Youtuber kameleon-gaming doing a Let's Play of Control Shift
We now have the big picture for when we could consider our game complete. It's missing all the important details, which I'll discuss in Completing the development of your game: Part2!
