Aug 14
There you are, yet again. Getting excited by your idea of a game, that you’ve been shuffling in your head for some time. The excitement has been building and stacking for the past few weeks, or maybe even months.
Now is the time to act.
You create a new project and start working with the idea. You are on fire. You are more or less addicted to developing the game and while the project progresses, you can see more and more of its potential and all the possibilities you can do with it. You write down all the ideas you come up with and even make some of those, because those feel so easy to code.
Time runs, weeks get by and your motivation and lust for the project is starting to drop down. Getting yourself back to the project feels like a burden and you start seeking for optional activities. Maybe you feel that if you would start it all over, you would make it better. Or maybe you’ve just created so many features which require polish that the workload is too much to carry. Or maybe you’ve come up with a better idea (which would start this journal entry from the beginning).
Whatever the reason is, you will most likely encounter this demotivating feeling. Which obviously causes the project to delay and in most of the cases, get canceled. As a hobby game developer, this is also an option you CAN take since your finances won't really take a hit, if you finish it or not.
I'm rather confident in saying that if you’ve made a game before you’ve already experienced this. You may have experienced this so many times that you’ve even become pessimistic of starting anything since “it will just get canceled and on top of the big list of unfinished projects” which is obviously very sad.
This has happened to me as well. Way too many times. Same goes with my current project, the Seeker: Quest. The game had so many ideas what it should include and in some cases it MUST include (at least in my head). This time I’ve decided to actually complete the game, which would make it the first release as a game that I’ve programmed 100%.
How can we dodge the inevitable demotivation for the project? How can we get it finished? This is the question which hundreds of independent game development blogs and articles try to think and resolve. The only reasoning you most likely get is the good old “Scope” which I’ve read about way too many times.
So yeah, scope is the scale of your project. The amount of features you plan on your game. The ideal thing is of course that you don’t add too many features, you keep the project small scale and because of this, actually get it finished. That’s very easy to say and when thinking, isn’t it very obvious as well? If every game developer out there would follow this rule, we would have so many completed games that they wouldn’t even fit into the whole internet. But still, very many of us can’t and won’t follow that rule. Why?
With Seeker: Quest I’ve grown around the project and I can see how awesome the game could become if I’m just able to achieve the planned features. I’ve been working on the code base to enable massive scaling possibilities for the game, which have obviously taken a big chunk of my time. Unfortunately, these scaling possibilities will most likely never be used. As a solo developer, you have very limited time or you need to prepare to work with the game for years. I want Seeker: Quest completed faster than this and to do that, I’ve been killing my darlings (features) with two hands for the past month.
So what I’ve done wrong with Seeker: Quest? Rule number one would be that do not get too attached to your project. With too attached I mean that your game is not supposed to have all the fancy fireworks you can imagine, but it should deliver that ONE thing as good as it possibly could.
Most of the games that are more or less caught the interest of players have that one thing they are talking about. If it’s the story as an example, you don’t hear many people saying something super awesome from the game's combat mechanics. Or if it is the combat mechanics, you don’t really people saying how cool the story was. Obviously I’m talking about small independent games here, since if you have a bigger team and budget you can deliver multiple polished features.
Aim to discover that one thing you’re trying to achieve and design your game around that. The rest of the features and “fancy fireworks” are just extra which you can deliver at some point, or leave those to the next project.
With Seeker: Quest the aim is to provide an interesting story in a casual way and offer fun & stress free monster catching in a top-down shooter game. Everything else is that “extra fireworks” we’re talking about. Now the aim is to focus only on these features and leave everything else out from the scope. If I’m able to achieve this, the game can be completed within some amount of months and I can focus on delivering quality features, rather than having a large amount of unfinished ones.
So because of this my second and last tip for getting your game complete, is to always design games with short development times. The longer you scale the project for calendar days, the likely you will discover something more interesting on the way and ditch the on-going project. There is nothing wrong in discovering something more interesting, but if you aim to get something complete, you may want to discover those a little later.
Now is the time to act.
You create a new project and start working with the idea. You are on fire. You are more or less addicted to developing the game and while the project progresses, you can see more and more of its potential and all the possibilities you can do with it. You write down all the ideas you come up with and even make some of those, because those feel so easy to code.
Time runs, weeks get by and your motivation and lust for the project is starting to drop down. Getting yourself back to the project feels like a burden and you start seeking for optional activities. Maybe you feel that if you would start it all over, you would make it better. Or maybe you’ve just created so many features which require polish that the workload is too much to carry. Or maybe you’ve come up with a better idea (which would start this journal entry from the beginning).
Whatever the reason is, you will most likely encounter this demotivating feeling. Which obviously causes the project to delay and in most of the cases, get canceled. As a hobby game developer, this is also an option you CAN take since your finances won't really take a hit, if you finish it or not.
I'm rather confident in saying that if you’ve made a game before you’ve already experienced this. You may have experienced this so many times that you’ve even become pessimistic of starting anything since “it will just get canceled and on top of the big list of unfinished projects” which is obviously very sad.
This has happened to me as well. Way too many times. Same goes with my current project, the Seeker: Quest. The game had so many ideas what it should include and in some cases it MUST include (at least in my head). This time I’ve decided to actually complete the game, which would make it the first release as a game that I’ve programmed 100%.
How can we dodge the inevitable demotivation for the project? How can we get it finished? This is the question which hundreds of independent game development blogs and articles try to think and resolve. The only reasoning you most likely get is the good old “Scope” which I’ve read about way too many times.
So yeah, scope is the scale of your project. The amount of features you plan on your game. The ideal thing is of course that you don’t add too many features, you keep the project small scale and because of this, actually get it finished. That’s very easy to say and when thinking, isn’t it very obvious as well? If every game developer out there would follow this rule, we would have so many completed games that they wouldn’t even fit into the whole internet. But still, very many of us can’t and won’t follow that rule. Why?
With Seeker: Quest I’ve grown around the project and I can see how awesome the game could become if I’m just able to achieve the planned features. I’ve been working on the code base to enable massive scaling possibilities for the game, which have obviously taken a big chunk of my time. Unfortunately, these scaling possibilities will most likely never be used. As a solo developer, you have very limited time or you need to prepare to work with the game for years. I want Seeker: Quest completed faster than this and to do that, I’ve been killing my darlings (features) with two hands for the past month.
So what I’ve done wrong with Seeker: Quest? Rule number one would be that do not get too attached to your project. With too attached I mean that your game is not supposed to have all the fancy fireworks you can imagine, but it should deliver that ONE thing as good as it possibly could.
Most of the games that are more or less caught the interest of players have that one thing they are talking about. If it’s the story as an example, you don’t hear many people saying something super awesome from the game's combat mechanics. Or if it is the combat mechanics, you don’t really people saying how cool the story was. Obviously I’m talking about small independent games here, since if you have a bigger team and budget you can deliver multiple polished features.
Aim to discover that one thing you’re trying to achieve and design your game around that. The rest of the features and “fancy fireworks” are just extra which you can deliver at some point, or leave those to the next project.
With Seeker: Quest the aim is to provide an interesting story in a casual way and offer fun & stress free monster catching in a top-down shooter game. Everything else is that “extra fireworks” we’re talking about. Now the aim is to focus only on these features and leave everything else out from the scope. If I’m able to achieve this, the game can be completed within some amount of months and I can focus on delivering quality features, rather than having a large amount of unfinished ones.
So because of this my second and last tip for getting your game complete, is to always design games with short development times. The longer you scale the project for calendar days, the likely you will discover something more interesting on the way and ditch the on-going project. There is nothing wrong in discovering something more interesting, but if you aim to get something complete, you may want to discover those a little later.
0 Comments