Stuck in late development

If you want to finish the game and the problem holding you back is bugs then you need to do debugging, there isn't really any way of avoiding it. Good tools can really help with this -- are you using a good set of tools that provide debugging facilities, and do you know how to use them? If not, you'll probably want to spend some time learning about them.

You might consider applying the user pain metric to your bugs and only dealing with the ones that are a serious usability concern. Hopefully if you've structured your code well you will only have to consider smaller sections at a time rather than hunting around the entire code-base.


Unfortunately if you've gotten to a near complete state and allowed bugs to remain in the software till this point, you will have a lot of code to go through. It's often easier to ensure you're properly testing your code during development and try to deal with the majority of problems as they arise; you could perhaps even use TDD.



It's up to you really... if you want to finish the game, you need to put in the work to do so. If not, you could perhaps try to take a better approach your next project so that you experience less problems, but again at some point you will inevitably end up with some work (often debugging, documentation, or adding final usability features) you don't really want to do -- if finishing a game is important to you, you'll need to such it up and do the work.


Does that help at all?

Do professional games go through this or do the pros never make such mistakes? Will I ever achieved pro-dom?

Maybe the reason games like Counter-Strike and Rappelz are successful is because they haven't gone through such phases. They are the product of a bug-free development. Maybe it's because of the path/design I've chosen that it's so prone to bugs.

I'm going to get a BSc in comp sci later and wonder if this will help me at all. I know it will help in understanding the math of BSP's. But I don't see how it'll help my RTS project.

I'd use a simpler design for the economics of the game but I just don't find it interesting then.

At my age John Carmack released Wolfenstein 3D and then Doom the next year. But maybe it's too much to compare myself to the pros. Technology-wise I am ahead of him at this age (he started off doing the Commander Keen platformer series, well, not really started off, but ...). I wonder if I will progress. I've been stuck with my FPS for how many years now with stuff I learned off of gametutorials.com. But I've learned to code on linux and put the server on Amazon. Mmm...

Maybe Counter-Strike/Half-Life/Quake, StarCraft, and Rappelz are historical accidents where the developers got it right the first time. And why they're so rare.

Do you mean "bugs" in the programming sense or in the logic sense?

If you make programming mistakes, it is not so hard to fix them. You just have to spot the bug, trace it to its origins and fix them. Familiarity with your tools (language, compiler, debugger) makes that much easier. Every game has bugs, the successful ones merely fix the important ones. Think of, for example, Fallout 3, where you can encounter bugs almost everywhere (a consequence of open and dynamic world). But the important thing is they should not break the immersion of player (for example, broken questline or game crashing to desktop always does that).

If you make logic mistakes, you should fix them immediately when you realize them. Otherwise, it is getting worse and worse because you surround the mistake with more and more code. That makes fixing the code without rewriting the entire project almost impossible without using a lot of kludges and hacks.

Also, it is a mistake to assume that successful games didn't have serious bugs / logic mistakes when in developement. The point is that noone makes code / logic without mistakes. But the key to not having bugs in the released product is fixing the known bugs, testing and iteration.

Skilled professional developers are able to avoid some common bugs and design mistakes due to their experience -- and that will come to you with practice if you write enough software -- but they still have plenty of bugs, and do not always choose optimal designs.

So why isn't their software buggy like yours? Simply because they took the time to fix the bugs, either before release (perhaps using a metric such as user pain to decide when the product was acceptable for launch) or in post-release patches as they discovered more problems. Fixing bugs can be tedious, and it isn't always a very exciting part of software development -- but it's something you have to do if you want to release a quality product.


It isn't a problem that your software is buggy. That's perfectly normal, and as a beginner it would be pretty surprising if there weren't lots of bugs.
It is a problem that you don't want to spend time fixing those bugs -- if you want to finish your game, you have to spend the time and effort to do so -- skilled professionals have to spend lots of their time fixing bugs.

Maybe Counter-Strike/Half-Life/Quake, StarCraft, and Rappelz are historical accidents where the developers got it right the first time.

They didn't get them right the first time -- they made mistakes during development, but they made the effort to fix those mistakes before they released the games to the public.


Formal education will probably help you in three ways:

