Online Campaign Guidelines

This page is intended to be a set of guidelines for campaign designers in order to give an idea of the boundaries to work within, so that the campaign is a playable experience over the Internet.

This page was originally a post made at SB.com forums.

Page last updated in 2014.

Guidelines

1. Ideally, you should never go larger than one battalion versus two battalions. A fourth battalion can be added if said force has a delayed spawn, or if the others are not at full strength. Red Tide proved that the fourth battalion had to have a delayed arrival otherwise it placed some strain on the network, but not severe strain to the point that the session would be unplayable, but it would not be the ideal experience. Henceforth, this shall be known as the "3+1 battalion rule".
   
   
2. The larger the scenario size, the less you are able to embellish the experience with supply vehicles and on-map artillery. Even with the 3+1 battalion rule, on map artillery and abundant supply vehicles or civilians should not be added. The 3+1 should involve pure/lean line units only -- the essentials. A scenario featuring a company vs. a battalion (the ideal situation), then on-map artillery, civilians and full support units should be fine.
   
   
3. Always check units for carried troops and whether you need those troops. It can be wasteful when various vehicles intended for support carry troops, these should be deleted. Often you don't need to have every BRDM-2 recon vehicle carrying their one scout team, you have to find and spot excess and remove what is non-essential. Not only does too many units really detract from the experience (usually "more" is actually "less"), but keep in mind that SB has to keep track of each soldier, so unnecessary infantry should be removed if at all possible. One important point here is if you are modeling say, a red force on the attack. You don't need to give those BMPs infantry, if they aren't going to have scripted unloading points at waypoints or on routes. Otherwise, you may as well just remove the infantry from those BMPs that are moving along attack routes. To clarify though, if a unit never drops out its infantry then there is not a problem, but often these excess vehicles end up dismounted unnecessary troops at the start of scenarios (because of hold or defender orders on their carrier unit), or at some point they end up dropping out their infantry and these basically spawn entities that must be tracked during the session.
   
   
4. The larger the scenario, the less you are able to model a full TOE. If you exceed the 3+1 rule, then only essential vehicles should be represented, those HQ elements should not be present, only a CO vehicle.
   
   
5. As mentioned in #2, on-map artillery should be avoided in large scenarios at 3+1 and higher, on-map is only practical (in WAN setup) for unit sizes below 3+1 rule size. The reason is quite simple: with on-map artillery you will have extra vehicles on the map plus the tracking of artillery rounds in flight. Off map artillery is always best for very large scenarios/campaigns, but you can use some on-map artillery if used sparingly in those situations.
   
   
6. The larger the scenario map and or unit size, nav mesh should not be used to conserve resources on clients with older hardware.
   
   
7. The number of sides and size of map should not play a huge factor, unless said map is extremely heavily populated with objects or there is an excessive number of sides that have extremely detailed logic. In other words, everything can be done in excess, but neither of these things should be a "deal breaker" if used in moderation.
   
   
8. If you are spawning units in a scenario, always try to stagger them by a time delay so that they arrive in groups. When a unit is spawned it places a momentary strain on the network, as these units are created and the clients receive the data. I think Sean and I have always tried to follow a rule where no more than one battalion will arrive by spawn at once, but ideally you should probably stagger the spawn by company if you can manage it. There should be at least a 10 second delay between spawning groups. Doing this allows the large force to arrive piece by piece, allowing everyone on the network to keep up without a large force appearing suddenly, causing extreme network overload.
   
   
9. The less events that you have happening in the first second of the mission the better. For example, always try not to spawn units or have too many events occur at mission time > 0:00, delay this by about 10 seconds or so to allow all clients to get up to speed when the scenario starts.
   
   
10. Assume that you will always create a scenario that is too large on the first pass, then go back and look at ways to streamline it after it is created. And once a scenario has been proven to be unplayable, then drastic and uncomfortable editing MUST be done if you ever want it playable. I have learned this myself, spending weeks working on a scenario and eventually finding that I have to cut it in half.