Development How do YOU decide if a game you're working on is to ambitious for you and a discontinuation of your game needs to be done?

flyinian

Member
Pretty much what the title says and,

I've been working on my game for a good while now. Roughly the beginning of 2020 on and off. I'm sure I've stuck in a few hundred hours or more into it by now.

I've been trying to get a playable version of the game released since the end of 2020 and have had to delay it due to unfinished/broken parts of the game.

I've spent more than I want on debugging my code just to get a little thing in the game to work. Example: A max buy system has taken me much much longer than I thought it would and I ultimately scrapped it and decided to work on it later and find a new way to implement one.

Now I'm here debating on what to do with my game. I may just clean it up, comment it, get it working, and release it and discontinue the development of it. Just so, its not a complete loss.

Any suggestions along with on how you decide when its time to discontinue a project?

Thanks for the feedback.
 

Tyg

Member
Sorry to hear that, putting a lot of time into a project can sometimes be frustrating
if you break each part down , like the menu system or state machine and just get that part right then it could be used in other games
if you want to continue there are lots of helpful members, sometime you just need to look at it differently or there is an existing system for that part
let me know if you need some help and ill help when i can
if your tired of the game, make a fresh one with a different theme, re use some code that you know works
it might bring back some excitement, there are lots of new features, i havent even tried the particle system or sequencer or the new sound stuff
im not saying keep at it, but if you want to smash through the bugged parts ill help out where i can :)
 

flyinian

Member
Sorry to hear that, putting a lot of time into a project can sometimes be frustrating
if you break each part down , like the menu system or state machine and just get that part right then it could be used in other games
if you want to continue there are lots of helpful members, sometime you just need to look at it differently or there is an existing system for that part
let me know if you need some help and ill help when i can
if your tired of the game, make a fresh one with a different theme, re use some code that you know works
it might bring back some excitement, there are lots of new features, i havent even tried the particle system or sequencer or the new sound stuff
im not saying keep at it, but if you want to smash through the bugged parts ill help out where i can :)
Thanks for the reply as well as the offer to help.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
My own rule(s) of thumb:

  1. THE MOST IMPORTANT! Are you enjoying the development? If not, then time to drop it and start something new!

  2. Do you have a clear goal and strict set of parameters for the game? If not then, you may want to consider dropping it... Projects that don't have a clear goal and "finish line" can drag on for years thanks to feature creep and the constant change of mechanics/story/gameplay...

  3. Finally, are you on the last 10% of the project? Personally I find that last 10% of ANY project to be incredibly difficult to get through... Usually because it's all about preparing to publish and promotion, which are two things I find really difficult to deal with and the last 10% can often take up >50% of the development time for me! If this is the case then all I can say is knuckle down and get through it, you're almost there!

Ultimately, it's up to you to decide whether to drop a project or not. All I can really talk about is my own experiences, and for me a dropped project is rarely a waste of time because I've have learned a LOT from making it and quite often I can go back and "cannibalise" what I've created so far for other projects. I've also started projects and then dropped them, then gone back to them YEARS later and finished them! The little physics game I made - "Microscope Madness" - is a great example, as I started that about 10 years ago and after about 6months of dev I was really bored with the whole concept so dropped it. About 7 years after that I had a look through the project again and thought "y'know, this is nearly a finished game, let's just do it!", and finished it in about 3 months!
 

Alice

Darts addict
Forum Staff
Moderator
  1. THE MOST IMPORTANT! Are you enjoying the development? If not, then time to drop it and start something new!
I'd make this point a little more nuanced.
Any larger creative project has these less-glamorous moments when the creator needs to struggle against their lack of motivation/inspiration, and they need to overcome these instead of waiting for a creative rush.
But if the struggle constistently continues without any moment of joy about the project, then I guess it indeed would be the time to stop.
Alternatively, when you reach the point when you don't enjoy not just the development but also the game itself, no matter what improvements you add.
 
Last edited:

pixeltroid

Member
Any larger creative project has these less-glamorous moments when the creator needs to struggle against their lack of motivation/inspiration, and they need to overcome these instead of waiting for a creative rush.
IMO, a big mistake many gamedevs make is to treat their game project like a super-artsy vanity project. That leads to the mindset of "I'll produce work only if I'm in the right mood or feel a certain level of inspiration". The problem is that feeling motivated / inspired is a matter of emotion. Being disciplined is a mindset. Discipline, not inspiration produces results.

Sure, game design is art and it's good to be emotionally attached to it and all that. But from my experience, more work gets done if the project is handled like a dull normal blue collar job with a real deadline, and not an exotic hobby.
 

Xer0botXer0

Senpai
I don't do this, but the most obvious answer is to make a game design document, part of it which breaks up all the forecast work, with that you can tell if it's too much.

There are two other things though,

