Don't want to write GUI to debug units that stand around and do nothing.
What do? Abandon?
Will I never finish a project?
Edited by Hodgman, 06 September 2012 - 11:20 PM.
Jump to content
Posted 06 September 2012 - 11:05 PM
Edited by jbadams, 06 September 2012 - 11:07 PM.
- Jason Astle-Adams.
Posted 07 September 2012 - 12:38 AM
Edited by polyfrag, 07 September 2012 - 01:11 AM.
Posted 07 September 2012 - 01:46 AM
Posted 07 September 2012 - 01:48 AM
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.
Maybe Counter-Strike/Half-Life/Quake, StarCraft, and Rappelz are historical accidents where the developers got it right the first time.
- Jason Astle-Adams.
Posted 07 September 2012 - 02:36 AM
Edited by kd7tck, 07 September 2012 - 05:07 AM.
Posted 07 September 2012 - 02:41 AM
Posted 07 September 2012 - 03:10 AM
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.
Posted 07 September 2012 - 03:14 AM
Posted 07 September 2012 - 04:20 AM
Posted 07 September 2012 - 05:31 AM
Posted 07 September 2012 - 07:25 AM
Posted 07 September 2012 - 07:39 AM
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.
Posted 07 September 2012 - 08:35 AM
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):
Do professional games go through this or do the pros never make such mistakes? Will I ever achieved pro-dom?
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.
Edited by Bacterius, 07 September 2012 - 08:36 AM.
The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.
- Pessimal Algorithms and Simplexity Analysis
Posted 08 September 2012 - 01:55 PM
Current Project: TechnoFlux read all about it on my
Posted 08 September 2012 - 02:22 PM
Posted 11 September 2012 - 02:26 PM
"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
Posted 12 September 2012 - 08:21 AM
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.
Posted 12 September 2012 - 12:44 PM
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
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.