We could define a campaign as a serie of scenarios linked on a given sequence, adding specifics options to each scenario in addition to the own scenario's options. One special type of scenario is the "Choice" scenario, which allows the player to pick between different choices to play different paths.

Campaigns can define some additional media files, like videos, music, text with photos to create an additional enviroment to the player, at start of the campaign, when any scenario is finish, when any scenario is loaded to continue the campaign and whenever the campaign is won or lost.

Also the campaign rules the prestige, allowing to assign an initial amount of prestige (usually need to buy your core units) and the prestige awarded to players, according their result in previous scenario. That prestige awarded can be limited to a maximun in each scenario (the CAP)

These additional options can be defined for each scenario in the campaign:

• Can force to lose all your core units
• Can disable autorefit at start of scenario (by defualt core units are replenished when moved to next scenario)
• Can disable autoresupply at start of scenario (by default they resupplied)
• Can allow to upgrade and Overstrength units in Supply Hexes (SH)
• Can force your core units to adopt the main country at start of scenario
• Can define to skip updating score for the scenario (usually for Choice scenarios)
• Can define to disable upgrading units at initial HQ
• Can define to disable purchasing new unit
• Can disable to sell prototypes

All the units purchased when playing a campaign become "core" units, although only the initial core and the prototypes are free. The rest of purchased, count as the "army cost" which affects the limit of prestige awarded at the end of each scenario, so as bigger is the cost of your army, the less prestige you will be awarded depending on each scenario cap.

The campaign CAP has been called for years the 'Jensen Cap', because it was Jensen who first figured how it worked, I'll call here just CAP for short. The following was written by Philip "Reepicheep" Nelson and it is probably the best description of the prestige cap system. Many thanks to Reepi for the great explanation

At the end of a scenario in a campaign, there is the possibility of winning a prestige award above and beyond what you can earn within the scenario. This award is not affected by the prestige setting, and is a pre-set amount per victory condition. For instance, the maximum possible award for a BV is usually 1000 prestige, and for a NV it is usually 1,500. How much of it you can win is determined by the CAP, which is also a pre-set figure.

