Ron Hiler's Plan File
Current Book: A Game of Thrones (George R.R. Martin)
Current CD: Is There Anybody Out There? (Pink Floyd)
Current Games: Asheron's Call (Microsoft), Nox (Westwood)
Current Programming Task: Code Organization, Map Icons
May 15th, 2000
Before I get started, let me say something about the frequency of the .plans. I originally said these would come about once per week, and, as you have probably noticed, I've fallen a bit off that mark.
The .plan files exist not only because you are interested (I hope!), but also as an aid for program design, as I discussed early on in one of the other talks. At any time, if I feel my time would be better spent programming, I will be doing that rather than trying to keep to a schedule for .plan files. If I ever begin to write these things because I promised a them at a certain time, they no longer are a help, but rather a hindrance to the design process. And the design process is really the important thing, isn't it? Would you rather have the game, or a web page of me babbling once a week? I thought so :)
I originally thought that about once a week would be a good amount of time to spend pondering the game code subconciously, but I think in practice it is more like every two weeks or so. I make no claims of consistancy! I reserve the right to change that as needed. That means you'll just have to check back every once in a while to see if anything new is here.
But that's not what I came here to say.
As we get close to the first Alpha release, I will be changing the "Status"
portion of the web page to a slightly different format. Right now it shows (more or less) the progress we are making toward the first release. After the release occurs, there will be no particular set plan in the order that things are done. This is because one of the big things we will be doing (in addition to adding new features) is killing bugs, many of which we will not be aware of when the release first hits. Therefore, there is simply no way for us to set up a "list" of things to do, as such.
So, how will bugs be dealt with? Ah, glad you asked....
We're going to set up a form on the webpage whereby you will be able to report a bug to us. On this form you will simply tell us what the bug is, when it happened, what you were doing at the time, whatever you think will best help us track it down. Once you hit the "submit" button, the text will pop up on the Bugs page (which will replace the Status page).
On the Bugs page, there will be a list of bug reports sent in. These reports will consist of a few items (including the text submitted by the reporter). One of the items will be for developer comments, where I will try to keep everyone informed of what is going on with that bug. There will be a few other things. One of the items will be a "Severity" setting, and this is the setting I want to talk a little about.
Bug reports will be catagorized into seven possible levels. These levels are commonly used in the programming industry, I didn't make them up. Let me paraphrase their basic descriptions.
Pending This means that the report is new, and I haven't yet had a chance to put the bug into a catagory. All bug reports will automatically recieve this catagory until I decide where they belong.
Critical This is a game stopper bug, meaning that the players cannot play the game with this bug unfixed, possibly a system crash or lockup. This could also be something which would corrupt a game file (like the Host file, for instance). A bug like this recieves top priority, and could very well prompt an immediate emergency patch release once fixed.
Grave Bugs put into this catagory are those which would cause some major game system to be unusable. For instance, if the unit design screen was not working properly, or the research queues were not accepting research tasks. These sorts of bugs effectively halt a game, although the program can still be run and the game files are intact. Again, an emergency patch might be prompted by such bugs, depending on their effect.
Normal Normal bugs are those which affect small parts of major game systems. This might make a non-critical game system unusable (for instance, if the "Player Score" screen were malfunctioning). Generally speaking, though an annoyance, such bugs can coexist with players. Either the system is not one which is critical to game play, or there is an acceptable workaround.
Wishlist Not bugs as such, these would be comments from players on ways the game could be improved (such as "it would be nice if the Player Score Screen showed a breakdown of Player Resource Income versus Time"). These kinds of "bugs" are often opinion, and might not necessarily be acted upon by the designers.
Aesthetic Things like fonts, colors, spelling errors, etc. fall into this catagory. Again, sometimes bugs of this nature are opinion, and as such might not be agreed upon by the designers or other players.
Fixed Bugs which have been repaired in the design version of the game. In general, all fixed bug reports will be removed at the release of new version. If you see a bug labelled "Fixed", it generally means the version the players have still has the live bug, but the next release will have it fixed.
Okay, that's how the bugs will be handled. At any time, you will be able to report a bug to us, and further, will be able to track what is going on with it. At least, that's the plan.
Take care...
- Ron Hiler (Lead Programmer)
|