1. You'll learn different techniques you can apply to minimise bugs and make it easier to find and fix them when they occur.
   
2. You'll hopefully write more code along the way, which will give you more experience. It is only by having first-hand experience of why certain designs are bad that you can learn to avoid those problems in the future.
   
3. During your course, you will be forced to do things (homework, classes you don't particularly enjoy, etc.) you do not find particularly interesting. If you want to release complete and polished products, you have to do the bits that aren't fun such as debugging, not just the interesting parts where you figure out how to make the game play work efficiently and implement cool effects.
   

If you already have an almost complete game that mostly works, then you've done better than many other people who set out to make games. If you want a finished game, you'll need to do the extra work to finish it.

The only way you can become a "pro" is through continued learning, effort, and practice. You will make hundreds, if not thousands of mistakes along the way -- every skilled professional has. You will get to solve lots of interesting problems, but you will also have lots of tedious work, and will sometimes encounter problems that make you want to punch a hole in the computer.


If you do all that, one day you will be a pro.
If you don't do all that -- because it's boring, or you think it's not worth the effort, or it's too hard, or any other reason -- then you will be a beginner or intermediate coder forever.

The choice is yours.

To save time debugging in the future, design your code around making it easy to debug latter on. The following is a list of things to impliment in future projects to reduce the amount of time spent debugging. (You might need to google some of the terminology used in these steps)

1) Logging of all input, output, events, calculations and errors to an output file.
2) Write out a game design document before coding game, based on this document write out every possible use case, then every possible test case.
3) Use a unit testing framework, apply all assertions from test cases made earlier in step 2.
4) Use a documentation system like doxygen, helps you learn to better comment code.

Many (most?) games have elaborate debugging systems / tools built for them that you never see as a player. There are certain things you can debug with an IDE debugger, but other things are incredibly slow and tedious to debug this way (often AI) and can be easier with to debug with a custom system often involving lots of logging, GUIs in the game etc.

It can be a bit of an effort to pull your finger out and write initially write these tools but once you have them you realise you couldn't live without them.

At my age John Carmack released Wolfenstein 3D and then Doom the next year. But maybe it's too much to compare myself to the pros.

It's too much to compare yourself with John Carmack (not that you should waste time on comparing yourself with anyone).

He started programming when he was very young, and it took him more than 10 years to actually gain the skills required to make the engine for Wolfenstein, and Doom after that. Not to mention that he was working on these games with an equally skilled team of programmers/artists.

John Romero talks about it here.

Writing good code from start is always easier than "debugging things to existence". But what to do if you already have a bug-ridden code base?

1. Admit, that it is not hopeless
2. If you wrote the code yourself, take some time off. Work on something else. Rest.
3. Take a fresh look at your codebase.
4. Write down the structure of your code.
5. Start writing down bugs. Assign priorities to them.
6. Work becomes manageable.

They say the only way to learn is through mistakes. Only geniuses learn from mistakes done by others. For every bug you fix, I promise you will learn something that will be of help for you in the professional life as a programmer.

Mistakes because of bad design is usually harder to fix. Talking about personal experience, I have to fight with my lazyness. Usually, it is easy to recognize (afterwards) how something really should have been done. But taking the time to do this redesign is very rewarding. It is not at all uncommon that unexpected benefits materialize, leading to unpredictable boost in creativity. That is what makes programming fun!

There are moments, after a thorough redesign, that I just do nothing but stare at the result and enjoy it. I show it proudly to friends, and they try to show some enthusiasm for a design that is very obvious.

Don't lose hope in what you've worked so hard for, if you ever watch the movie, Indie the movie (Which is a documentary on indie developers) I noticed that the main thing that the majority of them felt was hopelessness. But after they were proud with what they created, plus I've been needing a good RTS

Your problem is quite obvious. You have tried to take on more than you chew. You simply need to hire another programmer to help you finish up. And yes, you can find other programmers who will go after your bugs and fix them. I would recommend one of the many freelancing websites.

All the successful projects you mentioned were completed by at least a handful of programmers. Some of them by a small army. And here you are, trying to do it all alone. It is ok to ask for help.

Maybe the reason games like Counter-Strike [....] are successful is because they haven't gone through such phases. They are the product of a bug-free development.