If you do what I do, and not much preparation, then you'll know ..well either you can make the game easily - no problem at all..
or you're well aware that there will be many challenges ahead.

So in preparation for the nether, is really beyond my scope of expertise, but I can say ..be ready for the challenges, be aware that they will arise, and when they do will you half ass it, learn from it, give each feature your all, spent 10 years for a great game or 1 year for an inferior game, there's a lot of decision paths.

Usually I don't decide this, well.. I'm not going to make the next COD game, the impossibility of that is right in my face. It boils down to man hours.
But I can make a pacman or tetris clone without much difficulty, that's just as obvious to me.

In my case what makes more sense is to if anything, work on time management, see how long certain tasks take, get some idea of how many times you'll have to do it, get some idea of pretty much how long things do take and work out the total minimum hours it'll take you to work on a game.

The difficulty is that we can't see very well into the future, in a mystical/magical sense. Predictions are works of art, which themselves are difficult to master.
 

Yal

šŸ§ *penguin noises*
GMC Elder
My goto development strategy is to do small trivial changes first (because checking stuff off your todo list refills your motivation), and then for large things, either break them down until they're a pile of small trivial changes, or ignore them until they go away. (I've scrapped a lot of ideas if they felt like too much work, especially if the added value is dubious)

Treat motivation as a mana bar, not a stamina bar: it goes down as you work on your game, and the only way to refill it is to complete new features. If you run out of motivation, you can't work on the project anymore, so you need to plan your work so you can get those refills between large annoying tasks.

Ideally you should make your code in reusable packages (e.g. init/step scripts you can copypaste into another project unchanged) so that any work you pour into this project will also affect all your future projects, that cuts the loss (if you abandon a project) down considerably.
 

tetris_mess

Member
I study the chapter and plan if anything will go wrong in my project and I also know if there will be any hiccups in the project. Knowing what to do when things go wrong with the release of a product guides my entire project as much as possible to avoid issues that will slow down my projects as much as possible. It really is necessary to already have a plan when ramping up production as problems need to be solved and issues need to be addressed before you roll out. The chaos in the environment is under control in a controlled environment. All your goals need to be isolated.

In a project, knowing that the project will continue because I did my market research in a complex environment oriented around a design thinking approach, these conditions determine the continuation of the project. All quality assurance checks have to be passed before any release. The situation is a very transactional one. There are the critical stages in the environments and materials that are required and the action that is necessary on my part. When anything starts to become a necessity, there aren't requirements being met, and I know something is wrong in a critical stage of development.

There are creative endeavors and trust issues with team members and the ability to continue getting work done that could really end everyone's day as well, so I make sure to be on top of the relationships and self-awareness management. If people are or aren't working together, that sometimes does end a project.

Really being engaged in a project is what continues to motivate people, and the power of kindness continues to empower teams of managers and other team members.

In you, and no one but yourself...you are the only one who can be at the resort of your own default mode network in your brain. Judging these properties, you know the signs in yourself when it is time to press the pause button to move yourself to a different resort. You have to know for yourself when it is time to take a break from your current assignments.

When it is time for a retreat, find a resort, and engage in some radical ideas that express new ways of thinking. If you can't take a radical approach, take time from your creative projects to go to health retreats or consider some other form of relaxation that will reset your brain so you can come back to your project. Maybe even go see a psychiatrist and check into a mental hospital. The area of design, building, and production in a development environment makes safety a priority. Make sure that you are clear about your policies in your environment, having established what your code of conduct is. Show people that you value your work ethic, and always continue to strive to boost morale, by lifting up people's spirits, soothing everyone on your teams emotionally, to bring up the mood, so you are scaling yourself to the level others are on emotionally.

Also, have point sources of intelligence. Intellectual insight is key. Be where you are gathering all your sources of intel constantly and protect your project. Does your project have intel inside of it?

Your key sources of intel are also the people who advise you in matters you aren't able to control. If you can't counsel yourself, seek counsel from other reliable sources of intelligence. Always continue where you have gathered sources of information, at point sources of intelligence, to continue gathering your sources of intel. Your projects need intel inside of them.

If you are able to follow these guidelines, you will guarantee results, and you won't make any promises that are too big.
 

flyinian

Member
I study the chapter and plan if anything will go wrong in my project and I also know if there will be any hiccups in the project. Knowing what to do when things go wrong with the release of a product guides my entire project as much as possible to avoid issues that will slow down my projects as much as possible. It really is necessary to already have a plan when ramping up production as problems need to be solved and issues need to be addressed before you roll out. The chaos in the environment is under control in a controlled environment. All your goals need to be isolated.

In a project, knowing that the project will continue because I did my market research in a complex environment oriented around a design thinking approach, these conditions determine the continuation of the project. All quality assurance checks have to be passed before any release. The situation is a very transactional one. There are the critical stages in the environments and materials that are required and the action that is necessary on my part. When anything starts to become a necessity, there aren't requirements being met, and I know something is wrong in a critical stage of development.

