Difference between revisions of "Testing"

From FreeSpace Wiki
Jump to: navigation, search
m (Advice for testing moved to Testing: More wiki-like title)
(New section)
Line 10: Line 10:
 
*Never release a mission without testing its last version twice or three times. A seemingly minor change like changing wing delays can result in unexpected difficulties.
 
*Never release a mission without testing its last version twice or three times. A seemingly minor change like changing wing delays can result in unexpected difficulties.
 
*Never be the sole tester, give it out to others, preferably from any skill level, to test for difficulty, pacing, etc. What works for you, might not work for others.
 
*Never be the sole tester, give it out to others, preferably from any skill level, to test for difficulty, pacing, etc. What works for you, might not work for others.
 +
 +
==Testing someone else's mission==
 +
===The testing process===
 +
Remember that by the time you receive the mission file, it's supposed to be more or less complete. For the first test run, play as if you were any casual player who is playing a user-made mission for fun. Don't specifically look for mistakes. If you find some mistakes even so, those mistakes must be ones that any player will come across. These mistakes will likely come up every time you play the mission, so they are to be reported and fixed as soon as possible. You'll now have a clue about the mission. After a few more casual plays, dig yourself deep into some real testing.
 +
 +
Now start testing a mission as if it were your own, except you can afford more test runs because you don't have to fix the mistakes. Use notes to keep track of your findings. Pay attention to details and test every possible mission outcome. You may win the mission totally by blowing up all the three hostile cruisers while keeping your corvette alive, but try to lose the corvette once and see what the debriefing will say.
 +
 +
Lastly, open the mission in FRED and look around. You may discover some unused Events, a forever-invalid mission objective. You'll be point out some mistakes that would otherwise require a dozen re-runs to be found.
 +
 +
===Submitting feedback===
 +
Submitting feedback to the mission designer is the last step in your testing of someone else's mission. Whatever way of information echange you choose (email, forum post, instant messaging) remember to be objective. Don't use attributives like "bad" or "amateurish," even if the mission designer made a very blatant mistake. Even experienced mission designers tend to forget about putting mission critical craft on the Escort List. A factual "There is no Escort List." sentence will do it. If the mission designer is a beginner, explain why the Escort List is needed. This must indeed be an explanation.
 +
 +
Don't report all your findings. A disproportionately long list of mistakes is discouraging. Concentrate on the really important mistakes first and put forward some propositions on how to fix them.
 +
 +
While it has previously been said to be as objective as possible, some praise—which is inherently subjective—helps maintain a steady level of encouragement. Be specific about your compliments, also. A very general, "The mission was excellent, but I have a long list of mistakes here" sentence sounds dishonest. A dishonest praise is no praise. It is okay to praise the mission for its intensity and point out some minor briefing icon-related mistakes.
  
 
==Speeding up your testing==
 
==Speeding up your testing==

Revision as of 15:23, 28 December 2008

Keywords: patience, time, circumspection, purposefulness

General hints

  • Never be afraid of testing. Always be straightforward and logical: If you think that part is buggy and you are afraid that you discover that you did something wrong, other people, who played that mission will warn you and that's most inconvenient.
  • Do not be afraid of time: the more time you spend to look after your mission the better it will become, the more ideas you will get how to make it better.
  • Never, never, never get annoyed by a bug you can fix. If a debriefing shows up at a bad time every time you test your mission, keep cool. Open up the debriefing window, look at the SEXP tree and think slowly, logically and first of all, calmly. The more time you spend with a bug the more chance you have to fix it. If you manage to fix a problem that you had been fighting with for hours, you will feel more deliberated.
  • Never be satisfied: Always want to add new things. If needed, sit ten, twenty or even thirty minutes looking onto the boring grid of FRED while thinking into the possible ways of adding new items. Look into the Events window and zoom in/out at the ships and an idea will soon come what to add.
  • Use the Designer's notes! Note down bugs you do not want to fix in the moment you discovered it, note down anything you will want to add. Keep erasing your notes as soon as they become obsolete. Do not let others see your mission until there are any notes left. This window can also be used to communicate with other mission designers, if not only you have been assigned to that mission.
  • Concentrate on fixing only one bug: Do not try to fix multiple bugs unless you are sure it won't need any testing after you have fixed it (typing mistakes, no ships in Escort List, etc).
  • Never release a mission without testing its last version twice or three times. A seemingly minor change like changing wing delays can result in unexpected difficulties.
  • Never be the sole tester, give it out to others, preferably from any skill level, to test for difficulty, pacing, etc. What works for you, might not work for others.

Testing someone else's mission

The testing process

Remember that by the time you receive the mission file, it's supposed to be more or less complete. For the first test run, play as if you were any casual player who is playing a user-made mission for fun. Don't specifically look for mistakes. If you find some mistakes even so, those mistakes must be ones that any player will come across. These mistakes will likely come up every time you play the mission, so they are to be reported and fixed as soon as possible. You'll now have a clue about the mission. After a few more casual plays, dig yourself deep into some real testing.

