• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
polyfrag

Stuck in late development

21 posts in this topic

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
0

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
0

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.
2

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].
2

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.
1

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.
0

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 :)
0

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.
0

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.
0

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
1

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.
0

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.
0

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.
0

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.
0

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 ;-)
0

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.
0

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]
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0