STAR FLEET BATTLES |
INPUT GUIDE- CL27 |
Players seem to have liked Modules E1 and E2 and we'd be interested in printing E3 and E4. We don't have any of these galaxy designs on hand at this time, but wouldn't mind seeing some of them. We don't intend to design E-modules ourselves; we have other things on our list of projects.
What made E1 and E2 popular was that they were packs of new races, new ships, and new technology, so it would be logical to presume that any other E-modules would be of similar format. Such things as "packs of new Fed and Klingon ships" and "packs of new scenarios" might be published but not as E-modules.
A general note on submissions is that lots of players send us memos raving about the cool module they are going to do, but very few of them finish or submit their projects. So don't take it personally if we don't spend a lot of time talking with you about your module because we have spent a lot of time with other people who dropped the project halfway through, wasting a lot of our time. When you have a reasonably complete package of materials, close enough that we could finish it if you disappeared, we'll spend more time talking with you about the details.
One aspect of such submissions (and many others) is pre-submission playtesting. You are welcome to do this and should do it. Having a buddy "read it over" is not enough; have total strangers TEST IT IN COMBAT. Emailing playtest packs to selected individuals is the normal procedure. (Putting it on a web site means we would probably never publish it as everybody interested already got a copy for free.) It is important that before ADB Inc. spends time on your project that you have already proven that it works and is reasonably complete, and only playtesting can do that. Don't be surprised if more than half of those who offer to playtest never report, or send incomplete or superficial and fairly useless reports. That's pretty much what happens when we send things out. Do not send things to members of the SFB staff as we need them working on more urgent projects that we assign from here. Be careful of the mental trap in which designers are so proud of their creation that they ignore playtesters who say it doesn't work. Remember the old Jewish saying:
If three men say you are a jackass, go buy a saddle.
There is a chicken-and-egg problem in projects of all types, but with bigger projects (such as a package of 3-5 races) this problem gets astronomical. The problem can be defined like this. If you don't have Steve Petrick read and comment on your package before you do your own playtesting, then you may very well be wasting your playtesters' time on something that will be rejected automatically when it arrives. But if Steve Petrick spends a lot of his very limited and therefore valuable time reviewing and fixing your project then that time will be wasted if you never finish the project or if your playtesters conclusively prove that it is never ever going to work. And don't take it personally, but over the last 15 years, more than 2/3 of the things Petrick has done preliminary work on never actually came back as finished pieces.
The best compromise we can find is for Petrick to do a very superficial review just to see if you have hit upon some landmine (e.g., you do a whole package of ships from Babylon 5 and they're not within our license and we can never publish them), but not a full rules review. Steve Cole has to ride herd on Steve Petrick's time to make sure he doesn't spend entire weeks getting somebody's E-module ready for outside playtests and let a Captain's Log be late.
We are often asked "what are you looking for?" and we return this question with a blank stare. We don't know it until we see it. If we had a cool idea, we'd do it ourselves, not tell the next guy who walks in the door to do it for us. (Although, sometimes, rarely, SVC does just that on the BBS.) We want to print projects that fit within the universe, make players say "I gotta have that!", and don't cause us years of pain and anguish dealing with logical or background inconsistencies.
A formal procedure is impossible to define, but a good one might be this:
Copyright © 1999-2004 Amarillo Design Bureau, All Rights Reserved | Updated 19 November 2004 |