Sign in to follow this  

Stuck in late development

This topic is 1952 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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? Edited by Hodgman

Share this post


Link to post
Share on other sites
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. Edited by polyfrag

Share this post


Link to post
Share on other sites
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. [b]Every game[/b] 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.

Share this post


Link to post
Share on other sites
Skilled professional developers are able to avoid [i]some[/i] 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 [i]plenty[/i] 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 [i]weren't[/i] lots of bugs.
It [i]is[/i] 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.

[quote name='polyfrag' timestamp='1346999925' post='4977506']
Maybe Counter-Strike/Half-Life/Quake, StarCraft, and Rappelz are historical accidents where the developers got it right the first time.
[/quote]
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:[list=1]
[*]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.
[/list]

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 [i]finished[/i] 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.

Share this post


Link to post
Share on other sites
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. Edited by kd7tck

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='polyfrag' timestamp='1346999925' post='4977506']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.[/quote]

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 [url="http://www.youtube.com/watch?v=wgb8UxBb7og#t=8m41s"]here[/url].

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='polyfrag' timestamp='1346999925' post='4977506']
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. [/quote]

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.

Share this post


Link to post
Share on other sites
[quote]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):

[quote]
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 [i]line by line[/i], 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! Edited by Bacterius

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote]"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.

Share this post


Link to post
Share on other sites
[quote name='jbadams' timestamp='1346994311' post='4977493']
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.
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='menyo' timestamp='1347134105' post='4978080']
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.
[/quote]
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 ;-)

Share this post


Link to post
Share on other sites
What most of the people have said: every programmer makes mistakes (even Carmack), good programmers make fewer mistakes and fix them sooner. If you've been avoiding bug fixing it makes your job harder. If an area of code has many bugs they may interact in weird and wonderful manners than make diagnosis difficult. But still possible. Get to a better mindset, then get to it. You'd regret abandoning your hard work.

Share this post


Link to post
Share on other sites
To fix a bug ridden codebase:
- Set compiler warnings to the max, set compiler to treat every warning as error, and fix (or silence) the errors.
- Add a lot of asserts, specially for function preconditions.
- Make sure you read return values everywhere, and check them for errors.
- Rename poorly named classes and functions to be more clear.
- Use const-correctness.
- Fail fast

If using visual studio:
- Set debugger to break whenever exception is thrown.

Is you codebase riddled with null-checks? Optional codepaths if/when something fails?

[url="http://www.martinfowler.com/ieeeSoftware/failFast.pdf"]http://www.martinfow...re/failFast.pdf[/url]
[quote]
Some people recommend making your software robust by working around problems automatically. This results in the software "failing slowly." The program continues working right after an error but fails in strange ways later on. A system that fails fast does exactly the opposite: when a problem occurs, it fails immediately and visibly. Failing fast is a nonintuitive technique: "failing immediately and visibly" sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production.
[/quote]

Share this post


Link to post
Share on other sites
Sign in to follow this