RTS game full of bugs.
Don't want to write GUI to debug units that stand around and do nothing.
What do? Abandon?
Will I never finish a project?
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?
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?
Author
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.
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.
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.
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:
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.
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:
- You'll learn different techniques you can apply to minimise bugs and make it easier to find and fix them when they occur.
- 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.
- 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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
