Difference between revisions of "The Need to Beta-Test FreeSpace Missions"

From FreeSpace Wiki
Jump to: navigation, search
m
(the header is unnecessary, given it's the article's title - (this is probably the first of a series of related edits))
 
Line 1: Line 1:
==The Need to Beta-Test FreeSpace Missions==
 
 
by: Old Staff (Zarathud) - November 02, 1998 for Freespace Watch
 
by: Old Staff (Zarathud) - November 02, 1998 for Freespace Watch
  

Latest revision as of 11:34, 24 January 2013

by: Old Staff (Zarathud) - November 02, 1998 for Freespace Watch

Perhaps a favorite gaming topic is to complain about quality, often by denouncing at long lengths the game designers for releasing a "shoddy beta product and using the unsuspecting public as beta testers for a product rushed to meet an arbitrary publishing deadline." You can hear these complaints made in almost any public forum, no matter how good or polished the game. The usual release of patches only seems to confirm these gripes. Indeed, the Descent: FreeSpace Forum contains many of these comments made by gamers about FreeSpace. Some of these complaints are valid, some might be valid, others are invalid.

If gamers complain about quality, therefore, it would only seem right that these same gamers would attempt to release only quality products when they were the designers. FRED, the FreeSpace Mission editor, allows ordinary gamers to use many of the same tools that Volition used to create the Great War campaign. Even though independent gamers are often not professionals and unpaid, these are dedicated people and it is suprising that the quality and uniqueness of user-created missions often falls far below that of game's developers. This statement does not ignore the missions demonstrating talent or meeting (if not exceeding) the quality of missions available from Volition. However, these missions are relatively few despite our continuous efforts to find the hidden "gems" and announce them in the FreeSpace Review to the community.

I am continually amazed at the low quality of many FreeSpace missions available on the Internet and through Xanadu's FreeSpace Mission Archive. Too many of these missions have clearly not been beta-tested by anyone, including the mission designer. Unfortunately, missions too often have obvious flaws that will remove the fun and potential out of an otherwise promising design. There are more than a few missions that have little design at all, and only appear to work due to the wonderful default AI programming of Volition's designers. It amazes me that someone would consider a mission to be "done" after doing little more than merely throwing a bunch of ships into FRED and saving the file. That might be an exaggeration, perhaps, for many cases, but too often the wonderful and unique options of FRED lie untapped and unused.

For this reason, you might have noticed that many missions recently haven't been receiving high reviews. Therefore, I feel it necessary to mention some of the more common design mistakes I have noticed during my mission reviews:


  • Failure to place ships on different X, Y, and Z axes. Many seem to be stuck in a 2D model, even though FRED provides for 3 dimensions.
  • Failure to place ships at a distance from each other. Few things frustrate this pilot more than starting a mission to an "incoming missile" warning. Initial hostile ships should never be placed less than 1500 meters away from Alpha 1's starting point.
  • Failure to name ships other than the default. This ruins the immersion of the mission, missing out on an enjoyable method to personalize your mission. What fun is there in chasing around "PVF Seth 12" when you could be dishing out the hurt to the "PVF Punisher 1"?
  • Failure to provide ships standard AI Orders. Tell the hostiles to do something other than wander around shooting aimlessly.
  • Failure to use Events at all. The Events and sexp coding provides the power and flexibility to FRED that makes FreeSpace revolutionary. Not taking advantage of the game's distinguishing feature is shameful.
  • Failure of critical Events. Often mission-critical events will not work, resulting in a show-stopping bug that ruins the intended effect or prevents the mission from completing.
  • Failure to provide an adequate and reasonable Team Loadout. Nothing is more frustrating than running out of secondaries to arm your ship. There should be a good selection of weapons (unless the story or timeline requires otherwise), but not an infinite or non-existent supply.
  • Battle of Endor Syndrome. Call this my personal crusade against "grand battles," it is a subject serious enough to warrant its own editorial due to continuous attempts by mission designers to stuff as many ships (especially capital ships) or fleets into a mission as possible.
  • Overuse of Subspace. A issue raised by Ouroboros in his editorial, Subspace holds a particular niche in the FreeSpace storyline and should be used only when the storyline requires -- not because it's "neat."
  • Failure to balance mission difficulty. Many missions are so difficult that I doubt anyone (even the top-ranked PXO pilots) could finish on medium difficulty. Other missions are so easy that I could walk away, have a few beers, and return to find the mission was a success.


