How do you cope mentally with one very long piece of work [closed]

Question

This is my first games industry job and my task is to take out one major game component and put in a newer one.

So far it's been 5 weeks, and I'm still just staring at errors. I think it could be months before it's at the point that it can compile. It's really getting me down. I'm just changing things over, I'm not really writing anything myself. it's just endless. I fix a thousand errors and nine thousand take their place.

I'm sure this must be a common thing, so I was just wondering, how do you cope with this? It doesn't seem like I can break it down into little chunks at all.

Answer 1

Welcome to the game industry :)

So you're doing a massive refactoring. Massive refactoring is Evil, but that's not the topic. You were probably given this task to test your nerves anyway, so don't give up on it.

My answer is: you have to break it down into little chunks. It'll be your daily routine in a few months, so you have to learn how to divide and conquer. It's basically your job. A few suggestions:

• Make sure you understand what this component is supposed to do. Play with what you have to take out and see what it does, ask your colleagues if your assumptions are right.

• You're rewriting this module for a reason. It might not be obvious to you, but if you were given this task it's most likely because something was so crappy that people feel it's better starting it over. Ask around: what are those defects?

• Try finding the core feature of the component you're rewriting, its very substance, the reason it exists, and start by getting this one working. It must be really tiny, as small as you can. Ask your colleagues about what they think this feature would be. If it's a GFX system, just make it display one polygon. If it's an animation system, just place one bone properly. If it's an AI system, just make it play an animation. Etc. etc. Just trash everything that gets in the way and gives you all those daunting errors. Don't get disturbed by the details, just get this core feature working as quickly as you can. Your implementation will be ugly, full of bugs and hacks and magic numbers and you wouldn't let anyone glance at your code, but that's not a problem.

• Once you've got this core feature, you'll already start feeling better. It's essential to see the result of your work as early as possible 1) for your morale 2) to be able to test it. So, test it, stress test it, torture it. If it crashes or shows some really bad bug, fix this. It's the heart of your module so rework it a bit and clean it up until you feel comfortable with it.

• Then show it to your colleagues and ask them if that's what the game needs. Ask for a code review: your colleagues will probably tell you about plenty of things that you didn't think of. You'll have to refactor again to make sure your implementation fits with what the rest of the team wants.

• Then when you feel ready for it, pick one of the other features you trashed earlier on, rinse, repeat. Make it work as fast as you can, rework, ask for a review, re-rework.

I have to put the emphasis one last time on this: communicate. Ask you colleagues, not only your lead, not only the programmers, everybody that will use or test or evaluate this system. Don't fear about asking stupid questions: when in doubt, it's always better to get the information right now than to wait weeks for a meeting or a review.

The reality of game programming is that you're not going to create brand shiny new systems everyday, it's a job of keeping focus and getting the things done quickly and efficiently. Pull yourself together, get to work, and good luck!

EDIT

There's extra info I find useful in Leo's comment and dhasenan's answer, I'm shamelessly steeling that from them to complete this answer.

I didn't write about how to deal with inter-dependencies. The module you're rewriting is probably deeply coupled with the rest of the game, that's why you get so many errors when changing something. So there's two solutions:

• If there are just a few dependencies, then you're lucky. The old and the new module can be kept in parallel for a while, you can even have a switch for your users so they can decide to change between the old and the new module whenever they need to. Just put a switch somewhere, in a configuration file or in a debug menu, and use it where-ever your module is plugged to the rest of the game. When your new module is ready for production, put the switch on by default. Later on, when the old module is not used anymore or when production needs to go on, remove the old module and the switch.

• If there are many dependencies, you have to unplug and re-plug them one by one. Try to keep both modules in the background, and each time you get a new feature to work, switch to the new module for that feature. I.e. unplug and re-plug what's related to this feature. It'll take you some time because it's probably more work than changing just one function call: some data structures might change, the program flow might change, etc. But it's still better than rewriting everything once and taking weeks to kill the compilation beast. If that's really impossible to keep both the old and the new modules in parallel because you module is so vital to the game, you might consider rewriting in place. But beware that this could mean that if the defects are in the old module's interface, you'll end up with the same defects. Anyway, if this happens, try taking advantage of this refactoring: you might be able to remove a few dependencies or to split the module in sub-modules for the sake of good software design.

If there's something specific to video game development, it's this: we're not doing rocket science, or a complicated research work, we're part of a creative process. When doing something, you have to craft a first version as quickly as possible so it can be tested, played, frown upon, and modified. You can't spend weeks doing "one very long piece of work" without delivering a bit.

Answer 2

You have to split up your task, but nobody's offering advice on how to do that.

• Do the new and old modules work together? That is, can you compile your project with both? This will let you at least compile and probably run automated tests at some milestones.
• Are you writing the new module? Or is the old one code that you own? Rewrite in place (insofar as the external API is remaining the same). If you fix one function at a time, you should be able to continue using the combined mongrel API, to some extent.
• Are there other projects at the company that will be making a similar transition? Write wrappers around these modules to make the process easier next time. It might be worthwhile doing this in the meantime.
• Can you comment out or avoid compiling chunks of your dependency chain? If you have half a million lines of code total, maybe you can split it up into twenty chunks that compile independently, get one working in a couple weeks, and then move on to the next. Maybe not fully independent chunks all the time, but then you can do it in order of dependencies.

Also: ask your manager for advice. I would probably start off describing the problem: it's taking so long to get things compiling properly that it's hard to keep track of changes, which will make it harder to debug once you have something you can test. Then I'd mention a potential solution, and ask: "How do you recommend I implement this solution, or is there a better way of doing this entirely?"