|
Strana 1 z 2 Some "behind the scenes information" about the bug fixing process
Bug fixing is an important part of game development. It's a part which is not very attractive to do, because it's most often not very creative, but it is necessary - without it, no product can be released.
This blog entry aims to tell you a little about how the bug fixing process is organized within Bohemia Interactive. Some of the practices described here are a common industry practice, some may be specific to how our company is doing things.
There are several different phases in a product's life, and in each of them bug fixing is handled in a slightly different way. One flexible formalization you can use at bug selection is to view it as an optimization problem. When a bug is fixed, you get some bonus from this fix (or you can view it on the other hand, that an unfixed bug causes a penalty). Fixing a bug costs you something - time, money, work ... and sometimes the cost may be not obvious: sometimes a fix which is simple on a programmers side has a significant gameplay impact and needs to be tested extensively.
Fixing a Bug
First let us take a look at fixing an individual bug. This is usually done in several steps
- Read the bug report
- Read it again to understand it :)
- Finding what is causing the bug
- Fixing the bug
- Deploying the fixed version
Good bug reports are of critical importance here. Good bug reports contain repro steps, so that the person fixing the issue can see it with his own eyes (or debugger, or whatever sense he can use). The best bug reports contain short repro steps - if the repro steps are complicated and hard to follow, the total time to fix the bug is increased.
Create - Building the Game
Product being developed from design to beta, new features implemented.
Bug sources:
- People in the team working on the game
- Publisher feedback
Bug penalties:
- Workflow impact - does the bug prevent someone else from doing his work?
Bug fixing cost:
- Time to fix
- Time to test not so important, as at this stage the big game testing is still ahead of us anyway
Planned bug fixing capacity:
- Each person in a team should dedicate one day per week to bug fixing
Polish - Bug Fixing Phase
Between Beta and Gold there are generally no new features implemented, only bugs are fixed and sometimes existing features refined.
Bug sources:
- Publisher requirements - the publisher can reject the product because of
some issues considered "critical" by them. Such issues need to be fixed,
or in some cases we need to communicate with the publisher and perhaps convince them that the issue is not so important.
- Internal testing - which bugs do we view as major blocks for the product to be released.
- Closed external beta.
Bug fixing cost:
- Time to fix - this is the obvious cost: someone needs to fix the issue, be it a programmer, artist, designer.
- Time to test dependent content: AI bugs are infamous for this. Some AI fixes may drastically change the playability of the game. When an AI bug is identified close to the release date, but is not critical enough to justify delaying the release, it may happen that its fixing is postponed into a patch.
Bug penalties:
- Risk of bad product reputation, which may also result in bad reviews and lesser sales
- Workflow impact
Planned bug fixing capacity:
- Bug fixing is the primary activity for everyone in the team
Support - After Release Maintenance
 Bugs are fixed which we were either unable to fix before release, or we did not know about them before release.
Bug sources:
- Customer feedback - this is you, complaining about bugs using various channels (technical support,community bug tracker, forum, etc etc).
Bug penalties:
- Lost sales because of bad reputation.
Bug fixing cost:
- Time to test dependent content - this is very problematic, as at this stage there is usually not any regular QA process funded by the publisher any more.
- Time to fix. Not obvious here may be the fact that another product is already in development, therefore fixing bugs from older products may cause schedule issues for the new product, especially when the fix is not related to it.
- An interesting situation here is the fixing cost may be significantly reduced when a fix was developed and tested in a product which is already in development. An example of this is that ArmA patches sometimes contain fixes which were implemented for ArmA 2. Sometimes the issues fixed this way are not very important, but as the cost of transferring the fix is sometimes relatively low, this fix is included for ArmA as well.
Planned bug fixing capacity:
- If there are many known bugs at the gold date, there is still usually a substantial amount of time reserved to fixing them so that customer impact can be minimized or reduced. Later on, there is no permanently reserved capacity for this at all, what is done is that sometimes there are short periods of time dedicated to bug fixing either by individuals, or by small teams.
Čtenáři napsali 11 komentářů. No.11 Shirt
Today I've proudly received ArmA "If you see the BUG..." T-shirt :D No.10 Nothing.
CWR was created by community members, the input of BIS was negligible.
Can't understand the point you're trying to make about the Xbox.
Your opinions have nothing to do with this specific blog entry, you're using the comments section to air some unrelated grievances you have IMO, that's what the forums are for, apparently...... No.9 evrything
Maybe in your absence you have overlooked the process of arma`s release ?
CWR was a waste of resources and time that should have been used on a BTS . what the hell is it coming to when all that time and energy is spent on something that was released on xbox , when it could have been used to invest in a propper BTS and not rely on a community one that has now dissapeared . just my opinion if i cant voice that then whats a blog ,comments section for ? No.8 Stay on track...
What does CWR have to do with a killing bugs in ArmA2 blog entry? Please stay on track. No.7 correction
just wanted to clarify that i am not sying cwr team has no talent , just that the project should never have taken place ,that pipeline could have been put to better use for better and more useful things. i meant sack the cwr project . No.6 You talk a nice Job
You know i can apply all this to the BIS that built ofp and see how you tried your best and succeeded even with a product that was still flawed in many ways.But how you can say that you have applied this to arma before release and not be slightly embarrased at version 1.0 is astounding. Sack your beta testers and your community elite (cwr team too) and make real pipelines for real fans with real talent and do what you have suggested above or ARMA2 is doomed from the outset and believe me i want it to succeed.
No.5 Re: Head Banger
Yes OFP2 might be nice, but i'm worried about community support. Don't know if there will be a mission editor or even an SDK for OFP2...
Anyway, if ArmA2 as much improved AI and great campaign it should do fine:)
Don't know if using Armed Assault name is good a idea though :| since most people will bring back bad memories from ArmA No.4 Head Banger
ha, I notice all of a sudden they are worried about a bad reputation... Alittle late for that I think. I am curious to see how many people actually stopped playing ArmA... I suspect the sale of ArmA 2 to be down significally. I know alot of us are waiting on the OFP2. No.3 Nice
Oh nice, BIS should have a little online shop, Shirts/Key Rings etc.. that would be an idea. But yeah i could imagine myself one day wandering around the unknown outside BIS HQ with one of those T-Shirts on :D Right time to get this bug reporting know on the BIS forums. No.2 If you see the bug it's already too late.......
Glad you like the picture, we actually had T-shirts made with that logo, I have one in my cupboard ;) We sent one to each of the ArmA beta testers as well :)
|