Now start testing a mission as if it were your own, except you can afford more test runs because you don't have to fix the mistakes. Use notes to keep track of your findings. Pay attention to details and test every possible mission outcome. You may win the mission totally by blowing up all the three hostile cruisers while keeping your corvette alive, but try to lose the corvette once and see what the debriefing will say.

Lastly, open the mission in FRED and look around. You may discover some unused Events, a forever-invalid mission objective. You'll be point out some mistakes that would otherwise require a dozen re-runs to be found.

Submitting feedback

Submitting feedback to the mission designer is the last step in your testing of someone else's mission. Whatever way of information echange you choose (email, forum post, instant messaging) remember to be objective. Don't use attributives like "bad" or "amateurish," even if the mission designer made a very blatant mistake. Even experienced mission designers tend to forget about putting mission critical craft on the Escort List. A factual "There is no Escort List." sentence will do it. If the mission designer is a beginner, explain why the Escort List is needed. This must indeed be an explanation.

Don't report all your findings. A disproportionately long list of mistakes is discouraging. Concentrate on the really important mistakes first and put forward some propositions on how to fix them.

While it has previously been said to be as objective as possible, some praise—which is inherently subjective—helps maintain a steady level of encouragement. Be specific about your compliments, also. A very general, "The mission was excellent, but I have a long list of mistakes here" sentence sounds dishonest. A dishonest praise is no praise. It is okay to praise the mission for its intensity and point out some minor briefing icon-related mistakes.

Speeding up your testing

FREDders, especially when making a campaign, are faced with time constraints due to real life reasons. This section will help you minimize your testing time without sacrificing effectiveness.

  • Most importantly, minimize your loading times. A very straightforward way of doing this is to disable the MediaVPs and all graphical enhancements (FreeSpace Open users only). Don't be too minimalistic, however. Keep it to your tolerable standard, otherwise it will distract your attention from the testing part.
  • Using windowed mode will prevent your game from crashing if you change between the game and FRED using ALT-Tab. (FreeSpace Open only).
    • Note: Retail FreeSpace users will not encounter the above problem.
  • Rename your mission to make it the first on the list in your Mission Simulator. Renaming your mission to a_<mission name>.fs2 or 1_<mission name>.fs2 will be sufficient. Don't forget to rename it again to its finalized name when you start thoroughly testing another mission.
  • There are no moral standards for testing. Feel free to use cheats to easily and quickly reach the part of the mission you want to test. Making use of "developer Events" like ones that make friendly mission critical craft invulnerable is also possible. Don't delete such Events when you are done, because that would change the order of Events, and break the mission. Use false instead to disable them.
  • You can set up a one-mission campaign to easily access your mission by clicking on the Ready Room, instead of using the Tech Room method. This method may compromise your pilot file when not done right, so either make a backup copy or a new pilot. Less experienced mission designers may not want to follow this method at all.
  • Decide which changes actually need testing. You may want to test if your briefing icons are set up right, but you may not have to test spelling corrections. The more experienced you are, the better you'll be able to judge which changes require testing.
  • To test if certain Events work or not, use directives. Therefore, you will be able to tell when and if the problematic Event turns true or false.

Testing your campaign

By the time you had set up your campaign file, you'll ideally have a series or more-or-less finalized missions. This section will give you advice on how to test if your campaign file is set up properly. Remember that changes applied to your campaign file will take effect only when you reset your campaign in the Campaign Room.

  • First and foremost, your Error Checker must not indicate a problem. If it does, it's very likely something won't work right.
  • Enter the Campaign Room, select your campaign, and read your campaign's description at least twice to discover if you have done some typos or made some spelling mistakes. If you discover something you want to change, don't do that yet!
  • Run the first mission and discover if the player has access to all the intended ships and weapons. First-time campaign makers tend to forget that they must allow the player to use certain ships and weapons in the campaign file. If the player has weapons and flies the intended fighter by default, it's okay. If you have found anything you want to change while you were in the Campaign Room window, do that change now. If the player doesn't have access to all the intended weapons or ships and you found a spelling mistake in your campaign's description, you can change all that in one run.
  • To test if your Repeat Mission SEXPs work, jump out at the beginning of each mission and see if the game tells you to replay the mission in the debriefing room. Ideally, it will. If not, revise.
  • Test what happens if the player is minimalistic. Complete only those objectives that will allow the player to progress in the campaign. You can be a maximalist for the second or third re-run.
  • If you complete your campaign, see what happens if you click on the Ready Room. If it says you have completed the campaign, you're done.
  • If you're using custom tables and/or mods, set up a mod folder that contains only the files you're about to release. This will objectively reflect what your players will have when they download your campaign. If there's a mod you've forgotten to include in your download, this method will bring that to light.

See also

General hints
Typical FREDding mistakes
Tips for mission balancing