CF combat Units and terrain Tiles are defined in separate files. This means many annoyances can be 'fixed' by making changes to the existing definition files and rebuilding the existing 'maps' (see my Building new maps section)) after which the rebuilt maps can then be played with the existing CF software. Other things require code changes to CF itself - and this means rebuilding CF from the 'source' (see my Building CF for Windows pages for details).
The Maps
The terrain layout and unit positioning of many maps is very 'unrealistic' - indeed it's obvious none of the roads were built by Romans (since none ever seem to take the most direct/obvious path from one 'factory' or 'depot' to the next, let alone the Roman 'we build roads straight through the woods / mountains' approach.
Often the obvious (short) river crossing point is 'bypassed' for a wider / harder to reach position 'downstream' - whilst some roads and bridges seem to have been built for no reason at all ! In some cases the road route seems to have been chosen AFTER the 'defences' (trenches, 'barbed wire', tank traps) were built !
There are also maps where a Depot / Factory has been built just one or two hex's away from a river or the sea (for example, the 'Foxhole' map, both 'northern' buildings are 'inland' for no obvious reason other than, perhaps, to prevent materials being delivered or ships being built or repaired there !
Whilst you have to be a bit careful not to 'ruin' the 'campaign story line', most of the unrealistic 'annoyances' built into the existing maps can be fixed just by adjusting the maps without changing anything else
Indeed, the terrain / unit layout is the easiest thing to fix, since you can 'open' the map using CoMET, modify the terrain with some mountains / woods / lakes etc. to 'justify' the road/rail routing and remove or add units, and then 'save' the modified version without needing to 'recompile' anything.
See my Fixing issues pages. Most of the rest of this page is a 'justification' for the changes I made to the Unit or Terrain Tile parameters for my reworked '-x3' maps.
Buildings
Bunkers/Pill Box Units and some house/barn Tiles exist, however the major 'building' type is the 'shop' or 'factory' Tile. Such 'buildings' should be regarded as a factory complex that is at least Town sized, so it's not unreasonable to enforce an 'Infantry only' requirement to 'capture' the complex (sending in the Tanks would only risk destruction of the very facilities you are trying to capture intact). It's how forces already within the complex behave that's unrealistic
There is a need for more 'house' Tiles, and 'houses' should give some advantage to the Infantry/light guns 'defending' them (it's not unreasonable to 'ban' AFV's from houses) Bunkers, on the other hand, are Units rather than Tiles (which means Bunkers can be destroyed, but not captured). By adding the 'transporter' attribute to Bunkers, it becomes possible for Infantry (and light guns) to 'shelter' within them.
Neutral buildings (and forces)
For a start, there is the ludicrous behaviour of Neutral Infantry.
Whilst it's reasonable to suggest that neutral factory workers could be 'convinced' to work for who ever arrives (with a gun) first (or next) - and that equipment (such as tanks etc) stored in an un-manned depot is 'up for grabs' (and can be seized intact by anyone), it's hard to believe that 'neutral' Infantry forces would be instantly 'convinced' to fight on the side of who-ever arrived first (unless, of course, they are all simply (re-)programmable robots) A rather more believable scenario would be that any neutral Infantry (indeed, all Neutral military forces) might fight (and die) to prevent their factory being captured - or at the very least surrender and be imprisoned (or escape and run away) rather than 'defect'.
This can be 'fixed' by removing Infantry from all neutral depots and factories. However it's not unreasonable to suggest that Infantry could be recruited from 'neutral' populations (after all, in any neutral country there's bound to be volunteers willing to fight for both sides), so Infantry 'manufacturing' should remain
Enemy forces
Then we come to enemy troops being stored or 'repaired' in Depots etc. Why they don't fight to defend the Depot is beyond me, however perhaps we can assume all the (vehicle) crews 'go on leave' to the local Town whilst waiting for their Tanks etc. to be repaired.
However expecting one sides infantry to instantly 'defect' to the other side is just total nonsense. Further, whist you might expect to capture enemy buildings or manufacturing facilities more or less intact (if you move fast), it's hard to believe that the enemy repair engineers would make no attempt to destroy equipment (rather than just let it all fall into enemy hands intact) - and even when you do manage to capture kit, you would then need to 'man' those Tanks etc. with your own troops. A modern army might have sufficiently flexible Infantry that could, at a pinch, be sent to man Tanks and guns etc, however it's hard to see how they would (magically) learn to fly Helicopter Gunships etc. So it's doubly ludicrous for 'turned' units to retain their 'level of experience when Infantry 'manning' the equipment would have no specific training on that unit type at all !
Whilst a partial fix might be possible using Events, it's likely code changes will be needed to sort this out, especially if you need to 'man' equipment using your own Infantry
The need to 'man' captured kit will mean a LOT more Infantry will be running around on every map, which is more 'realistic' but means the APC / transport / repair problems all have to be sorted out (see later)
General Unit and terrain Tile issues
Movement
One thing you will immediately notice is how slow aircraft fly - or how fast ground units move, except rail units (which move at infantry speed)
This can be 'fixed' easily - in this case by rebuilding the Units and Terrain files with new move parameters - however there are so many unit problems to consider that a spreadsheet is vital to help you avoid introducing more issues
Next you will discover that no unit can pass through another. Even aircraft are unable to pass (fly over) any other unit, not even your own forces !
Friendly forces should be allowed to pass through one another, and aircraft should be able to fly over any unit that has no capability of shooting them down. However, fixing all this requires code changes.
Then we come to terrain that can (or can't) be entered by various units.
Examples are numerous - starting with the 'anti-aircraft' tanks that can climb mountains (whilst other "tanks" can't) and the magic tank traps that no tank except 'anti-aircraft' tanks can cross, barbed wire that can only be crossed by infantry and bridges that can't be under passed by boats. Since they are Terrain, none of the above mentioned 'obstacles' can be attacked or destroyed, not even by artillery :-(
Some of this can be fixed by changing the definition sin the Terrain Tiles file (see later) and some can be fixed using the Events system, however some need code changes.
Relative strengths
Many of the units seem extremely poorly 'designed' for their 'role' - for example, placing your Infantry into an APC (Personal Carrier) makes them MORE vulnerable, not less !
One of my particular annoyances is the way Gunships (Helicopters) can kill Interceptors (fast jets) at a ratio of 3:1 !
Unit attack and defence ('armour') values are easy to change - for example the Interceptor can have it's attack and armour values increased (so they can shoot down Helicopter Gunships without problem), however, as already noted, a spreadsheet is the only way to ensure 'balance'
Roads
There are the two types of 'road' tile = 'Tarmac' and 'Dirt Tracks'.
Tarmac plainly has 'magical' properties = it allows Heavy Tanks to move faster than Helicopter Gunships (7 v's 6) !!!! On the other hand, 'dirt tracks' have no effect on movement at all ! Plainly 'real life' roads don't allow ground units to reach 300+ mph and 'tracks' should have some (perhaps minor) effect (otherwise there would be just no point in distinguishing 'tracks' from 'grass')
To fix this I had to increase all the Unit move allowances and all the terrain Tile 'cost to enter' values. Again, a spreadsheet was necessary to 'keep track' of Unit speeds
One unwanted effect is that Ground and Sea units with a move allowance greater than 16 suddenly gain the ability to pass through other units !!!
Unfortunately that means that a human played can end their turn 'on top of' another Unit, and if the other Unit doesn't have 'transport' capability, the CF program will crash :-(
Water
There is a set of 'river' (streams) tiles plus 3 types of 'sea' tile = shallow (which can be used to create a (major) river, along with the 'beach' tiles), medium and deep water.
Since streams have footbridges, it seems reasonable to allow Tanks to 'wade' across the stream. I also allowed Tanks to cross shallowwater Rivers at 'fords' (water + rock Tiles) Submarines were limited to deep water (which is total nonsense since this prevents them reaching the ocean from their bases) so I gave them water ability. Transport Ships are limited to deep and medium sea hex's, which would be 'OK' except for one thing = there is no 'landing craft' Unit ! Instead of a landing craft, we have a massive Hovercraft = one capable of transporting Heavy Tanks (something that the puny Transport Aircraft can't do ... which is rather odd, given that jet engines are plainly available ..). I downgraded the Hovercraft but left the Transport Aircraft 'as is'.
The Unit definition files are easy enough to modify, which means changing a Units ability to enter specific terrain is easy enough, as is creating new units. The Unit 'carry / weight' values are also easy enough to change (again, a spreadsheet is vital)
Bridges
There are two types of bridge over shallow sea-water = Tarmac Road bridges and Rail bridges. However, sea units are 'blocked' by these bridges, which is annoying (but was easy to fix)
There is no dirt Track over shallow water, but a complete set of bridges over 'streams' exists (Tarmac, Rail, Track and Footbridge (a sort of 'rope bridge' that only infantry are allowed to use).
We can define a 'ferry' for rivers 2 or more shallowwater tiles in width by deploying a Transport Ship into water tiles (it can't move out of position if the rest of the river is shallowwater) = you move units into it on one turn, it then moves across the (2 or more tile) river to the opposite bank and you exit the next turn) Since the Ferry is a ship, it can be 'sunk' (attacked and destroyed) just like any other unit
Resources ('crystals')
Why the original game designers (BlueByte) had to use the nonsense concept of 'crystals' (rather than just 'Resources' or even 'Building Materials') is beyond me, however the repair/factory system does work remarkably well
One rather odd thing is that whilst any building (with sufficient resources) can 'repair' units, only those designated as 'Factories' can build new units. However, this is not totally unreasonable, as we can assume that 'repair' is from pre-manufactured 'spare part crystals', whilst new build is from scratch using 'raw material crystals' :-)
Perhaps more of an 'annoyance' is that on many maps the buildings have no 'resource generation' capability, so, after the (usually, very) limited 'stock' of resources have been 'used up' that building is no longer of any use and is not even 'worth' defending.
It is possible to use transport units to load Crystals at one building and transport them to another. However buildings are usually so far apart, and factories so far from the 'front line', that by the time you have moved 'crystals' to the factory and used them to build new units, the battle is over. It's of note that the A.I. has no concept of moving Crystals - further the A.I. will 'build' (only) the most 'expensive' unit it can afford each turn - so if resource replenishment is low it builds Infantry, if high it builds Artillery (or whatever other most expensive unit is allowed)
There is actually a need for a cheap 'lorry' (transport unit) with decent "materials" carrying capacity - also a 'Tank Transporter' (which is capable of carrying a (single) Heavy Tank at a road speed faster than the actual Tank (of course) is also needed
For 'repair only' buildings, CoMET should be used to add some 'resource generation' rate to every building. On a small map the rate needs to be at least 3 per turn to make a building worth defending (or capturing), whilst on larger maps (with many more units available) 4-6 is needed to provide a decent incentive. Since the A.I. is so poor at choosing what units to build, the Events system should be used to replace 'resources' with 'reinforcements' in factories run by the A.I. (those run by a human player can be left 'as is')
Repairing units
Repairing costs the same resources ('5 crystals') and takes the same time (1 turn) no matter what the damage or original 'cost' of the unit - plus you have to 'return to base' !!
When you take into account the very low resource generation rate on just about every map (and the position of your base / factory / depots, typically multiple turns to your rear), it's only ever worth repairing the most expensive (and fastest) unit types. Even then, unless you are fighting very close to your own base(s), by the time your unit has been moved back to base, been repaired, and moved back to the front, the battle will be over long ago. So, in practice, the only things worth 'repairing' are air units - whilst other damaged units are better used as 'bait' to tempt the enemy out of position etc (i.e. as 'cannon fodder')
The 'return to base' for 'repair' is also rather 'counter intuitive' - yes, MAJOR damage might require some heavy equipment (Tanks etc.) to be 'returned to base', however few armies fighting in the field would require it's combat units to 'return home'. Rather, units would be withdrawn from the action in the front line and 'rested' (just to the rear) whilst being re-equipped (and absorbing replacement crews) etc.
It's a fact that during WW2, the German 'field repair' units were so effective that (so long as they remained in control of the battle field) up to 1/3rd of the Tanks 'lost' during combat would repaired 'in situ' during the night and be back in action the following day !
Fortunately, Crimson Fields already supports the concept of a 'mobile repair shops' (intended for 'Hospital Trains' and 'Aircraft carriers', but there's nothing to stop you applying it to an APC etc).
Even better, to 'repair' a unit it has to be 'loaded' into the mobile repair shop. By setting a 'max unit weight' factor it is possible to limit what can be 'loaded' into the mobile repair shop and thus what can be repaired by it !
Some specific Unit issues
The 'Scout' unit type may be fast moving, but it's rather easy to kill. It does, however, have a 'range attack' capability (unlike APC's & Tanks etc).
The 'problem' with this is that maps have no 'fog of war' (i.e. all players get a "God's-eye" overview) This means no-one can hide their units anywhere (except in Buildings) and there is no advantage what-so-ever in 'scouting' in front of your forces (all you will do is get the 'scout' unit killed) Instead the 'scout' is best used as an indirect fire 'support' unit (positioned directly behind an attacking unit) i.e. as a sort of self-propelled mortar or short-range howitzer = and for sure not wasted by rushing off in front of your forces (where it will just be 'premium' target)
Interceptors are killed by Gunships and have no ground attack capability - so there really is no point in wasting resources building them at all (you are better off with Gunships, or, if you must, 'Fighters' (which are actually 'Ground Attack Fighters'))
Submarines can only 'move' in deep water and have no 'dive' capability, so can't 'hide' from the enemy (which is more nonsense).
The real advantage of Submarines is their 3 hex range attack capability. This allows you to use them as 'Sea Artillery' from the 3rd rank (i.e. behind the Torpedo Boats in the second rank which are themselves fighting behind the Patrol Boats in the first rank). NB. Submarines (& Torpedo Boats) can even fire at enemy units 'behind' intervening 'land' hex's, which is useful, when you discover that sea units can't pass under road or rail bridges (but can fire under them, but, of course, only at other sea units) Since we have Aircraft Carriers, it seems a shame there are no other 'capital' naval units (Destroyers, Cruisers, Battleships etc). Somehow 'escorting' your Aircraft Carrier with nothing but Gunboats just doesn't feel right :-)
Next we come to "mines". The "mine" unit is a sort of 'concrete tank trap' (or, at Sea, a 'floating rock') since all they can be used for is to 'block' the movement of other units. They are quite tough, but can be 'destroyed' with impunity since they don't 'fight back'
Land mines are only ever 'pre-deployed' (no land unit can carry mines, although it's easy enough to change that) Sea mines can be carried and deployed by Patrol Boats. However, to add to the unreality, Patrol Boats can also 'Sweep' mines (i.e. pick them up and use them again :-) ) Since a mine has no 'attack' (or 'counter attack') capability, it can only be used as a barrier, to "slow down the enemy". However, since you can't 'attack' your own mines, your land mines are an impenetrable barrier to your forces = whilst you can attack and destroy enemy mines to get past !
The way mines are used is such total nonsense that it was one of the very first things I 'fixed' (changing the existing 'mine' unit icon into a 'concrete block' was a good first step :-) ) However it tuns out that Mines offer a whole world of opportunities ! == see later re: Bridge building and destruction ..
Transport units
There are so many issues with transport units that they get their own section.
The first problem is that any 'combat' damage to the 'transport unit' is immediately applied to units being carried !
Whilst there is some justification for damage to a truck to be applied to it's contents, the same can't be applied to air or sea transport. Sure, the contents of a transport aircraft (or transport ship) would be (totally) lost when the plane 'goes down' (or the ship sinks) but whilst it continues to fly (or float) we would expect the cargo to be essentially undamaged.
This 'damage the content' effect has a major negative effect on game play.
Infantry use of APC's
Even on todays battlefield, it's rare for infantry to run around unprotected, however in CF letting a loaded APC anywhere near the enemy is just an invitation to get your Infantry killed - and that totally negates the sole purpose of using an APC, which is to protect the Infantry inside !
The 'kill the contents' effect plus the fact that APC's are restricted to roads and 'grassland' (and hardly moves faster than Infantry = indeed, the mixed terrain of most maps means APC's are often so 'blocked in' by 'impassible' terrain that trying to move your Infantry in APC's is actually SLOWER) means few players will ever bother 'building' or using APC's. Allowing APC's to move through the same terrain as other tracked vehicles helps (Units file, movement values), especially as there is one trick you can already pull = if you move an APC with Infantry already inside, at the end of the APC's move the Infantry can exit the APC by making their own full distance move. Adjusting the APC 'defense' factor in the Units file (to make it much harder to damage) whilst reducing it's 'attack' capability (to essentially zero, to stop players using them as 'mobile pill boxes' :-) )
Transporting the wounded
It's suicidally risky to use any sort of transport to evacuate your 'wounded'. A transport taking 1 or 2 damage can result in units inside on a strength of 1 or 2 being 'wiped out' !
This is especially annoying when you use (or try to use) Transport Aircraft to pick up the wounded. Transport aircraft are extremely vulnerable to AA fire and if you take a couple of hits on the way home (which is more or less inevitable) your aircraft will arrive with nothing but dead bodies on board. So, after delivering their initial cargo of troops to the front lines, instead of using your APC's, Hovercraft, Transport Aircraft and Ships to 'pick up' and evacuate the wounded (back to base where they can be 'repaired' and where fresh units might be waiting to be picked up), more often than not the 'carriers' are of more use as 'cannon fodder'. Part of the problem is that the Depot etc. is so far from the front line that by the time anything gets there, is repaired, and makes it back to the front line, the battle is essentially over.
Code changes are really needed to 'fix' carriers (APC, transport planes/ships). The obvious change is to just remove the 'carrier damage = units inside damaged' approach EXCEPT when the carrier is totally destroyed. This lets us leave the 'vulnerability' of transport aircraft and ships the same. Of course, even if the carrier is destroyed, on favourable terrain some of the passengers should 'survive' = however things get rather complicated when it comes to transport ships, landing craft and aircraft over water. So the 'quick fix' is just to eliminate the contents with the unit
Carry limits
Whilst a 'transport' unit has a weight 'carry limit', losses are not taken into account when a unit is 'weighed' (i.e. a half strength unit does not count as half weight). Also, losses to the transport has no effect on it's carrying capacity (transport on '1 life left' can carry the same as a 'full strength' unit)
This is, perhaps, not 'unreasonable' if you regard a 'half strength' unit as still comprising all vehicles etc. with each having 50% damage (rather than as having lost 50% of it's Tanks etc).
The 'weight' system is also 'too course' = Heavy Tanks (and Artillery) should be many multiple times the weight of Infantry. Plus, some of the unit 'weights' are rather 'odd' (but all of this is easy enough to change :-) ).
I started by multiplying unit weights by 3, and then by 5. This gave me enough 'space' to fit in Missiles as well as making some 'fine adjustments'. I ended up spread-sheeting all units, since each transport type has both a max' and 'min' individual weight (as well as a total it can carry) and these parameters must be used to control what types unit can be carried)
The missing transports
Landing Craft - the existing Transport Ships are not 'allowed' into shallow water so can't 'land' (or load) anything except at a dock
Easy enough to fix = it's just a new unit with 'small' carry capacity that's 'allowed' into medium and/or shallow water (only)
Heavy Lifter (Transport plane) - the existing transport plane is more like a 'special forces' light lifter
Again, easy enough as a new unit = the build costs, lift capacity and movement ranges of both types will be adjusted to ensure proper 'differentiation'
Gilders / Paratrooper Transport - currently, there is nothing to stop units re-boarding their transport and flying away again :-).
It's possible simulate both units by defining a (pre-loaded) 'Paratroop Transport' unit that has a carry capability but a 'max weight' of 1. The '1 max.' will prevents any units 're-boarding' the craft (the only 'unit' with a weight of 1 is the Anti-Tank missile), and whilst CoMET won't let you load it with units, the Map file can be 'hand (or script) edited' to 'pre-load' the troops. It might also be possible to simulate Gliders by using the 'Events' system to eliminate the 'transport' unit after some 'trigger' (see Events, later)
Artillery tractor - for 'carrying' (towing) heavy artillery
I simulated this by using a 'transport' + 'sweeper' unit (and defining the Artillery as 'type=Mine') This lets you set Artillery Move=0, but can be 'deployed' from their transport into their own allowed Terrain=.
Supply Trucks / Tank Transporter - a way to move resources (crystals) and units (infantry / tanks) at speed along roads
The Max/Min weight limits are used to limit what can be loaded into a Tank Transporter
Combat
There are so many issues here it's hard to know where to start
First there is the units size. '5' presents a problem for 'attrition' as the minimum 'kill' is 20% or nothing. So, for example, when attacking fixed defences such as mines and, especially, 'Pill Boxes', you can bang away with your Artillery to zero effect for the entire game (Artillery does not have enough 'attack strength' to overcome the Pill Box 'armour' and 'kill' 20% of the pill-box).
Ideal we should switch to a '%' approach, however just switching from 5 strength points to 10 might be enough (note - a set of 10 new 'strength' icons would be required)
Next there are the attacking/defending 'bonuses'.
Support 'bonuses' are applied to both attacker and defender = you get +10% from friends supporting you on the flanks, +5% for rear support Whilst this may have made sense prior to the advent of mechanised warfare (when having some-one fighting next to you might spur you on to achieve more), once gunpowder weapons started to dominate the battlefield your gun didn't gain accuracy (nor did your armour increase it's effectiveness) just because others were shooting at the same target (or sitting in the trench next door). What the 'attack bonus' means is that when you are 'near' the enemy (and on the same type of terrain), you must either attack or run-away. Units that try to 'stand and defend' will always die (eventually) unless in (very) advantageous terrain. Whilst this encourages fast 'game play', it's total nonsense.
Removing the 'bonus' will require code changes, however this should be quite easy
Next is the nonsense 'Combat sequence'.
When you attack a single enemy with multiple units, combat is resolved 'one step at a time', in the order you choose to attack. Each attack is resolved in turn with all the other attacking units acting as support. Losses from each combat 'step' are carried forward to the next This is total nonsense = only in Hollywood films do individuals attack one at a time ! In real life the defenders would have to defend against all attackers at the same time. Whilst hidden defenders might get the chance to 'shoot first', we can assume that 'on average' all attacking and defending damage will be 'simultaneous' and for sure not 'one step at a time'. The only exception would be defenders taking damage from a preliminary artillery (or other ranged weapon) support and attackers taking damage from the defenders ranged weapons (or due to crossing mine-fields etc.) What the current approach means is that you need to be very very careful indeed in choosing the attack 'sequence'. Whilst it makes sense to start with your artillery and all other ranged units, you next have to attack with your 'most powerful' unit (and so on down tot he weakest), because losses inflicted on an enemy unit 'early' in an attack sequence can result in it being destroyed by a weak unit attacking last, whilst if that same weak unit attacked first it would itself be destroyed !
Fixing this means rather harder code changes
"Experience". Units gain 'combat experience' from killing the enemy, and this makes a real big difference to their (future) combat effectiveness
The issue is, of course, that whilst it makes sense for Infantry to 'gain effectiveness' as they gain experience in the multitude of tasks they can never be fully trained for, plainly the same can't be said for all unit types. To some extent, Tank crews - and to a lesser extent, Air crew - will also improve with experience, since firing at 'live' targets who fire back can't easily be 'simulated' in training However some units - especially Artillery - can indeed be 'fully trained'. Artillery gunners will have learnt how to load the shells, select the right target co-ordinates and fire their guns. So whilst experience may lead to fewer mistakes 'in the heat of battle' - not that Artillery firing from 6-12 miles behind the lines will be feeling much 'heat' - it's hard to see why they would become 'a lot more effective' just because some of their targets happened to be 'weak' or get caught in 'unsuitable terrain' (or failed to take proper cover) and get hammered. What's more nonsense is that, in Crimson Fields, a unit only gains experience when itself directly inflicts losses on the enemy. In fact, real troops gain effectiveness just from fighting (and surviving) - killing the enemy can be almost irrelevant - which is why Artillery can become fully effective as a result of them training to shell the correct co-ordinates without ever seeing their targets (and even when no enemy happens to be present where the shells land).
Changing the 'experience' system is the hardest thing to do as units have to be 'graded' into those who gain a lot from experience (Infantry), those who gain some (Tank, Air crew) and those who gain essentially nothing (Artillery, all Missile units)
Winning (and loosing)
"Capture the enemy HQ to win" hasn't really worked since 1812 (when Napoleon captured Moscow but then discovered the Russians refused to give up). So it's hard to believe that any 'modern' army would place itself into a situation where the loss of a single building, even their "command and control center", would force them to surrender !!
More typically a battle ends when one side has achieved it's objectives (and the other has no realistic prospect of achieving theirs) or when one or the other side has suffered so many losses that the remaining troops refuse to carry on fighting. Few forces ever 'fight to the death' (Hitler and his insane 'no retreat' orders and the Japanese 'die fighting' ethos excepted), so, when losses reach some critical level, we can expect an army to surrender or, in more modern times, retreat to the next ready prepared defensive position (i.e. 'run away and live to fight another day')
The 'Events' systems allows us to set 'victory points' (in 1% 'steps'), so it is possible to allocate points to each 'objective' (building, hex location) that has to be captured and each 'target' (specific enemy unit) that needs to be destroyed.
It is much harder to implement any sort of 'quit when too many units have been lost' rule
However, in a 'campaign', where units surviving one battle go on to fight in the next, both sides have an incentive to 'quit whilst ahead' (or run before loosing everything). There does, of course, need to be some advantage in 'quitting after winning' and a disadvantage for 'quitting when not loosing' (otherwise the 'winning' side might be tempted to keep fighting until they have wiped out every last enemy unit, or the loosing side might be tempted to quit just to stop the other side from achieving their objectives), however this is way beyond the Events system
The display size
Changing the game window 'display pixels' only changes the 'canvas size' i.e. it will not 'zoom' up the map, so all you get is more of the same size tiles - or, once the whole map is shown, lots of unused/empty black hex space.
To 'zoom up', you can reduce your computer's Display Properties, Settings, Screen resolution. Most maps are relatively small, so I found the 'best' choice was to set my Display to 1280 x 1024, and in Crimson Fields set the Options / Video (width x height) to something smaller (eg 600 x 800) In the CF .ini file, the 'video' width & height pixel counts are used for the 'inner window' (i.e. where actual map tiles are shown). The 'surrounding box' pixels (and 'title bar' etc.) are 'extra'. So if you set the CF 'video' count to the same size as your display, the map tiles will 'overflow' the bottom of your display as the top border etc. 'uses up' some of the space - and this hides the 'info' text for the selected unit !
One of the first things I did after discovering how to recompile Crimson Fields was to 'zoom up' the game by x2. To achieve this it is only necessary to change a few of the 'global definitions' in the source code header files, plus, of course, create new 'x2' sized artwork for the terrain tiles and unit icons (see my next few pages for 'how its done') == see Next