Outpost 2 Custom Scenario Checklist

[Vagabond]

An Updated copy can be found in the wiki here: http://wiki.outpost2.net/doku.php?id=op2_sdk:custom_scenario_checklist.

Hey everyone,

I put together a checklist that contains most everything that should be considered in an Outpost 2 scenario before calling it polished. The checklist purposefully doesn’t discuss the scenario’s ‘fun factor’ since that is highly subjective and I think should typically be left up to the author. Someone can either use the checklist to ensure they hit all the wickets after coding a scenario or use the checklist to guide them through what is required. I’m hoping it will also be helpful to someone new to programming Outpost 2 scenarios so they can read about common pitfalls and requirements.

Let me know what you think overall and if there are any specifics that should be added or removed. I’d like to push it into a wiki article in the Outpost 2 mission coding section.

I think this checklist can be used as a litmus test on whether a scenario is polished and ready for inclusion in the next release of Outpost 2. I'd like to create a different forum topic to start sorting through which scenarios should be included in the next Outpost 2 release.


Outpost 2 Custom Scenario Checklist

Below is a checklist for reviewing against new Outpost 2 scenarios. The checklist is designed to highlight most requirements involved in making a scenario DLL mesh with Outpost 2 programmatically and fulfill typical expectations of Outpost 2 players. This list is meant as a guide but not a rigid requirement. It is not meant to prevent someone from being creative or breaking the rules.

All Scenarios