As mission reviewers for the FreeSpace Review, Ouroboros and I have taken the responsibility of playing as many levels as possible and providing reviews of those missions to the community. We are also committed to providing feedback to the mission designers (both positive and negative), so that they may improve the quality of their missions. However, neither of us volunteered to be beta testers for those who cannot play their own missions. We don't enjoy writing bad reviews, and the mission designers probably don't enjoy receiving them either.

At times, it becomes frustrating to even write those reviews because the time we spend describing all of the flaws may be more time than the author spent designing the mission! A few missions (such as first.fsm, bomber.fsm and humans.fsm) should be infamous for this very reason. Perhaps their value can be as lessons of what not to do in mission design.

Other times, we find ourselves wondering how some show-stopping bugs ever made it past the author. For these missions, we can only conclude that the designer failed to even play the mission themselves before submitting the design. Missions like this (including ShivanA.fsm and Andromeda.fsm) just can't be explained by any other reason, as the bugs are just too obvious. These missions provide valuable lessons on what to look for in order to avoid repeating the same mistakes.

The bottom line for any mission designer should come down to this:


1. Take the time to polish your missions before submitting them to the public.
2. Don't rush the design process, take a few days to think about the mission and to get help if necessary.
3. Beta-test and beta-test some more. Then beta-test it again!


Some of the upcoming campaigns have several beta-testers, often FreeSpace designers of note, to verify that the ideas work in the mission and that bugs do not sneak through. The best mission designers take the time, often weeks, to perfect their missions. As a result, these designers have released only a few missions and are willing to revise even well-rated missions. This release "when it's done" approach is what we as gamers demand from game developers. It only makes sense that we live up to our own demands.

After you have a semi-finished version of a mission, enlist (draft, beg, borrow, or con) someone else to test it for you. Bugs will often slip through only because the author knows too much about the design to look for alternate approaches that could trigger problems. There are several places with other FreeSpace designers willing to help out, such as the MissionSwap program for members of the SwapMeet. If you only register your willingness to exchange missions for beta-testing, you'll join many other authors willing to help provide feedback. If you're interested in this program, contact Paul Regenhardt at the SwapMeet.

Even if you can't find someone else to help test your mission, there is no excuse to not beta-test yourself. Authors can use the various checklists created by excellent designers in the FreeSpace community, such as the Unofficial FRED Checklist from RAZOR of the CyberRaptors and the Mission Design Checklist from Nathan "Dynamo" Hoying. Also useful is the guide for How to Critique a Mission at the SwapMeet. If you find yourself frustrated with continuous replaying of your mission, set it aside (along with some sort of developer's notes) and work on another design, or just enjoy playing the game. After a breather, you can often find that "neat" ideas just aren't working out. This fresh perspective can help greatly improve your mission designs.

Good missions can only be created through constant testing of how the ideas and design work when playing the mission. Excellent missions are created through polishing those elements and paying attention to all of the details that can help make your mission Volition-quality. It seems difficult to believe that any mission designer aspires to a lower standard. The FreeSpace community is in desperate need of good, well-designed and polished missions that tell a story.

Use the FreeSpace Design Resources to help in your design efforts and always remember to beta-test before submitting your mission! Missions that we have to beta-test at the FreeSpace Review are almost guaranteed poor ratings.

Author's Note: This editorial does not ignore the many quality missions out there or the efforts of mission designers. I, also, am a mission designer and know the difficulties of working to create a mission with minimal bugs.