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!

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.