Oh god no.

I played the original CS games back on the HL engine; between the HL engine bugs and the CS game bugs it certainly wasn't bug free.

There was the old problem of 'bunny hopping' which was a movement bug.
There was a CS Beta 6.0 release where the hand gun aiming was off by about a foot.
There have been reload bugs.
Logic bugs.
Graphical bugs such as the simple Half-Life shadow system showing shadows through the walls.

Believe me; Counter Strike had and still has bugs.

Where you can getting confused is that you don't see the worst of them because they are caught internally before they are released; if they were developing your game and came across this bug then they would fix it and the end user would never see it.

All game development has bugs; as to how many the end user sees is another matter but as the developer you can see behind the curtain and have to deal with them.

If any bugs can delay the shipping of a product, they will.

- Murphy's Law of Programming

Do professional games go through this or do the pros never make such mistakes? Will I ever achieved pro-dom?[/quote]
Every coder, no matter his age, skill, or experience, creates bugs. However, "pros" know how to fix them efficiently (this is what beta phases, playtesting, QA and code reviews are for). There are many types of bugs. Depending on your experience as a coder, it is generally fairly easy to identify which category any one bug fits in, and decide how hard it will likely be to fix it. Here are some examples of bugs you may encounter (or have already):

Your sample output is missing the first line of data. Your GUI says your player has one bullet left, but he won't shoot. All your sprites are drawn except the last one. You deftly browse your code to the correct line and chuckle as you realize your loop or condition has a one-off error. You correct the bug, and everything works fine. Hurray!

You fire up your program after a sweaty two hours of restless coding. You hit "Play", but nothing happens. You click again, and again - the game just won't work. You read through some of your GUI code, and realize you wrote & instead of &&, messing up a boolean condition on the mouse position, and spitefully ignored the compiler warning, because warnings are for wussies and just run my code already. You remind yourself to look at the compiler output from time to time and easily fix the offending line.

Your game is running fine. However, you are unhappy because every now and then, it will suddenly freeze for no apparent reason and you need to kill it from the task manager. You are aware that your game uses multiple threads, because multithreading is cool, and you have read horror stories about race condition and mutex deadlocks on the web. After a few hours, many cups of coffees and several kilobytes of skimmed-through log output, you discover an edge case in which your render thread *could potentially* finish its frame work before the logic thread, something completely unconceivable to you because your graphics effects are so awesome, and since both threads need to lock the log file to write information you will never need to read anyways, the lock would enter a deadlock state and your main loop will be stuck. You correct this by introducing a condition where each thread is aware of who holds the lock, and you note this as bad design, to be fixed in an upcoming version - because todo lists are also cool.

You have encountered the most difficult to track down bug in all of existence. You get shivers up your spine as you slowly realize that your code contains an Heisenbug: a bug that appears only when you are not looking out for it, and vanishes as soon as you attempt to track it down. No amount of debugging or desperately printing out variables will help you here - your only chance of survival is your own brain. You must analyze the code line by line, several hundred times, until you finally discover where you went wrong. If at all possible, brief somebody else on the code and have him debug it - it is well-known that programmers are partial to their own code and will have difficulty locating their own bugs.

A friend has inserted a header file containing a single line of code akin to #define true false, named it stdcmath.h (a plausible name for a standard header which does not actually exist) and included it in your program, password-protected the extra file and made it hidden for bonus points. You would have never solved the mystery, except that in this brief moment of desperation, as you frustratingly threw your hands in the air as a tribute to your friend's incredible pranking skills, your mouse cursor randomly lands on a constant in your code, revealing the deed as the logic-breaking macro appears before your eyes. Luck is also a factor in fixing bugs - just deal with it and consider yourself lucky you only spent four days on this.
[/quote]

As you can see, all bugs are not created equal, and they come in all shapes and sizes, and it is extremely easy to introduce bugs in your program. Any one line you add or remove can produce a bug that will affect a completely different section of your code. Sometimes, introducing one bug can remove another, and similarly, fixing one bug can actually create more bugs, and if the new bugs are similar to the old one, it may mislead you to believe that you did not actually fix anything. Even a professional developer will produce more bugs than features, and accepts this fact by fixing most of them.