There are creative endeavors and trust issues with team members and the ability to continue getting work done that could really end everyone's day as well, so I make sure to be on top of the relationships and self-awareness management. If people are or aren't working together, that sometimes does end a project.

Really being engaged in a project is what continues to motivate people, and the power of kindness continues to empower teams of managers and other team members.

In you, and no one but yourself...you are the only one who can be at the resort of your own default mode network in your brain. Judging these properties, you know the signs in yourself when it is time to press the pause button to move yourself to a different resort. You have to know for yourself when it is time to take a break from your current assignments.

When it is time for a retreat, find a resort, and engage in some radical ideas that express new ways of thinking. If you can't take a radical approach, take time from your creative projects to go to health retreats or consider some other form of relaxation that will reset your brain so you can come back to your project. Maybe even go see a psychiatrist and check into a mental hospital. The area of design, building, and production in a development environment makes safety a priority. Make sure that you are clear about your policies in your environment, having established what your code of conduct is. Show people that you value your work ethic, and always continue to strive to boost morale, by lifting up people's spirits, soothing everyone on your teams emotionally, to bring up the mood, so you are scaling yourself to the level others are on emotionally.

Also, have point sources of intelligence. Intellectual insight is key. Be where you are gathering all your sources of intel constantly and protect your project. Does your project have intel inside of it?

Your key sources of intel are also the people who advise you in matters you aren't able to control. If you can't counsel yourself, seek counsel from other reliable sources of intelligence. Always continue where you have gathered sources of information, at point sources of intelligence, to continue gathering your sources of intel. Your projects need intel inside of them.

If you are able to follow these guidelines, you will guarantee results, and you won't make any promises that are too big.
Thanks for the reply. Definitely well worth the read.
 
B

bitwiseOperator

Guest
Is it your first major project? Sometimes it's better to get a few smaller projects out first to get a feel for the whole development process.
 

Rob

Member
It sounds like you're towards the end of development and if you can find it in yourself to finish, you'll have that under your belt for the rest of your life and youll be glad you did it.
If you don't finish it, don't beat yourself up too badly though and try and learn from any mistakes you made!
 

Director_X

Member
Whenever I get stuck or bored with a particular project, I simply start another totally different project until I get stuck or bored with that one, and so on and so forth. This way I more-or-less prevent "burnout" and frustration with any particular project.

Over time (as I encounter new code and concepts and gain more experience) I can get inspiration or solutions to solve my older problems and then I can re-start work on those partial projects till I get... you guessed it... stuck or bored with them! ;)

Yes. I do have a dozen partial projects.... but they'll get there some day! :) One day at a time......

Don't give up buddy!
šŸ‘
 

Wainggan

Member
I don't do this, but the most obvious answer is to make a game design document, part of it which breaks up all the forecast work, with that you can tell if it's too much.
I started using a program called Pivotal Tracker, which is basically a todo list for projects. It is also completely free if you have less than 5 members!

Here is an example of it for my game. I kinda add things into it as I go
When I realize I need to do something, like adding a feature, rewriting code, drawing sprites, I add a story about it.
For example, I need to draw a sprite for... a car. I create a story with the name of "Graphics - Draw Car Sprite"

  • When I start working on it, I press "Start

  • When I finish and implement it, I press "Finish"

  • When I push a build with the feature, I press "Deliver"

  • When I decide that the feature works correctly, I finally press "Accept"

It helps me remember what I need to do, and prevents me from adding things that I don't actually need
 

otterZ

Member
Maybe subdivide the game into parts. Treat each mini part as a separate project and slow everything down. As in first get the UI polished, then the first room running smoothly, then levels 1 to 10 etc (just an example). . . . Or whatever applies to your game project. There will be times when a bug pops up in an already polished part, or players say they are unhappy with something - maybe treat this as a puzzle to solve / new programming skills to be obtained.

I think it maybe comes down to mindset, as in if something is 'broken', or if it is just a puzzle challenging you to solve it.

For example, I made a UI in my game and players said that it looks depressing and unfinished. I was a graphic designer for 13 years so I could either take that personally or admit that I am not a game UI designer and that using GMS's draw tools was not the answer in this case. So I am learning Inkscape and studying game UI design and I hope to fix this in the next 2 months, leaving my ego at the door and listening to players. Plus I have had issues with bugs, glitches etc, but they can be fixed - if something 'broken' is looked at like a mini puzzle. At times I really don't feel like I know what I am doing even lol - but even ignorance has a hard time pushing back against tenacity.

Personally, my mistakes teach me the most. Or what I think is great and actually gets a big thumbs down by players teaches me way more than the things I get right. So, maybe embrace those 'broken' parts as a learning experience and tackle them one by one - then, when they become 'unbroken' you know you are really on fire . . .
 
Top