Now, the award is determined when the computer compares the CAP to the value of your army plus your prestige. It is important to note that the original units in a campaign are not counted against the CAP, nor are prototypes. (I am assuming original core units are always free, regardless of the campaign. I don't know if user-made campaigns can bypass that feature or not). Anyway, those units represent 'free' slots. For instance, let's say you win a Pz IIIG prototype at Madrid. Not only is that a free tank, it also represents a free tank slot. You could upgrade it to a Maus and it would not count against the CAP. Overstrength is not counted against the CAP either.

If the value of your army plus your prestige is less than the CAP, you win the difference up to the maximum prestige award for the type of victory you won. Otherwise, you get nothing.

For example, at Madrid (SSI stock campaign) player we start with 500 prestige. The CAP is 2,000. The award for a BV is 1000. That means that in order to get the full award for a BV at the end of the scenario, we cannot accumulate more than 1,000 prestige. But at 100%, it is very easy to do so. The only way to keep from wasting the prestige award is to judiciously refit our troops. If done properly, we could have about 2,000 prestige to spend heading into Ciechanow.

Now, the CAP at Ciechanow is 2,500. Let's say we squeezed every last drop of prestige out of Madrid, and have 2,000 to spend. Since once again the award is 1,000 for a BV, we need to keep the total value of our assets at 1,500 in order to reap its full benefit. But not only do we have more prestige than that in the bank, we will be capturing much more. The best solution to that problem is to upgrade our original core units, as they represent unit slots that will never count against the CAP.

We can, and probably should buy new units too; but we must keep in mind that they count against the CAP. Let's say we buy a SdKfz 6/2 and a Pz 38(t)A. That's 660 prestige(in the Adlerkorps e-file). Since our target value for maximum prestige accrued was 1,500, we must subtract 660 from it . The new figure is 840, and we must make certain we do not accumulate more prestige than that during the scenario. We still have plenty of prestige left; and knowing that at this rate we will still have more than 840 prestige at the end of the scenario, we decide to overstrength a couple units before upgrading them as that also does not count against the CAP. Essentially, such overstrength becomes 'pre-replacements", and we are not concerned about losing it at this point.

Upgrades of purchased equipment 'lose' prestige in regards to the CAP, since only the prestige cost of the current equipment is counted. For example, upgrading a unit worth 300 prestige to something worth 600 will cost 450, but the computer sees that as an army value increase of only 300. Thus 150 prestige is 'lost'. That can be an excellent way of using prestige that would be wasted anyway.

By using upgrades, overstrength, and replacements as a means of keeping the total value of your assets under the CAP, you can develop a stunning army at any prestige setting.

Scenarios are the basic game files.
The scenario file defines the countries, sides and the units for each player. Scenarios can be configured to have 2,3 or 4 players, having each one a main country plus 4 support countries and one of the possible sides (Axe/Allied, or whichever designer named them...).

Scenarios also should define the "enviroment" data, like the map (either as image or tiled), the number of turns, the latitude (climate zine), initial weather, ground condition and the iconset to use the units. A title to show in game, an intro text/jpg file to explain the player some hints and optionally a custom music to play.

Scenarios must define the numbers of turns; the victory conditions and the size of the pool of transports of different type (Air, Naval, Rail or Helo) as well as other optional data.

Scenarios can include also a set of "options" that enable/disable certain rules, being the most important:

• Default exp. level for new units
• Default strength of new units
• If units having "blow" ability, can actually blow in this scenario
• If units having "Buil/Repair" ability, can actually build and/or repair in this scenario
• If air units can be intercepted by ground units
• If some ships can behave as Flaks
• If barrage fire can be used in this senario
• If air units are going to Air Missions instead
• If scenario can limit the units to purchase (no more than XX units)
• If first player turn is skipped
• If units having range/spot as zero works as PG2, or they an only fire/spot the own hex
• If line of fire is blocked behind Mountains, Forest and Cities
• If line of sight is blocked/limited by some terrain
• If roads will work on any terrain, or will be compatible with PG2
• When reinforces arrive (at start of turn or when player is activated)
• If port terrain behaves as Supply Hex or not
• If naval units can deploy in ports or not
• If paratroopers can misdrop randomly
• If weather can change ground condition
• if additional naval rules are in effect
• If scenario must discard all options not compatible with PG2 engine (Pg2-Mode)

Scenarios can be played in different ways, depending on how they have been designed:

• To play standalone
  Represent a single battle and one any side wins or last turn is reached, the scenario finishes returning to main menu. Can be played against the AI or against another player in "hot-seat" mode. At any time player can save the game, creating a XSAV file, that can be loaded later to continue playing.
• To play by mail (PBEM)
  Represent a single battle played by 2 humans players. One player starts the scenario and whenever any player finishes his turn, the game is saved and returns to main menu. Then that save game (.XEML) might be sent to the other player by email. When the opponent receive the XEML file, he opens it to play his turn. Usually he replays the opponent last turn before playing his turn. And so on, until any wins or last turn is reached.
• To play as part of a Campaign
  When playing as part of a campaign, scenarios are played according a sequence defined in the campaign file, and some units (the "core") are carried over next scenario. This kind of scenarios are played always against the AI. At any time the player can save the game, creating a XCSV file, that can be loaded later to continue playing.

Scenarios must define also the units to be commanded by each player. (see below) and the prestige the players can add for taking some positions on map, or simple because each turn assigns any. Prestige is the "coin" to purchase units and other things.

When picking a scenario or campaign to play, player can set a prestige modifier, ruling how much prestige is actually given for capturing hexes or as turn assignment, as bigger the percentage as easier to play the game

Scenarios should define the units for each player in game and when playing campaigns, the core units from previous scenario are added to the units defined in the next scenario.

Scenario units are instances of Efile units (thus inheriting all stats and attributes from Efile) but having additional stats that can change during the flow of the battle. For example the units will increase experience level whan combating and whenever the experience bars are increased the unit can raise a leader. Also the unit strength can change because casualties/reinforces, and the ammo and fuel is spent and refit. In addition the unit can get entrechment depending the terrain and the time the unit stays in it.

Some specific options/attributes can be assigned to scenarios units in design :

• Unit can be assigned as a depot, allowing other unit to resupply when adjacent
• Unit can be marked as void to reassing (recovering prestige by selling it)
• Unit can be set as a reinforce to arrive at a given turn, either in map or in HQ
• Unit can be assigned to icrease player prestige while alive
• Unit can be set as healing adjacent units
• Unit can be set as to blow the hex when killed
• Unit can be set as to start scenario with a certain leader
• Unit can be set as to start scenario with some attachments
• Unit can be set as MustSurviveUnit (MSU), affecting Victory conditions when MSU conditions are enabled in Victory Conditions
• Unit can be set as a new core unit, when playing campaigns

Scenario units, can be already deployed in map according an Order Of Battle (OOB) or placed at HeadQuarter (HQ) to be deployed by the player or AI.

When playing campaigns, player can be rewarded with a new free cost core unit, called a "prototype"

Core units can be bought spending prestige. When playing a campaign, these units become "core" units that can be carried over next scenarios, an these units do count for the campaign prestige cap. Core units can also be "reassigned" (removed) recovering their cost or upgraded to a different equipment, normally spending additional prestige.
See Units' cost below to know how cost of units is figured

These are the formulas used to get the unit's cost in Open General.

1.- "Integer division" is always used!

First and most important thing to realize is that all formulas use "integer division" ( / ), meaning that any fractional part is discarded, regardless how big it is. So a result of 1,9999 is same than 1,0001 and equal to just 1.

2. How cost of units is stored in efile.

The efile stores the cost of each unit as the cost to buy 10 strength points (aka sp) divided by 12.
Thus the formula to get the cost of N sp whose stored cost in efile is E is:
SC (for N sp) = (12 * E * N ) /10

3.- Cost of a unit having N sp

Being E the efile cost stored for the main code and T the efile cost stored for the organic transport, the cost (C) is:
C = (12 * (E+T) * N ) /10

When buying this formula is used with N = base sp
If unit has leader influence:
C = (C+1)/2

4.- Cost to add/remnove attachments.

For any attachment having a fixed cost of F, and a percentual cost V, the cost A is:
A = F + ( V * C ) /100 ... (* C is the cost of the unit as figured in #3)

5.- Cost to sell a unit having N sp

The cost is the sum of C (#3) and A (#4) for each attachment.

6. Cost to upgrade

The cost to upgrade a unit U1 to be U2 is a bit more complex
First figure the basic cost to use for main codes (E), being E1 and E2 the cost stored in efile for main codes of U1 and U2.
if E1>E2 then E = E2 - (E2 /2) else E =0

Then figure the basic cost to use for the transport codes (T), being T1 and T2 the cost stored in efile for transport codes of U1 and U2.
if T1>T2 then T = T2 - (T1 /2 ) else T =0. If no transport U1 or U2, T1/T2 are zero

The resultant cost to upgrade a unit having N sp:
C = (12 * (E + T) * N ) /10;
if has leader influence:
C = (C+1)/2

If the unit had attachments the engine updates also the cost for each attachment (can be changed or even removed during upgrade)
C = C + A2 - A1
being A2 the cost of attachment for U1 and A2 the cost of the attachment in U2, figured this way:
A1 = ( V1 * (M1+T1) * N ) /100
A2 = ( V2 * (M2+T2) * N ) /100

7.- Cost for reinforce/overstrengt

Although this routine always returns the cost for 1 sp
the engine the engine does the maths using the cost of 10 sp to eval the influence of elite/green,,
C10 = 12 * (E+T)

Then it figures the percentage for green/elite (P) and modifies C10 according that percentage:
C10 = (C10 * P )/ 100
if has leader influence:
C10 = (C10+1)/2

Resulting the cost to reinforce 1 sp as:
C = C10/10

Which is multiplied when needed by the sp required.

Depending on how a scenario is played, the file created when player (or engine) saves it, is one of these types:

• .XCSV files
  When saving a scenarioplayed standalone and player saves the same presing 'Ctrl+S' in keyborad or using menu "Game options". At the end of player turn, the engine saves automatically as AUTOSAVE_OPENSCN.xsav.
• .XEML files
  As the end of any player turn theplayer is prompted to save the game at that point as to send to the opponent. The proposed filename uses a certain structure agreed with PBEM players at start of development to make easier to handle saved turns.
• .XCSV files
  When saving a scenario played in a campaign and player saves the same presing 'Ctrl+S' in keyborad or using menu "Game options". At the end of player turn, the engine saves automatically as AUTOSAVE_OPENCAM.xsav. Also at the end of each scenario, engine saves automatically using a compound filemane make up of the campaing file plus the scenario-played-number-in campaign plus the result plus the prestige modifier (with suffix .xcsv)

There is an option to log the actions taken by players/AI, that allows to replay any scenario or part of it. All commands issue to units are stored in a .XLOG file than can be loaded later to watch how the game happened. This option can be enabled or disabled from User Settings Dialog

Also the AI turn can be logged to a text file (ai_turn.log) basically for testing purposes. Also can be enabled or disabled from User Settings Dialog.