Note - CF 0.6.0 is an 'unsanctioned' demonstration of "what's possible" without making huge changes to the source code. It will be removed when the CF code is moved to SourceForge (a 'proper' Open Source repository) and 'taken on' by 'real' programmers :-)
Unfortunately, I've not been able to get my 060 crimson.exe to 'run' on any PC other than the one I recompiled it on. On other PC's (Windows 10), crimson.exe 053 'runs' just fine, but my own build of crimson.exe (060) does not. On first launch, it complains of 'missing' DLL's. These are libgcc_s_dw2-1.dll, Libstdc++-6.dll, SDL.dll, SDL_mixer.dll, SDL_net.dll, and SDL_ttf.dll. However after I placed copies of these in the folder where crimson.exe resides, it 'silently fails' every time I launch it. I'm guessing that (as usual with Windows) I've not found the right version of the dll's needed. If I ever manage to find a working combination, I'll update here (for what it's worth, crimson.exe ran just fine on the Windows XPpro computer which I use to host my MinGW 'build' environment)
You can download the latest Crimson060 dll package here.
What's in Crimson Fields 0.6.0 ?
Crimson 0.5.3 plus the changes mentioned in my previous pages, including :-
My x2 'zoomed' tiles & units
Double size playing field for modern high res. computer displays, plus the "x3 move/speed" modifications (to improve Units movement granularity and fix relative speed of foot, vehicle, rails, ships and aircraft)
The order of Tiles in the 'definitions' file has been changed (and maps modified to match). Some Tiles have been removed, the definition of many changed, and a few dozen extra added.
The CoMET edit window defaults to 1280x1024
If it defaults to something else, find and delete your existing '../My Documents/crimson/cfed.ini' file)
New units
As of Jan 2013, 23 have been added (Landing Craft, Light Anti-Tank Gun, Transport Helicopters, Self-Propelled Guns, AA Missile, Cruise Missile, Engineers, SAM Missile, SAM Site, Rockets, Torpedo, Guided Missile Cruiser, A.S.W. Frigate, Depth Charge mine, Pontoon Bridge, Assault Boat, Pontoon/Boat transport, Coastal Defence battery, beach defences (mined anti-tank traps) & Pillbox (immobile transport)
Additional units 'coming soon' include Attack Hovercraft, Bombs and (parachute drop) Cargo (crystal) container.
Reworked Unit characteristics
Many of the existing units have been modified to carry Missiles. Aircraft move distances have been increased, 'Anti-Aircraft Guns' renamed 'A-A Missile Battery' (and given AA Missiles), Troop Trains given a 'medic' capability, Patrol Boats become Mine Sweepers, the existing 'Mines' become 'Auto-guns', 'Aircraft Carriers' are renamed Assault Carrier and have their carrying capacity adjusted and so on etc. etc.
Reworked standard mission maps
These include some of my new units plus at least 2 new maps to really show them off
What's included in the 060-code_src-gfx-folder.zip package' ?
Only the (complete) '/src' source code and '/gfx' folders.
NOTE. To build, start by unpacking Crimson 0.5.3 tar-gz and then replace the /src and /gfx folders with the 2 folders from the above package.
What's included in the Crimson-060-EXE package' ?
The crimson.exe '060' executable for Windows, plus the double sized default.tiles & default.units (these replace the existing ones found in C:\Program Files\CrimsonFields) and a new Levels 'set' (to replace your existing C:\Program Files\CrimsonFields\levels folder, although you might want to move any 'saved' games before doing so).
What about a WW1 tile and unit set ?
The original WW1 'set' never came with the original icon artwork (.bmp) files. Whilst the unit icons & terrain are undoubtedly embedded in the default.units & default.tiles files, I found no obvious way to extract them.
WW1 Units
With a bit of playing around I managed to deploy all the ww1 units onto a dummy (white tile) terrain background and used this as a basis for a double sized WW1 Unit artwork set
The 2xWW1.zip package contains the ww1 2xWW1.units and matching artwork (2xWW1.bmp) and Unit definitions (2xWW1.usrc) files, which are required if you want to make changes.
WW1 Tiles
I used the ww1 units with my own double sized modified Terrain Tile set (default.tiles from above).The result is 'playable', even if the 'buildings' look well out of place :-)
In you wanted, you could use CoMET to lay out each and every WW1 Terrain Tile (in rows of 24 with suitable 'gaps' between rows) A Screen capture would then produce a BMP file, which could then be modified using a photo edit package (to line up the rows and replace the background with 'transparent') That gets you the tiles.bmp. To create the Tile definitions, you would have to use your own 'best guess'.
What about the Battle Isle maps ?
I have not included bi2cf.exe with 0.6.0 because it will pick up my new unit and tile artwork but still use the old unit & tile ID numbers to do the 'conversion' - and thus it generates total 'nonsense' maps !
Instead I have edited the 'original' BI maps & put them through a 'map tile converter' to create '2x' sized maps. I include them here for play with Crimson 0.6.0.exe
The 3 sets are the original BI maps, 'data disk 1' set, and data disk 2.
NOTE - bi2cf adds an extra comma ',' at the end of each map-raw line. Whilst this does not upset CoMET, it did upset my 'tile-swap' script :-)
What's in the Crimson-060-SRC package ?
The units and tiles 'source' (CFUnits.bmp, default.usrc, CFTiles.bmp, default.tsrc) and all the map 'source' (levels\*.src)
You really only need these if you intend to build Crimson Fields yourself from the C++ source code, as per my previous pages, and want to use my '2x' sized units & tiles (and expanded unit set)
Any playing tips on the new maps ?
When playing against the computer "A.I" you should choose 'player 1' (the FNA) = the new maps have all been designed (and play tested) assuming you make this choice. If you do take player 2, ALWAYS set the 'handicap' option (which will adjust the scenario so that it is at least playable with the AI in the FNA role)
A1. Yes - first watch out for the computer AI's use of missiles ! (typically, it just 'fires' everything on it's first turn)
A2. Hovercraft are no longer the 'all powerful' unit they used to be - carrying capacity has been reduced and they are restricted to shallow water and 'good' ground
A3. Transport Ships can carry units too heavy to be 'unloaded' using Landing Craft - since transport ships are not allowed into shallowwater (and landing craft are not allowed into deepwater) you must plan your routes to suitable loading / unloading / landing craft 'launch' points in advance
Note that docking piers 'count as' both 'shallow water' and 'water' (even though the Tile artwork shows 'shallow water' sea colours)
A4. Landing Craft can be used as Rocket launchers - so check what's on board before 'storming the beaches' on my new map :-)
How do I use Missiles ?
Units with Missile capability are defined as 'transporters' .. and Missiles are just 'normal' air units (with a high 'attack' value and a defence of 1 (a defense of 0 crashes CF)).
Units weights have been adjusted to limit 'what can carry what'. All the existing maps have been modified to incorporate the new unit capabilities, as well as the addition of a couple of new maps to 'show off' the new units
There is no provision for 're-arming' .. once the Missiles have 'been used up', units are back to their basic fighting capability. Some (eg Helicopter Gunships, Ground Attack aircraft) have decent 'secondary' weapons (Gatling gun), others (eg Submarine) have none
The computer 'AI' typically 'fires' every missile it has on 'turn 1'. Preventing this behaviour will require changes to the AI (most likely the 'Artillery' target selection code can be used)
What (else) is next ?
1) Stop the crashes
a) First, crimson.exe allows units with a speed= of (16 + the Tile move= 'entry cost') to 'stop' on top of another unit already in the same hex. And then crashes if the destination does not have 'transport' capability
This should be an easy fix. All that is necessary is to locate the code that collects the 'possible destination' hex's and check if it contains a unit without sufficient transport capability. The module to look for is the one that is checking if the Unit 'is allowed to enter' based on it's terrain permissions and the Tile type. In other words, 'tile occupied' should be treated as 'no type=' (and thus no unit allowed to enter)
b) Second, whist in the .usrc definitions, a Unit can be set to 'armour=0' (and a .units file built without error) the idea being that it is killed on first combat (like an exploding bomb or missile), when a Unit of armour= 0 enters combat, crimson.exe crashes
This should also be easy enough to fix. The most likely problem is a 'divide by zero' somewhere in the combat resolution code. All that is needed is a 'If armour = 0, skip to end (unit dies)'.
c) Third, there is the 'large map / too many Units' lock up
This, unfortunately, is likely harder to fix. The 'most likely' cause is an 'infinite loop'. On my Windows XP computer, the A.I. freezes when called upon to move it's units if the combination of Units and map size exceeds some unknown limits (a small Map of 40x50 is OK with almost any number of Units, a 120x65 (my 'Dieppe' Map) is OK with a couple of hundred units whilst a 110x50 Map with about 600 Units 'locked up') CoMET seems to handle almost any sized map (up to 32k tiles) just fine, as does crimson.exe in Human v Human 'Hot Seat' play mode. On the Dieppe map, it's possible that the 'lock up' problem is caused by deploying large numbers of Units into landing craft (since they can't be 'unloaded' whilst 'at sea' I'm guessing the software does into some 'check every hex in the map' process trying to find somewhere for them to 'land')
2) Improve Combat and Unit 'casualties'
Combat should be more and less 'simultaneous'. What's more, the balance of attacker v defender is too 'balanced'. As a rule of thumb, the attacker should require double the strength of the defender to prevail.
First any ranged fire should be evaluated and defenders casualties deducted. Next, the remaining defenders defensive fire should be evaluated and attackers casualties taken (spread amongst the attacking units). Finally, surviving attackers have their total attack summed up and applied against the defender. Defenders casualties are then taken. This requires much better 'granularity' in the way casualties are accumulated.
Currently a Unit starts with a maximum 'strength' of 5. The minimum 'casualties' it can suffer is '1' or 20%. When the combat sequence is taken into account, it is possible for 5 weak units to die, one after the other, attacking a strong unit, even if the sum of the 5 outweighs the strong units strength
The '20% or nothing' must be fixed. At the very least Units should have a 'strength' of 10. Better would be to start at '100%', even if the 'display' is limited to 1/10ths.
3) Allow for losses when transporting and repairing
The unit's weight is the same, irrespective of losses. A 'unit of tanks' represents at least 5, so each 20% losses will reduce the number by 1. After taking losses, their 'weight' will be less.
Plainly a 'unit of (5) transporters' that can carry one full strength 'unit of (5) tanks' should be capable of carrying two units with 50% losses (one with 3 tanks, one with 2). All that's needed is to adjust the weight 'cost' for losses. NB. since the 'max/min weight' settings are used to control what type of unit can be carried, the undamaged unit weight should continue to be used when deciding what can or can not be carried.
Then there is the 'cost' of repair. This is '5 crystals' irrespective of the original build cost and irrespective of damage. This is obvious nonsense, but should be easy enough to 'fix'
Whilst we are at it, the term 'crystals' really should be replaced. 'Resources' would be better. Moving to a full strength of 10, costs can be 'charged' to the nearest 1/10th (rounded down) For example, Heavy Tanks (fulll build cost price = 30) at 50 to 53% strength would cost 15 to repair (at 54-56% would cost 14, 47-49%, would cost 16). Crystal generation rates would have to be adjusted to compensate for higher use (the max. number of crystals that any building can hold defaults to 1,000 but can be set as high as 10,000, so there is plenty of leeway)
NB. The dialogue box that comes up when you select 'repair' already shows the repair cost in crystal, so this should be an 'easy' fix
4) The A.I. needs a few 'tweaks' :-)
First, to speed up AI 'tweak' testing, there seems no reason why the AI can't be allowed to play both sides :-)
The (human) still has to interact during combat phase of the AI player, so it's only a matter of tracking down the 'computer plays this player' flag A 'quick fix' would be to build a version of crimson.exe specifically for AI v AI play testing.
The A.I. is nothing but a simple 'preferred move' decision system. Each unit is evaluated on it's own. Each units possible moves are determined with each destination given a 'score'. The highest is then chosen.
To change the behaviour, you can change the 'scoring'. Ending in contact with an enemy unit gets a higher score than ending in an empty tile, HOWEVER the priority for Infantry - which can capture the enemy HQ - is to head towards that HQ - but not other enemy (or neutral) buildings. So to 'fix' the problem of the AI failing to 'capture' other enemy (or neutral) buildings, even when there is no 'opposition' within sight and it's Infantry starts a turn or two outside the entrance, all we have to do is extend the HQ score so it applies, to a lessor extent, to all enemy and neutral buildings.
Another problem is the 'traffic jams' caused by moving units in 'unit number' order (the order in which they were originally created).
The 'easy' solution is to change the order in which the units are moved, so that those nearest the enemy (or furthest from their own base) move first.
A 'handicap' should be applied automatically when fighting against the computer AI.
Rather then rely on the human player to set the handicap when playing against the computer, when the human player starts a game, the AI should get it's 'bonus' automatically. The wording could be plainer (it's not obvious what 'Handicap, Player 1' actually means) The easy way would be for some default handicap [event] be added automatically when a new map is created, and then adjusted each time the map is Saved. This could simply 'add' a number of units to each building (P1, P2) as a fraction of the total number of units on the map. Some flag within the [event] would allow the map creator to 'freeze' the [event] to prevent further modification.
The AI has a problem loading units into transports, even when the transport is in the same (remote) Factory as the units it could carry. This is one reason why the AI can never win the Lost Islands map. The other is that it has no concept of moving resources (crystals) from the 'mine' to the Factory
To stop the AI moving units out of a Factory before it has a chance to use a transport unit to carry them, the order in which Units are considered for movement when inside a Factory (or other building) can be changed. Then, only if the unit has not been transported would it rush off on it's own. To stop the transports rushing off empty, especially when Units are being built and would be available to carry 'next turn', a 'leave now threshold' can be set which has to be exceeded by the 'score' which is set by the number of units available to carry. This will mean it waits for more units to be built. It should also be possible to set a 'special case' of transporting 'crystal' from a 'mine' to a 'factory' - and even possible to have empty transports, especially aircraft, treat the mine as a 'priority target'.
If the game is started with units in transports, the AI typically moves those units out of it's transports before moving the transports. It is this behaviour that leads the AI to 'fire all it's missiles' on turn 1.
It's simply not sensible to unload transports without moving them first (if the transports are moved first, the units inside get a 'free move' before they disembark). Since missiles have no 'time to live', they will keep flying until they hit the enemy. So 'fire the lot at the first opportunity' is perhaps a sensible approach. In the 'wish list' (see below) is to implement a time to live (TTL) for missiles. To stop them being 'launched' too early, all that's needed is for to put a 'block' on a TTL missile leaving the transport until it (the missile) is within range of the enemy
The 'best' way to 'kill' an enemy unit is to 'gang up on it'.
This will mean further changes to the AI movement decision process. At the very least, having decided to attack an enemy unit, this must be made a 'more desirable' target for the AI's remaining, not yet moved, units. To avoid units that might have taken part in an attack wandering off elsewhere, it may be necessary to perform multiple passes during the AI move decision phase. For example, first scan all units looking for possible attacks. Rank the attacks (value of the enemy unit, your strength, enemy strength etc) and commit to the most desirable. Then scan all the units again (after taking into account move of the first unit and upping the 'desirability' of the enemy as a target). The move second unit, rescan, and so on. Of course attack is only possible if your unit can get 'next door' to the enemy, so once the AI has sent in it's first unit, there will be one less next door tile available to attack from.
The AI 'build the most expensive it can afford' behaviour at a Factory needs changing
This is somewhat harder to address. First, just like movement, each possible build, and 'no build' can be 'scored'. The highest score is chosen. If that results in a build, the cost is deduced from the AI's crystal store and the build score ran again. This is kept up until the AI has no crystals or the 'build none' choice wins. The secret then, is how to score. For example, building transports has to get a higher priority when units have to be transported to the front.
Protecting it's HQ
With more realistic air moves, the tactic of sending infantry in transport aircraft to grab the enemy HQ in a sneak attack becomes possible. Since 'capture the enemy HQ to win the game' is the standard victory condition, plainly it's vital to protect you HQ from the enemy. But the AI typically rushes everything forward and leaves it's HQ unprotected. You need 100 points to win. So one fix is to reduce the HQ from 100 points. Instead, victory ponts could be spread more evenly around buildings. Again, standard [event] code could be generated by CoMET. The points allocated to each building could be adjusted each time the .lev is Saved (unless some 'freeze' flag is set)
5) Allowing submarines to submerge
The map is repainted between each players turn, so removing the other sides Subs from the screen should be easy enough - Torpedoes, of course, will be 'left in' :-). Automatically 'revealing' a Sub when something 'bumps into it' is a bit harder
'Sonar' is possible by using a ranged anti-ship capability (with attack=1) since the software will reveal the 'valid targets' when you select your unit to fire - depth charges, of course, are defined as a (new) transportable unit (with a move=0) that can be 'deployed'
6) Giving missiles a 'time to live'
Harder, this. One way is to add a new parameter to the definitions file - if not specified, then a Unit has no specific time to live.
Players will typically try to ensure their missiles hit something before they 'die', so the 'time to live' has to be checked after the combat phase. If the armour=0 is fixed, then they will be eliminated at the end of combat. The 'best' place to reduce the time to live (TTL) and eliminate those that have reached zero will be when the map is redrawn for the next player (i.e. the same module that 'submerges' submarines). Of course, the TTL is only reduced for units that are NOT being carried by a transport unit (i.e. not 'fired'). Missiles 'inside' a 'building' (silo) will also need to be skipped.
7) Defending buildings (and transports)
Whilst 'neutral' buildings are 'up for grabs' (we assume the unmanned equipment is being seized), it is plainly nonsense to expect that enemy units inside an enemy owned building should instantly 'change sides'. Further whilst we can't expect units being carried by ships or aircraft to put up much resistance, those in 'Armoured Personnel Carriers' (or any ground unit) when under attack should be expected to fight
Ideally, those inside should fight (and claim a defensive bonus for being inside a building, especially when holding a Pill Box (which comes with an attack bonus) or Bunkers). Factories can be assumed to be manned by civilians, so having them change sides might be acceptable. Further, if an undefended Factory is entered, it's not totally unreasonable to suggest that any demolition charges etc, be found and disarmed and the factory captured intact. However it does seem unreasonable for a defended Factory to be captured intact. Any fighting in and around the buildings would inevitably lead to damage, the longer the fight the more the damage, even if the defenders do not activity sabotage the equipment before being defeated
The problem with allowing units inside APC's etc. to fight is that 'super units' can be built up by 'stacking' multiple units inside the APC. However, at the very least, when a transport is attacked the units inside should automatically disembark (to next door spaces, if the terrain allows)
One compromise would be to allow Infantry (only) to fight by way of counter attack only. So the attacker hits the APC (or Pill Box etc) which uses it's own unit defence. Then the counter attack by the APC attack strength plus that of the Infantry inside is pitted against the combined attackers defence.
Clicking "Next >>" (nav bar, left) will take you to my 'Using {Events} for Bridging etc' page