Jump to content
XCOMUFO & Xenocide

Bug Tracking System


mindstormmaster

Recommended Posts

Work on the Bug Tracking Tool has continued. Now comes the big question, what information do we want to know for debugging purposes? for demographic purposes?

 

Here's the list so far:

Computer Info

Processor

-brand (ie Intel, AMD)

-model (ie Pentium 3, Pentium 4, Athlon...)

-speed (ie 1.6GHz...)

 

RAM

-type (DDR, SDRAM)

-amount (512MB)

 

Video Card

-brand (nVidia, ATI)

-model (GeForce2, Radeon 9700)

-Video RAM (64MB)

-Driver Version

 

Sound Card

-brand (Creative Labs, Cirrus Logic)

-model (Extigy, Crystal)

 

Operating System

-version (XP Pro, 98SE)

-service pack (SP2)

 

DxDiag.txt (Output from DxDiag.exe, provides all the details on your system)

 

Error Info

-Engine output files (Upload Engine Assertion Out.txt, Engine Report.txt)

-Error Description (User provided)

-Xenocide Version (Alpha 2.9)

 

Is there more stuff we should ask? Stuff we don't need?

Link to comment
Share on other sites

Under sound, should we get the sound drivers version, as well? Also, in the area where the user enters a description, what do you think about have a list of errors they can choose from, or they can enter their own if they don't think it fits any of the options. That way we may get a more quantified and specific list of the bugs instead of vague descriptions we have to for email-hunting to find.

 

Also, as a side note, when the next alpha is nearing release, I'm hoping to contact an assortment of people who submitted feedback to do some targeted testing (whatever this is called) before the public release, in addition to as many of us testing it ourselves, as well. Hopefully at least the web bug tracker will be operational, as it will be a good chance to test it out, as well.

Link to comment
Share on other sites

For error categories, how do these sound?

 

