Anxious about possibly hitting bugs i can't solve and having to cancel my games

Question

I've been doing game Dev for 5 months now and I've started small with following Pong and Flappy bird tutorials and other simple arcade games, and when I feel like I've reached a ceiling with the complexity level i move on to something more complex (Asteroids clone, simple twin stick shooter ,etc...) and when I'm done with a tutorial, I like to add my own things to them, as in adding entire new features to them or new levels or sort of "remixing" them into something new and maybe adding new original graphics.

I make sure to never bite off more than I could chew with projects, so I wouldn't have to inevitability cancel them, I always divide the entire project into parts inside my head, these parts are the main features of the game (movement, tile-maps, combat), and then I divide each feature into lines of code/functions that I can write in Godot.

And with each line of code I think "do I have enough coding knowledge and experience to implement this feature in the game without hitting a big roadblock and having to cancel the game?" and if I feel like I can do it, then I just start with the project.

But last night I got kinda stressed because I thought that I might have to possibly cancel a project that I really cared about.

It's a really small 5 minute prototype for a Metroidvania, I'm writing most of the code and getting the assets from a nice tutorial series, so yeah everything was going smoothly until I encountered a tricky bug that made the player jump too high, which would break the game since the player would reach places they weren't meant to reach yet. I posted the bug on this forum and other sites and i got a response within 5 minutes that resolved my issue with 1 simple line of code.

But while I was typing the post and trying to solve the bug on my own I honestly felt pretty worried, it's because the movement code for my player character is relatively complex and I wasn't sure where the bug is exactly so I posted the 100 or so lines of code that were related to movement, I was thinking stuff like "what if nobody answers my question because nobody's gonna read 100 lines of code?" "what if I had made a mistake and bit off more than I could chew despite all my careful planning and scoping?" "what if I'm gonna have to cancel it?" "maybe I shouldn't have gotten attached to this project..."

I feel kinda stressed now because I'm worried about encountering these scenarios.

I feel like maybe I'm overthinking this and I just shouldn't hype up projects too much in my head + not worry too much since the bug could literally be solved in 5 minutes.

And yeah I tend to always worry about these sorts of things 🤡

Answer 1

It's not unusual to worry about whether or not you have the ability to finish a technical task.

Minimal Working Examples

Your main problem boils down to how you develop... by adding bits and pieces into the existing game until it becomes difficult / complex to know what comes next, or how to solve bugs, especially if you don't completely understand the initial game code you built upon.

It is often preferable to do small "experiments" or Minimal Working Examples, i.e. a small program proving a part of your game can work as you imagine -- should take 1-3 days, and no more than 10 days. If it takes longer than that, you should consider splitting it into multiple MWEs.

MWE's are seperate from your game's codebase, for later integration if they work out.

Not only do MWEs minimise the complexity you have to deal with by not being combined with your game initially, but they are an excellent form in which to share your code if something goes wrong that you need help with, e.g. here on gamedev stackexchange or over on stackoverflow.

Over time, you may learn to build your projects by a repeat process of building external MWEs and integrating these into your game one after another until you have a complete working product. Integration itself is nearly always a challenge, so time also has to be set aside for that.

In an ideal world, you'd write these as modules that can be tested seperately from the main game, but maintaining them to be runnable separately does require additional effort over time.

This approach furthermore encourages modular design and separation of concerns.

Prioritising Technical Risks

It is essential to identify the most severe impending development risks as early in the development cycle as possible, prioritise them according to highest risk, and find out whether they are possible to achieve or not, before addressing simpler tasks wherever possible.

The moment one becomes aware of high risk factor issues looming, one should immediately note them down, consider them, consider alternatives, and if we decide to go straight into the risky issue, reduce the priority of other tasks accordingly.

We aim to resolve high risk issues in the shortest timeframe possible: we either prove the technical feat viable, or prove it non-viable and focus on coming up with and implementing alternatives.

For larger, more complex projects, some time is often allowed to pass between recognition of a looming technical issue, and addressing of that issue. This is the idea of "no sudden moves". A deeper analysis is often necessary (a) to thoroughly understand the required set of changes and the logical implications thereof, and (b) to justify the cost in time / human resource to solve it.

References

"Technical risk management priority" is my Googling suggestion for you, specific to "games development". There are a ton of resources on risk management within IT projects in general.

You should also Google "emergent complexity", a major issue in games development and a major source of interest in game design.

Two excellent books which address risk, complexity and timeframes specific to game dev are:

• Agile Game Development with Scrum by Clinton Keith
• Secrets of the Game Business by François-Dominic Laramée.

Answer 2

Use version control

I think major stress relief comes with version control. More so when you really care about tracking features in separate branches and commit often with each task completion. When you identify issue you are then able to go back in time and see when the issue appeared for the first time (or as happens in teams, "hey, you broke it with your commit xxxx, fix it"). Even when you notice issue right away it is easier to solve issue comparing old and new code than just thinking about your changes. In the really worst case you can even revert back and try again.

There is always debug

This has nothing to do with planning, just a note about not to worry that much, because there is ultimate way to investigate issue when you do not know what's going on - debugging. To be sure I checked if Godot supports it and it does (as should any normal IDE). Unless the issue is simple one (like oh my, I forgot about this and that case) it is often the case you do not really know what's going on under the hood. You can often spot issue just by stepping in your code, seeing where code goes and checking some variables. In hard cases stop the time, make a snapshot of variables and think about what that really means.

Answer 3

