Difference between revisions of "Testing"

From FreeSpace Wiki
Jump to: navigation, search
m
(Some expansion. More will come soon)
Line 1: Line 1:
 
<b>Keywords:</b> patience, time, circumspection, purposefulness
 
<b>Keywords:</b> 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.<br>
 
*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.<br>
 
*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.<br>
 
*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.<br>
Line 9: 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.
 +
 +
==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 [[MediaVP]]s and all graphical enhancements ([[FSSCP Introduction|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.
  
 
==See also==
 
==See also==

Revision as of 17:33, 27 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.

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.

See also

General hints
Typical FREDding mistakes
Tips for mission balancing