As developer it is your responsibility to seek and destroy them, it is part of your job and you cannot evade this task. You don't have to fix every single bug (because that is impossible), but you want to fix the ones that are visible to the user, or at least most of those. If possible, get a play-tester (friend or whatever) to play through the game and write down each bug he encounters with a helpful description. When you get the list back, make it your goal to fix each bug on the list. When done, get a different tester to play again, and reiterate until there are no (or very few unimportant) bugs left. At this point your game is reasonably "bug-free", as any bugs left (while still bothering you as a conscientious developer) are essentially invisible to the end user and thus irrelevant to anybody other than you.

If this makes you feel better, this is not something you need to explicitly work towards. Your ability to correct bugs will naturally improve as you write more and more bugged code. I suggest you give up your RPG for now if it really is too hard to maintain it, and try some smaller games. Later on, you will be able to go back to your RPG, look over the code and think to yourself "man, this is bug-riddled!" and rebuild it from scratch with a better design. In order to gain experience, you should hopefully limit yourself to small projects. God knows I spent years of my life just writing small applets of limited functionality, but which actually worked. Each of those had dozens of bugs gradually acquired over time, and which I had to painstakingly fix, but I learnt a lot from it. So will you - get to it!

Thanks for the read, I never finished something big yet but it scares me to death finding and fixing hundreds of bugs for a big game. Something i do to make my life easier, or at least thinking i am doing that is documenting and commenting on the fly. For every method i make i write a comprehensive comment. I also put something in like this "!CONTROLS!" so if there is something wrong with the controls i can search all my methods that have something to do with controlls quickly.

What makes me scared the most is a snowball effect, When you fix one bug 2 new arize and when you fix those you have 4.

One common source of bugs is when something is incomplete. Design can generally be done depth first or breadth first. Usually, it is something in between. You want the breadth, to get a result that can be seen. It is boring to go depth first, especially if you are uncertain.

One thing that works well for me is to focus on breadth first, but mark remaining tasks with a "TODO" in the source code, to make sure they are not forgotten.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
--Brian W. Kernighan[/quote]

Debugging is just part of it. And it's quite rewarding when you do finally fix a bad bug.

Unfortunately if you've gotten to a near complete state and allowed bugs to remain in the software till this point, you will have a lot of code to go through. It's often easier to ensure you're properly testing your code during development and try to deal with the majority of problems as they arise; you could perhaps even use TDD.

OP: This. If your codebase is full of bugs so late in development, it probably means you haven't been testing your code properly, and by that I mean automated unit tests and integration tests. It's likely that if you didn't test small units early enough, your integration was a bit sketchy, and the rot has spread over time throughout your codebase.

I would start testing now. Set up a unit testing framework and get your hands a tools to analyze code coverage. Start writing tests for low-hanging fruit: math computations, for example. Work from there. Keep an eye on your coverage percentage. With every commit you make to your version control system (you are using one, right?), try to improve that percentage.

Granted, code coverage isn't everything. The tests still need to be meaningful. But it's one very effective way to keep your code healthy and gain back some confidence in the stability of your game.

Also, it sounds like you're burnt out. I can sense your frustration. As others have said, take a break. Just get away from it for while and come back to it later with a fresh perspective. It also might help to talk with a friend or colleague about it. Have you heard of rubber ducking? If not, look it up. Sometimes just talking through the problem in detail can reveal new insights. If you don't have a friend or colleague you can talk to, you could even post on the forums here and talk about the issues in detail. Or start writing a design spec for your game (or update an existing one to reflect what is currently in the code). Or write some blog posts. Whatever. The points, in order to get out of this mess you need to change your mode of thinking. I believe Einstein was quoted saying, "Problems cannot be solved by the same level of thinking that created them.”

Hope that helps. Good luck.

What makes me scared the most is a snowball effect, When you fix one bug 2 new arize and when you fix those you have 4.

But as others have said before, not all bugs are created equal. For each showstopper fixed you get two simple glitches - it is definitely a progress :-D
But seriously take a time off. It seems that at moment you only see the amount of work still ahead and it demotivates you. But if you return later after certain pause, you will first and foremost see the work already done. You will probably surprised, how much good code you have produced in addition to bugs ;-)