Fatal Error (Game won't start)

Video Error (Graphics don't look right)

Sound Error (Sounds don't work)

General Error (Please specify)

Other (Please specify)

 

Basically the idea is to be able to break up errors by category, so they should be fairly specific, but not too detailed that you only have one report per error.

Eventually we'll be able to generate nice reports that show us who's having problems and their hardware breakdowns so we can isolate problems. But for now we'll stick to just accepting them and gathering data.

 

I agree with Micah in that before Alpha 4 release we should do a base test on a variety of systems so we know what hardware is definetly supported and which has some problems. We could probably start this with the development team and branch out if necessary.

Link to comment
Share on other sites

I'm hoping to contact an assortment of people who submitted feedback to do some targeted testing (whatever this is called) before the public release

 

Hey -

 

This is commonly referred to as a "Closed Beta". In my experience, this is how the vast majority of projects conduct their beta-testing. It is organized and effective, as apposed to releasing an unfinished product to the mob and then expecting to get back any type of organized, detailed reports.

 

Personally, I think all beta-testing should be either of the Closed or Internal nature, until a finished release is ready. To do a full public beta, I can garuntee the majority of bug reports will sound like "Why did you release this if it doesnt work!! Blah Blah Blah, I have nothing constructive to say!"

 

I'm talking about beta's here, not alphas - which are a whole different ball game as everyone can easily see it is not any where near complete.

 

Gold

Link to comment
Share on other sites

IMHO we should add a question to the user like the follow:

"You encounter this problem with others videogames too?"

If a user says for example "the game sometimes slow down for some seconds then returns normal" and he says "whoops, I encounter this problem also with other titles" this means he has a CPU overheat problem, which is NOT our problem..

Otherwise, if he replies "no, I am in trouble only with your game" it's a different thing!!

 

End-users stupidity has no limit :hammer:

Link to comment
Share on other sites

Thanks GG, "closed beta" was the phrase I was looking for.

Are we looking to do a "beta" of the "alpha"? Or a private release of the alpha followed by a public release? Essentially they are the same thing, just how you name them.

 

If they're aren't anymore comments on info to gather for the tracker, i'll start making pages and database this weekend.

Link to comment
Share on other sites

Hey -

 

I wouldn't do a closed alpha release. The reason for this, is anyone who downloads an alpha understands what they are getting. Also, at the alpha very early stage of development, it would be best to get the program to anyone who wants it, and then see if it works with their hardware. This will prevent hardware issues with the beta release hopefully.

 

Also, from a PR view, we can still use the max exposure possible.

 

Gold

Link to comment
Share on other sites

For error categories, how do these sound?

 

Fatal Error (Game won't start)

Video Error (Graphics don't look right)

Sound Error (Sounds don't work)

General Error (Please specify)

Other (Please specify)

Doesn't General Error and Other mean the same? I would make a such category list:

 

Fatal Error (game crashes, exits or hangs)

Video Error (Graphics don't look right)

Sound Error (Sounds don't work)

Gameplay Error (for example, cannot open a door or cannot pick up an item)

Other Error (everything else, more details are needed).

 

Regarding output files:

 

The names and their number could change. I will change the code so they will all be written in some separate directory, so we would ask the user to zip up to us the whole directory without specifying file names.

 

Regarding open/closed beta/alpha:

 

I would not even called it a beta until we have at least rudimentary game play implemented. As for now, I would keep putting releases for public download (of course after initial development unit testing), so we would get as much as possible feedback. As with current alpha everyone knows what he is getting into. However, when more features will be implemented, we should do this 'closed beta' phase before releasing it to public. But we are way too far from that yet.

Edited by mamutas
Link to comment
Share on other sites

Sorry, sorry, accidentally used the wrong word. Goodness :wacko:

 

I realize that people downloading an alpha should know what they are getting into. What I had in mind was to pass the alpha to perhaps 10 people, even just to project members here, to make sure there are not any huge artifacts that will be sort of an embarrassment to the project. Like, for instance, what if it runs for RK and Mamutas, but simply won't start at all on most everyone else's machines? I think if 1000 people download it and it only works for 200 of them, then that will not cause nearly as much wide positive publicity as it could if the alpha worked for 900 of the 1000. It is the same simple process that has been done prior to precious alpha releases. RK uploaded it, I made it available for download to half a dozen people, and they all tried it to make sure it ran. Then we made made the announcements and made it publicly available a day later. I was not suggesting a full scale closed alpha test....

Link to comment
Share on other sites

Regarding output files:

 

The names and their number could change. I will change the code so they will all be written in some separate directory, so we would ask the user to zip up to us the whole directory without specifying file names.

I'm leaning more towards just having them upload the actual text files. These can be included in a webpage and made available to the dev team right with the rest of the report. Having to do something server-side to unzip things is a bit much. Maybe we could just have the engine output them to one file with the appropriate section breaks. Or have each line prefixed by a category

ASSERTION blah blah
DEBUG stuff
INFO more stuff
FATAL program crashed because of this...

 

As for the beta/alpha, I agree with Micah that we should do some minimal QA before doing a public release. This doesn't mean that it has to be guaranteed on every system, but let's just avoid a big embarassment. There's an audience watching now, don't blow it.

Link to comment
Share on other sites

Sorry, sorry, accidentally used the wrong word. Goodness  :wacko:

 

I realize that people downloading an alpha should know what they are getting into. What I had in mind was to pass the alpha to perhaps 10 people, even just to project members here, to make sure there are not any huge artifacts that will be sort of an embarrassment to the project. Like, for instance, what if it runs for RK and Mamutas, but simply won't start at all on most everyone else's machines? I think if 1000 people download it and it only works for 200 of them, then that will not cause nearly as much wide positive publicity as it could if the alpha worked for 900 of the 1000. It is the same simple process that has been done prior to precious alpha releases. RK uploaded it, I made it available for download to half a dozen people, and they all tried it to make sure it ran. Then we made made the announcements and made it publicly available a day later. I was not suggesting a full scale closed alpha test....

That what I meant. I apologize if I was not clear. Please, excuse my poor English. :Blush:

 

Regarding the output files.

I was just thinking about manual zip/unzip. Nevertheles, it is more clean to provide the log files in a separate directory. There would be just few files (2-3 maybe). This system is not finalized yet, so changes could be possible there at any time. But be sure, that you will be informed.

 

Another thing I want to mention. For any of those visual erros it would be nice to have a screenshot. One picture is worth thousands words, you know.

Edited by mamutas
Link to comment
Share on other sites

Hey -

 

We could just put in the FAQ and Readme, that PrintScreen and then copy into Paint does the trick. Or, if we're feeling CRAZY, someone could just write a small app that takes screenshots and automatically converts them to .jpg and puts them in a screenshot folder.

 

Gold

Link to comment
Share on other sites

×
×
  • Create New...