Engineer's answer is a solid answer to the title question, but it sounds like in your specific case, you just need more practice understanding what your code actually does. Working from tutorials and from templates is helpful--as a next step, try remaking the same tutorials from memory/from scratch.

It sounds like you'll find that much harder, but it will deepen your understanding of what is going on! Once you actually understand what you're doing (the details, the big picture, the theory), you'll find that there are fewer tasks where you have no idea how to solve them on your own.

There will always be tasks that you don't know how to tackle on your own though--for that, Engineer's answer helps! You can also ask other programmers or even ChatGPT type services. Both of these require you to have a grasp of what it is that you want to know though.

Answer 4

This is just intrinsic to software development. You've got a bug. Software always has bugs. Major games ship with them, and end up profitable enough anyway. It's a game, it's not hooked up to a life support machine or a stock market trading system with real money.

For actionable advice: if you're a new developer, it is much better to collaborate with experienced people rather than do everything on your own. It's less lonely and you're less likely to panic; they can spot things you miss, and vice versa.

Answer 5

Personal projects never cancel, they just are put on hold

i might have to possibly cancel a project that i really cared about

Nothing can force you to cancel a project you care about. Even if you get part way through and realize that completing it is currently beyond your abilities, the worst that will happen is that you shelve the project for awhile until your abilities catch up to your vision.

I know of several indie games that have been rebuilt from the ground up because the developer wasn't happy with them, or because computers had changed too much since the project started. This might seem like a scary prospect, but no work is ever wasted. Even if you have to scrap all your code and start over, the lessons you learned (about coding and about your game) will stay with you. Your second attempt will be faster and better due to the work you put into the first attempt.

Answer 6

Fixing the bug and solving the problem aren't the same thing.

In this case you were able to fix the jump height calculation and that's great, but sometimes you may find that something really can't be done. Say you were using a third party library that had the bug with the jump height and you really need to keep using the library but you don't have access to fix it or you don't have time to fix someone else's stuff or whatever, it simply can't be fixed.

You could still solve the problem in a variety of ways. Maybe you put an invisible ceiling that limits jump height. Maybe you put a visible ceiling and some plot where the ceiling gets blown away. Maybe there's a laser that causes damage if you jump too high and players have to figure out how to turn it off. Video games are full of these sort of "fixes" for problems that couldn't be "fixed".

This may require changing your plot or some game play element or whatever but that's OK. It's very rare that such a specific element is critical to the whole game, even in a small game. Remember the people playing the game will never know what idea you started with, they only see the final game. So they aren't going to look and say oh, you never fixed the jump height bug, they're just going to think "yes, of course there's a ceiling here, that's obviously just how the game is".

The real problem isn't the jump height bug, or even how to prevent the player from progressing before planned, the real problem is making a good game in some kind of reasonable time frame, and that is usually a very solvable problem if you approach it with some flexibility.

Here's a YouTube video that analyzes a point where this didn't go well (Cyberpunk 2077) from a Software Engineer point of view. He says it much better (and funnier) than me, but the short version is that the long answers aren't unique to GameDev, they're also over on Project Management and Software Engineering, because the generic problem of making and shipping software is very much the same. And all the generic solutions (understanding the iron triangle, managing expectations, etc.) apply just as well to GameDev as to boring enterprisey software.

(But also, yeah, listen to other people about how to use the debugger.)

Answer 7

I like that @Piro pointed out one of the basics: Version control to make sure that you can roll back any breaking changes.

As @pjc50 writes, the issue you are facing is intrinsic to software development.

You will write bug and you will stumble on problems that seem unsolvable and sometimes you will face/feel strong desperation (I have observed it myself and on colleagues too).
It will take some training, but you will overcome/solve these problems and learn to trust yours skills and your ability to fix (or work-around) issues you thought would be impossible to resolve.

With time, you get confidence. After almost 15 years in software development I still experience this feeling of desperation from time to time but i know this too shall pass.

Answer 8

Im not sure how easy this is to implement for physics code in a game, but within software development this is usually what automated (unit) tests are for. Thats were you code up wanted behavior and use some automated way of checking them. This means when you find a bug, you can just add a new testcase to cover the problematic scenario. When you fix the bug, this will guard you against regression. Meaning it will let you know if fixing the bug broke something else. Large projects become a nightmare to maintain without automated tests.

Answer 9

To add to the other answers here:

It depends on why you're making a game. If this is a job, or you have other hard, important constraints demanding that you get this finished in such-and-such a timeframe, then yeah, it is correct to worry about whether you can finish what you're planning.

However, if you're making these for fun or for learning, I think you're being too careful. I've been programming for maybe 20 years, now - some for work, some for fun - and I'd say that many of my personal projects are quite ambitious. For many of them, I end up needing to reduce scope, and some of them I do end up "cancelling", as it were - I eventually decide that getting it to do what I want would require more work than is worth it, and I move on to something else. However, many of them I do manage to get to a point where it's useful, perhaps more than if I preemptively avoided the project. Almost never have I regretted starting a project. Furthermore, I think that biting off more than you can chew is a good way to increase the amount you can chew, as it were, teaching you how to manage the complex problems you encounter, as well as teaching you how to manage scope - i.e., when it turns out you bit off more than you thought, how to fix it.

In ways, it boils down to: what are the actual consequences of canceling the project? If the answer is "people are angry and I get fired", then yeah, be careful to scope appropriately before starting. If the answer is, "well, nothing, really", then, maybe you shouldn't be worried about it, and just try it and see what happens.