Testing - Revision history

Mobius: Extra information on checkpoints, and personal opinion on the different types of finding a tester may report to any FREDder.

2022-11-21T11:58:52Z

Extra information on checkpoints, and personal opinion on the different types of finding a tester may report to any FREDder.

← Older revision		Revision as of 11:58, 21 November 2022
Line 31:		Line 31:

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

			It's worth noting that a mission featuring checkpoints may require several extra attempts to be adequately tested. Checkpoints were not part of the original FreeSpace games, and are a product of fans skills at generating advanced SEXPs and scripts. From a FREDding standpoint, the implementation of checkpoints add a considerable degree of extra complexity to the structure of any mission, and said complexity requires testing. A single, triggered event that does not take into consideration the checkpoint infrastructure may break the entire mission, so the mission itself requires all checkpoints to be tested.

	===Submitting feedback===		===Submitting feedback===
	Submitting feedback to the mission designer is the last step in your testing of someone else's mission. Whatever way of information exchange 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. What's obvious to veteran FREDders may not be obvious to beginners.		Submitting feedback to the mission designer is the last step in your testing of someone else's mission. Whatever way of information exchange 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. What's obvious to veteran FREDders may not be obvious to beginners. You may also wish to avoid curse words and other forms of unpolite phrasing in your testing report.

	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.		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.
Line 40:		Line 42:

	Differentiate between a "mistake" and a "designer choice." As a tester, you may notice that the briefing uses no colored text, but instead of portraying this absence as a mistake, ask the creator whether it was his intent to use one color only.		Differentiate between a "mistake" and a "designer choice." As a tester, you may notice that the briefing uses no colored text, but instead of portraying this absence as a mistake, ask the creator whether it was his intent to use one color only.

			===Types of findings===
			Testing is a rather complex process where several factors tend to converge: the process normally results into the finding of '''objective bugs''', '''recommendations''' on how to improve the mission, and what may be perceived as '''plotholes or inconsistencies'''. A tester has the right to provide feedback on all such aspects, but testing reports should be differentiated for a number of reasons.

			For example, if a critical ship is not guardianed in FRED and is also meant to survive, its destruction will result in a series of oddities, such as its messages being sent by Command, general mission unbalance, and a major plothole should the ship be featured in any of the following missions and/or be mentioned in debriefings as an operational asset. The FREDder may have simply forgot to guardian said ship without noticing it (''e.g.,'' the warship survived during his playthroughs but didn't during yours). This is a '''mission bug''' and should be mentioned as such.

			The above mentioned warship engages another warship during the mission via an AI attack order, so its maneuvers may follow unpredictable patterns and the armaments this ship is meant to fire at the opposing unit may not be used during the confrontation due to POV variations. At this point, the tester may recommend implementing waypoints and capship speed limitations to have a proper control on how the battle is likely to develop; guardianing key turrets and engines on both vessels elso ensures that the battle develops a certain way. Should a tester decide to recommend any of this, feedback of this kind is to be listed as a '''recommendation:''' the tester believes a number of changes may improve the mission, but the mission still works in its ''status quo'' and the FREDder may decide not to change what he's done.

			Now imagine the following scenario: the previous mission stated that this warship is not equipped with a certain weapon, yet this magically appears and the warships starts using it with no explanation whatsoever. Or, the ship sustained a lot of damage during the previous mission, yet its hull integrity is now set to 100%. Or, Command deploys this warship, saying that it's the largest asset available, yet we know for sure that there are other - and larger - warships available. Or, any of the above things combined, if not all of them. These all qualify as '''plot inconsistencies,''' and may compromise a player's impression on a campaign the negative way. A tester has all the right to point them out, but before doing so it may be a good idea to get acquainted with the new continuity created by the FREDder, as these occurrences may indeed have explanations but you didn't quite notice them. Once you are sure these could indeed be inconsistencies in the plot, submit them to the FREDder, but do so separately from the actual bugs and recommendation lists to avoid confusion and allow the FREDder to better manage mission bugfixing. The FREDder will then realize if they're actual inconsistencies or things that are covered by the plot, but not in a way that makes them obvious to the player (in this case, the FREDder may decide to add the much needed extra information required). Some of these potential inconsistencies may be in place for the sake of mission balance (''e.g.,'' the warship now has 100% hull integrity, it ended the previous mission with 17%, and anything below 40% in the current mission may make it too easy/difficult), so a proper compromise could be setting, for example, a hull integrity of around 80%, a few damaged subsystems and turrets here and there, and an extra bit of lore explaining how the warship was subject to rapid field repair.

	==Speeding up your testing==		==Speeding up your testing==

The Force: Undo revision 38733 by Hired (Talk)

2012-06-19T08:43:17Z

Undo revision 38733 by Hired (Talk)

← Older revision	Revision as of 08:43, 19 June 2012
(No difference)

TopAce: prevent redirect

2011-06-17T11:55:58Z

prevent redirect

← Older revision		Revision as of 11:55, 17 June 2011
Line 67:		Line 67:

	==See also==		==See also==
	*[[General ~~Hints~~ (~~FREDding~~)\|General hints]]		*[[General hints (FRED)\|General hints]]
	*[[Mission balance]]		*[[Mission balance]]
	*[[Typical FREDding mistakes]]		*[[Typical FREDding mistakes]]

	[[Category:FRED Tips]]		[[Category:FRED Tips]]

TopAce: some rewrite, additions

2011-06-17T09:59:32Z

some rewrite, additions

Show changes

TopAce: FREDer --> FREDder

2009-08-28T16:26:59Z

FREDer --> FREDder

← Older revision		Revision as of 16:26, 28 August 2009
Line 6:		Line 6:
	*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.<br>		*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.<br>
	*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.<br>		*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.<br>
	*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 aren't any notes left. This window can also be used to communicate with other mission designers, if you are not the only ~~FREDer~~ assigned to that mission.<br>		*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 aren't any notes left. This window can also be used to communicate with other mission designers, if you are not the only FREDder assigned to that mission.<br>
	*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).<br>		*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).<br>
	*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.

Qent: /* The testing process */ Removed an extra space.

2009-08-28T15:45:37Z

The testing process: Removed an extra space.

← Older revision		Revision as of 15:45, 28 August 2009
Line 22:		Line 22:
	On a few occasions, it helps not to test your mission, but ''play'' it. To clarify, you must not be specifically looking for mistakes, but try to see your mission through the eyes of a player who hasn't seen the mission yet and just wants to play. You may notice some inconsistencies or logical flaws between the briefing and how the mission actually plays out.		On a few occasions, it helps not to test your mission, but ''play'' it. To clarify, you must not be specifically looking for mistakes, but try to see your mission through the eyes of a player who hasn't seen the mission yet and just wants to play. You may notice some inconsistencies or logical flaws between the briefing and how the mission actually plays out.

	In the last testing stage, you should concentrate on minor details like adding cargo to cargo containers, prettifying your background, or adding some more [[Mission Chatter\|mission chatter]]. This stage will take a lot more time than the previous ones, because you won't be hunting for something particularly obvious or observable. As a general rule, note down anything you find and after a few more test runs, once you have accumulated a long list of observations, decide which ones are worth it. You'll also have to finalize your mission's difficulty. An adequately balanced mission requires several additional test runs which are solely devoted to finding the "right" difficulty. For more information and tips for balancing your mission, see [[Mission balance]] .		In the last testing stage, you should concentrate on minor details like adding cargo to cargo containers, prettifying your background, or adding some more [[Mission Chatter\|mission chatter]]. This stage will take a lot more time than the previous ones, because you won't be hunting for something particularly obvious or observable. As a general rule, note down anything you find and after a few more test runs, once you have accumulated a long list of observations, decide which ones are worth it. You'll also have to finalize your mission's difficulty. An adequately balanced mission requires several additional test runs which are solely devoted to finding the "right" difficulty. For more information and tips for balancing your mission, see [[Mission balance]].

	==Testing someone else's mission==		==Testing someone else's mission==

Qent: /* The testing process */ Typo.

2009-08-28T15:44:51Z

The testing process: Typo.

← Older revision		Revision as of 15:44, 28 August 2009
Line 30:		Line 30:
	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.		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 ~~albe~~ point out some mistakes that would otherwise require a dozen re-runs to be found.		Lastly, open the mission in FRED and look around. You may discover some unused Events, a forever-invalid mission objective. You'll be able to point out some mistakes that would otherwise require a dozen re-runs to be found.

	===Submitting feedback===		===Submitting feedback===

Qent: /* General hints */ I think this makes more sense.

2009-08-28T15:43:49Z

General hints: I think this makes more sense.

← Older revision		Revision as of 15:43, 28 August 2009
Line 6:		Line 6:
	*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.<br>		*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.<br>
	*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.<br>		*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.<br>
	*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.<br>		*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 aren't any notes left. This window can also be used to communicate with other mission designers, if you are not the only FREDer assigned to that mission.<br>
	*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).<br>		*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).<br>
	*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.

TopAce: /* The testing process */ a word was missing here

2009-08-28T12:55:52Z

The testing process: a word was missing here

← Older revision		Revision as of 12:55, 28 August 2009
Line 30:		Line 30:
	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.		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.		Lastly, open the mission in FRED and look around. You may discover some unused Events, a forever-invalid mission objective. You'll be albe point out some mistakes that would otherwise require a dozen re-runs to be found.

	===Submitting feedback===		===Submitting feedback===

TopAce: /* Testing your campaign */ another addition

2009-08-28T12:52:54Z

Testing your campaign: another addition

← Older revision		Revision as of 12:52, 28 August 2009
Line 62:		Line 62:
	*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 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.		*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.
			*You needn't test your campaign as a whole in the initial stages of creating the campaign file. You can test it in small chunks of three or four missions to see if the campaign file is set up correctly. Some missions might require a complex set of conditions to allow the player to progress; this method helps a bit in testing these kind of missions.

	==See also==		==See also==