• DLL Filenames: Ensure the scenario’s DLL name does not conflict with an existing scenario.
  
  • Note: Consider using the Mission Scanner (http://wiki.outpost2.net/doku.php?id=op2_sdk:helper_programs) to check the name of scenario DLLs shipped with Outpost 2. Use the custom scenario wiki page to check established custom scenario DLL names.
• Map & Tech Tree Filenames: If using a custom map or tech tree, ensure its name does not conflict with existing map and tech tree names.
• Program Crashing Bugs: Ensure no game crashing bugs are present in scenario.
• Scenario Bugs: Ensure there are no other bugs in the scenario.
  
  • Note: if the scenario exposes a bug caused by the SDK or Outpost 2 itself, ensure the bug is documented in the wiki maps section or the scenario’s main forum post. Try to mitigate the bug as best possible.
• Winning Conditions: Ensure fulfilling all scenario objectives forces the winning player(s) to win.
• Losing Conditions: Ensure the scenario can be lost if proper conditions are met.
  
  • For multiplayer scenarios, consider not forcing a player to lose even when they are destroyed so they may watch the remainder of the game if they wish.
  • Consider adding a short delay to losing the scenario through a time trigger. This way the player can register why they are losing before the game immediately ends.
  • Common losing conditions:
    
    • Colony population falls too low to support even the most basic structures
    • Colony is no longer able to build required structures to win the game (IE structure factory destroyed and no structure factory kits available)
    • Colony no longer has a CC and has no CC kit available
    • Required wreckage recovered by opponent
• Map Cells: Ensure map cell types are set to match typical values. Impassable terrain like large rocks are I1/I2, cliffs have a high and low side, terrain speeds set appropriately.
• Music: Consider setting music playlist to match typical Outpost 2 scenario music selection (Eden vs Plymouth music). (For more details, goto: http://wiki.outpost2.net/doku.php?id=op2_sdk:music)
• Custom Scenario Gameplay/Rules: If the scenario contains gameplay altered from standard Outpost 2, ensure it is documented on the maps wiki page or the scenario’s main forum post. Common examples include: allowing colonists to be transferred using evac transports, forcing mining beacons to be discovered with scouts, forcing colonists to starve if food is not placed in trucks during evacuations, etc.
• Content Age Suitability: If scenario is going to be included in official Outpost 2 download, ensure mission briefings and backstory contain content that most people would find suitable for a 13 year old.

Land Rush Scenarios

• Morale: Keep morale steady until colony is established.
• Food Supply: Ensure starting food is sufficient to find a reasonable colony or do not allow food supply decrease until the colony is established.

Unit Only Scenarios

• Set Unit Only: Ensure the scenario is initialized as unit only so inapplicable messages are suppressed (like colony food store levels).
• Day/Night: Consider setting Day/Night to not cycle.

Single Player Specific

• Save/Load Game State: Ensure required game state data is stored in ScriptGlobal to allow saving and reloading the data as needed.
• Difficulty Settings: Ensure colony games implement more difficult gameplay based on selected difficulty.
  
  • Common ways to differ difficulty settings:
    
    • Increasing number of mission objectives
    • Reducing player’s starting resources, research, vehicles, structures, and structure kits
    • Strengthening enemy unit patrols or enemy AI
    • Reducing time until eruptions and/or blight appearance
    • Increasing frequency and/or strength of disasters
    • Reducing number of mine sites or the richness of their minerals
• Mission Briefing: Consider adding a mission briefing modal dialog box explaining scenario specifics and backstory if applicable. (For more details, goto: http://wiki.outpost2.net/doku.php?id=op2_sdk:textdialogbox).

Multiplayer Specific

• Scenario Name: Ensure scenario name as it appears within Outpost 2 matches established naming convention. For Example: 2P, LoS, 'Peacekeeper.'
• Scenario Filename: Ensure scenario is placed in proper category based on filename, for example Landrush, Last One Standing, etc. (For more details, goto: http://wiki.outpost2.net/doku.php?id=op2_sdk:scenario_naming_conventions)
• Morale Steady Check Box: Ensure morale is properly set as variable or steady when using the check box.
• Day/Night Check Box: Ensure day/night is properly set by the check box.
  
  • Note: For scenarios containing the blight, consider not allowing for day/night being disabled
• Disasters On/Off Check: Ensure Disasters can be turned on/off with the check box.
  
  • Note: Consider allowing volcanic eruptions to still occur with disasters off if they are essential to the scenario.
• Initial Vehicle Count: Ensure Initial vehicles are properly set and vehicle's weapon system matches proper colony.
  
  • Note: For non-military scenarios, consider giving non-military initial vehicles such as additional ConVecs, robo-miners, cargo trucks, etc.
• Initial Resources: Ensure changing initial colony resources changes the player’s starting resources appropriately.
• Custom Check Box Use: If the default use of the check boxes (morale steady, day/night, disasters) or initial vehicles is altered, ensure their function is documented in the wiki maps section or the main forum post.

Scenarios Coded from Scratch (Not using a project template as a base)
For more details on why and how to implement the following requirements, see http://wiki.outpost2.net/doku.php?id=op2_sdk:projectcreation.

• DLL Load Address: Ensure the scenario’s DLL is loaded into the proper base address and that dynamic base address shifting is set to off.
• Static Project Linking: The scenario should link statically to other libraries like the standard library and OP2Helper. Statically linking to the standard library will eliminate the dependency on the host computer have Microsoft Visual Studio 2015 C++ Redistributable and improve compatibility with WINE.
• Safe Exception Handling Off: Set Safe Exception handling compiler warnings to off. Outpost 2 does not comply with Safe Exception Handling and will not compile properly in some circumstances with this setting on.
  

----
EDIT 17-01-03: Added a section for Scenarios coded from scratch.

[Hooman]

I like that you put together a checklist for this. There are a lot of little details when making a scenario.

I was thinking concerns for custom game types should be collected in a separate section. Similarly, things that should be true by virtue of starting from a standard template (such as load base addresses) can also be separated out.

[Vagabond]

Thanks Hooman,

I separated out items that should be addressed simply by starting with a standard Visual Studio project template into its own section at the end as suggested.

When you say custom game types, do you mean Survival Multiplayer missions? Or do you mean messing with the function of the different check mark boxes like day/night to manipulate other factors of the game like difficulty?

I pushed this into the wiki here: http://wiki.outpost2.net/doku.php?id=op2_sdk:custom_scenario_checklist.

[Hooman]

I mean anything that you wouldn't expect to find in a stock Sierra released map. Things like mission briefings, non-standard use of of check boxes, and using the unit count dropdown for something other than military units. These are good points to bring up. They just don't apply to a standard stock mission.

It might also be good to separate out quality concerns as more of a requirement for official publishing. Saying things like your scenario shouldn't crash seem silly on their own, and not that useful as a checklist item for developing a level. It's not something you check off as you go. Saying no crashing bugs if you want your level published as part of the distribution is more to the point. Similar about age appropriate content. I don't mean to discourage anyone's attempt at making a Leisure Suit Larry level for OP2, but yeah, that sort of thing won't find it's way into the official download. Filename conflicts also probably fall in this category.

The note about map cells feels a little out of place. I suppose because it's usually not associated with making a DLL. It does however remind me of some point about marking the bottom row of tiles as impassable (for large maps?), for people working on maps. I'm not sure there are enough points on map making to warrant a separate list.

[Vagabond]

Hooman,

thank you for reviewing.

Good point on the I1 for the bottom row of cell types. The Mapmaker enforces this rule, but someone could try changing it programmatically. I added it to the checklist.

Does anyone know what happens if you set a celltype to something other than I1 on the bottom row? I programmatically changed a cell using GameMap::SetCellType(LOCATION(10 + X_, 128 + Y_), CellTypes::cellFastPassible1); on a 128x128 tile map. The scenario initialized fine and I was able to save/load it without issue.


What about adding a section called Official Publishing Requirements and moving the following items to it? I also reworded the items below to read better.

Official Publishing Requirements
In addition to the items described above, the following must be met before a new scenario is included in the official Outpost 2 release.

* Program Crashing Bugs: No game crashing bugs may be present in scenario.

* Scenario Bugs: There should be no bugs in the scenario.
    * if the scenario exposes a bug caused by the SDK or Outpost 2 itself, ensure the bug is documented in the wiki maps section or the scenario’s main forum post. Try to mitigate the bug as best possible.

* Content Age Suitability: The mission briefings and backstory contain content that most people would find suitable for a 13 year old.


I'm not sure about separating everything out for a non-stock scenario. To me, it makes more since to leave them within their other perspective categories. It seems rare that someone produces a vanilla stock scenario. The new section would become a hodgepodge of items that apply to either single or multiplayer scenarios.

[Hooman]

Does anyone know what happens if you set a celltype to something other than I1 on the bottom row?

I think there was a game crashing bug from units driving off the map.

It seems rare that someone produces a vanilla stock scenario. The new section would become a hodgepodge of items that apply to either single or multiplayer scenarios.

You're probably right. I was kind of wondering at the back of my mind if there is much work done of vanilla stock scenarios.

[Vagabond]

I just pushed the Official Publishing requirements into the wiki. I also did some minor rewording of some of the items. Mostly removed the words Note: and Ensure from everywhere.

Also added the following requirement for publishing:

  * **Outpost 2 Mods:** The scenario must not depend on an Outpost 2 mod that is not included in the official Outpost 2 download. For example, Multitek 2.

[Hooman]

Thank you for that.