This thing is soooo long, it needs a...
Table of Contents
0. IF YOU ONLY READ ONE THING!
1. Introduction
2. The Latest
3. Anatomy of an Excellent Bug Report
4. For Aspiring Architects
5. "
Safe"
Upgrade Process
0. IF YOU ONLY READ ONE THING!
At time of writing, DROD is chock-full of bugs. As a result, several testers have lost their DROD data along the way, and it has been discouraging for everyone. Ironically, the new features in DROD encourage you to create data, but be warned: holds, saved games, demos, and player settings are vulnerable to data loss.
Also, as long as you don't uninstall the Caravel DROD 1.5 (the previously-released stable version of DROD) you will be able to reimport your old saved games, demos, and player settings that were created in DROD 1.5 if things go wrong.
1. Introduction
Anybody want to help beat up on DROD? We are beginning beta-testing for what I call, "
Deadly Rooms of Death: Architect's Edition"
. This is a big release for us, since it has the much-clamored-for level editor. (Wait til you see it!) A lot of complexity has been introduced by the features that allow importing, exporting, and collaboration between players, so I predict there will be many problems that need to be discovered through some intensive testing.
For the last release of DROD, we had what is called a "
closed beta"
. This means we were a bit selective about including people in testing. (Or maybe the testers were selective about including us in their busy lives.) But anyhow, after we knew who was in, we locked the door to our clubhouse, and carried out communication through private e-mails. (Yeah, like everbody else desperately wanted to know what we were talking about.) Typically, the advantage of a closed beta is an improved quality of communication. Or in other words, we spend less time figuring out what people are trying to say. It turns out that the key person who ran our last closed beta, Brad Wall, is busy with lifey stuff. (That bastard!) With Brad off doing other things, it made me reconsider how to handle the beta.
I think we will instead try an open beta. An "
open beta"
means that anybody is welcome to participate. What's good about an open beta? More people means more bug reports, and supposedly we could learn what needs to be fixed more quickly. What's bad about it? The quality of communication tends to go down, and we have to spend more time figuring out what people are saying. In theory, anyhow. We'll see how it goes.
I enjoyed the comradery we had on the closed beta for the last release, and don't want to lose that tight teamwork. The people we worked with were fantastic! I'm glad that many of them are helping out again on Architect's Edition. (Welcome back Clayton, Martin, Peter, Russ, Stuart, and Mark!) I don't want this to be a lot of drudgery--we will have fun! I've got future surprises in store for people who help clean up this release.
Man, I sure like the sound of my own typing.
If you want to participate, here's what you do:
1. Read "
Anatomy of an Excellent Bug Report"
section to get an idea of what we need from you. You might be scared away, but I hope not.
2. Send an e-mail to bugs@drod.net. Include:
- your full name (so we can put it in the credits)
- your alias on the DROD.net forums
- the e-mail address we should use if we need to reach you
- your configuration including operating system, processor, and memory.
3. Read "
The Latest"
for instructions on downloading DROD. This section will be updated as we come out with new builds. (A "
build"
is a version of DROD you can install on your computer. In our case, newer builds have more bugs fixed than earlier builds.)
4. Post your bug reports to this board.
5. Check back on the board to see if me, Mike, or one of our testing coordinators has questions about the bug. When we understand the bug correctly and plan to fix it, you'll see a reply at the end of the post that says "
Entered in database."
-Erik
2. The Latest
The latest version of DROD is shown in the subject of this message. You can download it from:
http://sourceforge.net/project/showfiles.php?group_id=10939
This is a beta version of DROD, so it's got bugs in it. If you just want to play a solid game of DROD, I recommend the previously-released stable version. It can also be found at the above URL as "
Caravel DROD 1.5 Setup"
. When we get through beta testing, you'll have full-blown DROD ecstacy with nothing to complain about.
Please, don't distribute any beta version of DROD. That's like peeing in a reservoir.
3. Anatomy of an Excellent Bug Report
Here are some things to keep in mind when you are reporting bugs:
1. Try to report on bugs in the latest build. If you report on bugs in earlier builds than the latest, there's a good chance you'll come up with problems that have already been fixed. Even if your problem has never been reported before, we will want to know if it is present in the latest build.
2. Your subject line should be a summary of the problem. It's hard to browse through the board messages when they all say things like "
A bug"
, "
testing"
, "
Another bug"
, "
Something else I found"
.
3. Each bug should get a separate topic on the board. Don't reply to a message about one bug, with a message describing a new bug that you found. Just put your new bug in a new topic.
4. The bug report itself should contain not just a description of what went wrong, but what needs to be done to recreate the same problem on another computer. If we can't reproduce your bug, we can't fix it.
BAD: "
DROD crashed."
BETTER: "
DROD crashed on the title screen."
GOOD: "
DROD sometimes crashes when you click on top lefthand corner of the title screen."
EXCELLENT: "
Wait on the title screen until the screen begins fading to black as it changes to the demo screen. Click on the top lefthand corner. BAM! It crashes for me every time."
What We are Looking for
Basically, I want to know about anything in DROD that could use improvement. To give you an idea, here are some of the problems I'd like you to cover in your bug reports.
- You are trying to do something and the program won't let you. Maybe an error message comes up or the program exits unexpectedly.
- You expect something to happen, but the program does something else which is incorrect or confusing.
- You have to do something unusual or inconvenient to get the program to do what you want, a.k.a. a "
workaround"
. The interface should be easy for you to use.
- Something looks ugly. Something sounds bad. Although, not strictly a bug, a cosmetic concern is good to hear.
- Performance is slow on your computer. Some areas of the program might be slower than others.
Although there is often a fine line between the two, you should distinguish between bugs and feature requests. A bug is a problem for us to fix, i.e. "
The monster attacks me when I'm invisible"
. A feature request is something new you want to put into DROD, i.e. "
I would like a monster that will attack
me when I'm invisible."
Feature requests are welcome too, but don't expect a lot of attention to be paid to them during beta-testing. We have set up a public forum where you can discuss them with the Caravel team and DROD players at large.
http://www.drod.net/forum/viewboard.php?BoardID=3
4. For Aspiring Architects
If you'd like to make some "
real"
holds during the beta period that can be released to the world later, that's great! Creating real rooms is the best way to test all the new editing functionality, plus the DROD people will get your new hold to play with. However, be warned that the editor is likely to have bugs in it that will put your data at risk. If you want to make real holds and avoid losing your work along the way, here is what I recommend:
1. Wait for at least a week of testing and bug-fixing to go by before beginning any ambitious project. If you see open bugs related to importing and exporting holds, then you should wait until these are fixed. If there are any really horrible bugs that would require us changing the data in a way that would make your work unusable, it would likely come up early. This is why I say "
wait a week"
.
2. Install DROD twice to two different directories--one will be your "
primary"
installation and the other will be your "
backup"
installation.
3. Edit your hold in the primary installation. When you've finished a chunk of work (maybe every few hours or at the end of a session), export your hold to a file. Name the file with the date, or use some other naming convention that allows you to keep more than one export file. You don't want to overwrite your old export files because you may need them if problems come up to recover your data or aid in troubleshooting.
4. Import the file from step 3 into your backup installation.
5. In the backup installation, play through the rooms you just added a little bit to see if they imported correctly. Things to check:
a. All the rooms you recently added are present.
b. There aren't "
extra"
rooms present in the level.
c. The rooms look the same.
d. Orbs affect doors in the same way.
e. Scrolls display text correctly.
f. Stairs take you to the correct level.
There are other things that could be checked, but I think these are the important ones. As opposed to manually playing through the rooms in the backup installation, you may find it easier to export victory demos from the primary installation, import them into the backup installation, and play back the demos to make sure everything works.
5. "Safe" Upgrade Process
Well, I don't want you to think anything in beta-testing is safe. It's crazy out there, man--you could lose everything! But presumably you would want to try to preserve your data from one build to the next. This is what you should do to keep your saved games, demos, holds, and player settings reasonably protected from the rough-and-tumble build upgrades.
First, check the "
Changes for build X"
post for instructions on the upgrade. I will say whether or not the upgrade will overwrite your data files. If the upgrade doesn't overwrite your data, just run it and you should still have your data on the other side. Note that the data-overwrite is necessary for some builds because we will have made changes to the data files that need to be present.
If the upgrade installation does overwrite your data, here is how to preserve it:
1. Run the previous build of DROD, or at least the latest build that has data in it that you'd like to have in the new installation.
2. Export your player and holds. Demos too, if you want them, though that is more work because you have to go to each room that contains a demo that you want to export. I advise appending the build# to the name of the file. This will be helpful if you run into errors later.
3. You can either run the upgrade installation into the directory of the latest build (see "
Changes for build x"
post for info on what builds can be upgraded) or, if you want to be slightly safer, run the full installation into a new directory. The latter choice can be useful for troubleshooting errors that might come up during import/export.
4. Run the just-installed build of DROD.
5. Import your players, holds, and demos.
6. If you run into an error in the above process, please report it right away. Data loss bugs have the highest priority, since they make testing unpleasant and difficult.
[Edited by ErikH2000 on 08-13-2003 at 12:48 AM GMT: Update subject for build 36.]
____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals |
twitch stream |
youtube archive (NSFW)
(Peter King)
