17
\$\begingroup\$

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 🤡

\$\endgroup\$
12
  • 7
    \$\begingroup\$ Related to what's said in an answer, when you have a bug, you should try to construct a minimal reproducible example where you try to reduce your code down to a smaller and smaller part, to narrow down where the issue is. If you understand your code, you should know what every piece/method/block/line should do, and you should be able to check whether it actually does that by executing just those lines with some fixed input, and checking whether you get the output you expect (you can also do this through a debugger). \$\endgroup\$
    – NotThatGuy
    Commented May 20 at 5:08
  • 6
    \$\begingroup\$ I wonder if you have too high of an expectation from yourself. Metroidvania, tile maps and combat: these things aren't easy. I took six years from my first published hobby game to when I was comfortable drawing a tile map, and nine years until I could create a platformer. There is a huge gap between Pong and Metroidvania! You can try more intermediate projects (perhaps Breakout, Snake, Minesweeper) as a stepping stone. \$\endgroup\$
    – user41258
    Commented May 20 at 13:48
  • 5
    \$\begingroup\$ It can be helpful to remember that every bug can be fixed. There's a fix out there, you've just got to find it. \$\endgroup\$
    – Omegastick
    Commented May 20 at 14:26
  • 7
    \$\begingroup\$ what exactly is your question? \$\endgroup\$
    – jsotola
    Commented May 20 at 18:39
  • 3
    \$\begingroup\$ The first step is to ask yourself if it's really a bug. Rocket-jumping in first-person shooters and a number of the signature elements of modern fighting games started out as bugs. (And then there's Goat Simulator, where any glitch that didn't actually crash the game was declared a feature.) \$\endgroup\$
    – Mark
    Commented May 20 at 21:58

9 Answers 9

27
\$\begingroup\$

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.
\$\endgroup\$
0
23
\$\begingroup\$

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.

\$\endgroup\$
2
  • 4
    \$\begingroup\$ +1! I think a combination of this answer is most likely to solve the OP's problem. Trying to add a feature and failing should never result in the whole project being cancelled (even for a personal project) unless that feature was absolutely critical or removing the feature is impossible. The accepted answer covers prototyping before committing to "absolutely critical" features, and this answer covers being able to back out the less important breaking changes. \$\endgroup\$
    – Tim C
    Commented May 20 at 18:17
  • 5
    \$\begingroup\$ @TimC I agree. I think the fear "I might run into a bug and need to cancel my project" is mostly an artefact of not really understanding how software development works in practice. At the start, programming seems mostly like straightforward assembly of a limited set of program constructs and API calls. Once you get better, you realise that there is preciously little that absolutely cannot be done in most production environments. \$\endgroup\$
    – xLeitix
    Commented May 21 at 8:55
13
\$\begingroup\$

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.

\$\endgroup\$
4
  • 4
    \$\begingroup\$ I think the most important part of this answer is to focus on growing experience and confidence. Yes, planning and prioritizing technical challenges is good advice to efficiently deliver a game, but it sound like OP's focus should currently be on improving their skills instead on delivering a full game. Basically a daunting unsolved problem that blocks the game from being made should be approached as an opportunity to learn about this problem, if it can be solved and how. \$\endgroup\$
    – Vallahga
    Commented May 20 at 9:51
  • 6
    \$\begingroup\$ Regarding resources, I would trust other experienced game devs over chatGPT. People will usually answer if they can and want to help or stay silent if they don't. ChatGPT will more likely give an answer to all of your questions, even when it doesn't truly have relevant info on it. \$\endgroup\$
    – Vallahga
    Commented May 20 at 9:54
  • 2
    \$\begingroup\$ @Vallahga People are usually better, yes. But GPT tools are more convenient and won't downvote you when it takes you 10 tries to figure out what you actually want to ask ;) \$\endgroup\$
    – Mars
    Commented May 21 at 0:47
  • 3
    \$\begingroup\$ Indeed, chatGPT is more likely to answer any poorly-worded unclear questions instead of first making sure it correctly understand the issue. Not sure it is a net positive. Though I'll admit people can be needlessly antagonistic toward naïve or beginner-level questions on this site. But to me the answer lies in finding the right people, the right community for you to take advice from. At least until you have enough experience to think critically on advice given to you by strangers or LLMs. \$\endgroup\$
    – Vallahga
    Commented May 21 at 8:50
8
\$\begingroup\$

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.

\$\endgroup\$
2
  • 8
    \$\begingroup\$ I think there's a critical idea that this leads to but doesn't say explicitly: By working with experienced people, you'll also see that they encounter bugs they can't solve, every single week. Then they talk, and figure it out. Or they debug it for a week, and then figure it out. Or they debug it for a week, and then come up with a plan to gather more data, and then come back in a few weeks. Every single week. Seeing them will help with the anxiety, and teach you how to solve similar blocks. \$\endgroup\$ Commented May 20 at 18:39
  • \$\begingroup\$ And I would guess the coders of life support machines and stock trading systems (while probably very skilled), are also probably shielded by a much beefier legal team. \$\endgroup\$
    – Mentalist
    Commented May 23 at 2:15
8
\$\begingroup\$

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.

\$\endgroup\$
2
  • 5
    \$\begingroup\$ If you end up scrapping code and starting over, beware of "second-system effect" where you incorporate all the things that you decided to skip the first time around, and end up with an unmanageable project. \$\endgroup\$
    – MadMan
    Commented May 20 at 19:35
  • 2
    \$\begingroup\$ "Second system effect" is itself a lesson you learn, and frankly, the motivations that underlie it are best understood through personal experience. OP is just learning, he's not a starving indie dev. Personally, I'm of the opinion it's best to bite off more than you can chew. You might be surprised with what you can do, and if you can't, you can always fall back and do something simpler. Part of the trick is planning for how to fallback, and recognizing when to fall back. \$\endgroup\$
    – 16807
    Commented May 20 at 20:54
4
\$\begingroup\$

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.)

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .