Total Conversion -- Combat Shore

[fabi]

I am working on a clone of ASC which is itself a clone of
BattleIsle 2/3.

My current working name for the project is "Combat Shore", suggestions for better names are welcomed.

The default faction of Combat Shore can be discussed there.

Together with the mod itself I hope to get a good solution for Wesnoth supporting conversions being provided by the addon server.

Motivation

I have 4 main points on why doing the mod.

1. KISS
   While BattleIsle 1 can be called a game following the KISS principle this isn't true for its successors anymore. Especially the open source clone ASC has gathered more and more complexity over the time. There are often situations in which I just don't know why something happens because the game mechanism don't allow me to keep the overview.
   Combat Shore will remove everything from its origins which isn't strictly needed for keeping the game style.
2. Randomness
   ASC is a complete deterministic game.
   While I can understand the preferences some people have towards that design decision
   it doesn't suit me very well for myself.
3. Multiplayer
   None of the games mentioned can be played online, you need to rely on play by mail
   (which would be a nice feature for Wesnoth as well).
4. Content
   There is not much content available (mostly campaigns are missing) for ASC.
   I have the hope that the Wesnoth community can help here a little.

Setup

The setup of Combat Shore is that of modern Warfare with some slight references to the past and some futuristic elements as well.
You still rely on battleships and heavy artillery while on the other hand there are plenty of drones,
satellites and futuristic (not that anymore) stuff like stealth submarines.

Comparison Wesnoth - ASC

Wesnoth and ASC/BI have much in common:

• Both are turn based strategy games which play an a hexmap.
• There is a concept of experience in both games, but BI units don't advance to another level. -- AMLA can be used to implement the different concept.
• One unit per hex field (With the exception that BI units can be container or transporter for others)
• Shroud/Fog of War
• Multiplayer with teams (allies/neutrals) - but no multiplayer server for ASC
• Code and art is GPL
• Scenarios are script-able with LUA
• Recall list -- from BI3 support on for transition of experienced units into the next scenario.

The main differences between it and Wesnoth are:

The first 4 are not nice to emulate through lua or wml use, I am working on the c++ support for them.

1. Transportation of units -- Mostly done
2. Units which have a huge sight but a small or no movement -- Stable, ready to commit commited to trunk.
3. Ranged combat (over several hexes distance) -- Not started
4. Different hight levels like deep dived, dived, surface, low flying, high flying, orbit -- I might be able to simplify the gameplay and get rid of this task. Implemented by using [variation]
5. No night/day cycle -- I do not know if I should try to find a use of the time of day system that Wesnoth provides, suggestions are welcome.
6. Ammunition limits -- No work done
7. Fuel limits -- Stable, implemented in wml/lua c++.
8. There is no ZOC in ASC. However, if you move past a unit (and units have several hexes of weapon range sometimes) which has the "reaction fire" ability it gets an attack of opportunity, a little bit like in dungeons and dragons. Thus you can block your supporting units by guarding them by destruction.
   I think this is very hard to emulate, it is to consider if Combat Shore can't just stay with Wesnoth's ZOC system.
9. Buildings -- Those work by defining them as immobile units being transporters
10. No Villages -- Resource management is either done in buildings or by units collecting it on the terrain.
11. No Gold
12. There is a resource system with energy, material and fuel. I have not decided yet how much of it will be ported to CS.
13. Surrounding enemy units gives a combat bonus -- Can be implemented by modifying the backstab weapon special. Nearly every CS unit features it.
14. Jamming -- Every unit and terrain has a jamming ability, that is used to calculate the sight in ASC. While sight can be defined by vision= and the vision_cost features, the jamming would require more intrusive changes to Wesnoth's core. (Or maybe not, do you have an idea?) Current planning involves letting jamming units just apply a modified "Ambush" ability on neighboring units. Implemented in c++.
15. Sonar -- Dived units can only be seen by others having the "Sonar" ability. This might also be doable with "Ambush", still I don't know how to filter for being in vision range of such a unit.
16. Stealth units. -- See Jamming and Sonar.
17. Wheater -- This can be done by changing terrain on the map. ASC defines different terrain values depending on how dry, wet, snowy and what not they are.
18. Wind -- This can influence the hit accuracy especially at longer distances. -- Not planed to be ported.
19. Map format -- ASC maps (or better, the scenarios) are binaries, I have not found a way to convert them yet.

Height Levels

Those come with different movement values. A plane can only be moved an a runway terrain path while on ground level. If there is enough space on a row it can lift off and change its height to low flying. Here it is much faster and can travel through much more terrains, but not huge mountains. Spending some more movement points, maybe the round later it can ascent into higher air and pass even high mountains. Not all air units are able to fly that high. There is also the other way around, a satellite can not decent out of orbit height. Submarines can change their height level as well. They can start docked at a underwater base, ascent to surface and drive into the next harbor. Or they can decent into even deeper water levels, which makes shallow water impassable for them but has other benefits.
While this is indeed a nice feature of the BattleIsle series since the second game, it might be removable without much harm.
Considering that a unit can switch between height levels with a single hex move one can emulate the effects by just assuming that the unit choices the best height possible for the terrain given.
The height levels play an important role for the use of weapons as well.
Submarines when dived deep can only be reached by some weapons (like torpedoes, water bombs) while they can't fire their cruise missiles from there.

Resource System

The only Resource of BI1 is Material which is available at scenario start in the buildings.
Transporters can also collect Aldinium crystals on the map and bring them into buildings were they increase the amount of available material.
While this sounds like the resource system of Command and Conquer the Aldinium crystals were very rare in most levels and the focus of the game was not on the harvesting or base building.
Depending on the type of building the player can spend the material to repair damaged units or build new ones.
Since most buildings were able to produce Aldinium crystals from the stored material, it can be transported between buildings by transport units.

Then BI2 added Fuel and Energy to the available resources.

Battle Isle (3) Resource Mode

The Battle Isle Resource Mode is, as the name suggests,
very similar to Battle Isle: All buildings can generate resources.
The material is only available in the building it was produced in,
while energy is stored in one global pool for all your buildings.
Depending on a map parameter fuel is either handled like material or like energy.
The amount of resources that is produced every turn has be set in the map editor when designing the map.

In contrast to material, energy is needed to keep things going, most buildings and units fail without it.

Fuel and Energy are roughly the same stuff just being available in a different form.
While Energy can be transfered through lines in literaly no time (Electricity travels with one third of light speed) Fuel is much harder to transport, except when you have a pipeline.

While the energy need of vehicles is solved by burning fuel most buildings are not able to transform fuel into energy.
Those buildings need to be connected to a producer.

[taptap]

Early Battle Isle experience is probably what conditioned me to like Wesnoth I didn't play BI3 very much but I felt Battle Isle was deterioriating after BI2 because of too many special effects and OP units while broken core mechanics were not fixed.

I guess what would really shine is if you can fix the broken (in BI, don't know ASC) logistics system, I recall that 2 adjacent supply units could give unlimited supplies at least in BI and BI2. Then supplies would really start to be part of the game.

[fabi]

Early Battle Isle experience is probably what conditioned me to like Wesnoth

Same here, always searched for a turn based strategy game like it, gladly I found Wesnoth, or it found me
It was a perfect match because I also love medieval fantasy settings and RPG stuff.

I didn't play BI3 very much but I felt Battle Isle was deterioriating after BI2 because of too many special effects and OP units while broken core mechanics were not fixed.

Sadly, what you say is too true, BI2 and BI3 are games which have never been really completed. Like many commercial games it was released unpolished and critical bugs remained.

I guess what would really shine is if you can fix the broken (in BI, don't know ASC) logistics system, I recall that 2 adjacent supply units could give unlimited supplies at least in BI and BI2. Then supplies would really start to be part of the game.

ASC features two different resource management modes, one similar to BI3 but fixed and a new even complexer one.
ASC is a pretty game, the first MS-DOS based version is from 1994 thus you can imagine that it is a mature product.
Every BattleIsle fan can be recommended to have a look at ASC especially if he loves complex games and determinism.

I like also to point you to crimson fields which is a well made BI1 open source clone.

Regarding Combat Shore, I like to have an own definition of KISS.
The game mechanics of BattleIsle are too complex to make a similar game which can be called KISS in Wesnoth's context.
But it should be doable to simplify the rules too a degree such that Wesnoth players might still accept the game as manageable.

[fabi]

Some progress:

Most of the vision related issues are ready to test, having support in c++ and on the converted WML front as well.
I have also found a way to translate the weapon damage tables of asc into Wesnoth unit resistance ones,
with the disadvantage of having way too many of them now.

What prevents the faction from being playable is one last issue,
most likely it needs some inventing skills, I see no source for translation in the asc game mechanics.

ASC is deterministic, an attacker's chance to hit is 100%.
The defender gets some sort of resistance bonus for the terrain he stands on, but that doesn't depend on unit type.
Thus I don't see a chance to generate a unit specific defense table.

This leaves some possibilities:
1) Go with the deterministic damage system but find a way to include the terrain specific resistance bonus.
2) Translate the terrain resistance bonus into a generic resistance table not discriminating any unit types.
3) Carefully design some resistance tables, maybe one for each of the ASC vehicle types.

[MetalKing]

I think a totally deterministic Game in a Sense of what Humans understand about may be possible from an Aspect of Physic as the general Property of Reality to be Undeterministic are at MacroLevel normally not relevant BUT for Precision of of collected Data and Precision of Planing and Execution there should be any small Level of Random. But I don't want to start a Discussion pro or con Determinist reps Random but advise to make Influence of Random customizable that a Rifle could change its Precision from "SniperRifle" to "shot around the Corner" to cover all Tastes and Needs for Precision. E.g. a broken Engine could happen unexpected while Operation but at least due to not economic reasonable sufficient collectable and analysable Amount of Data there shoul remain any Kind of Unsureness about if Result of Execution match Planing. Fazit: I don't argue at last for Random or Determinisitc but Support for all. If different Classes for Random exist e.g. for Precision of Guns due to variable WeatherConditions or other Influences that doesn't concerns Reliability of Engines which are more sensible to stabil Production-Conditions etc. However, I don't think its good to build a "highly integrated Engine" you can't adjust any Effect for Things you can't or don't want to determine precisely and thus introduce Unprecision by Emulation by Random. You can't simulate Disease of Cancer at Moleculare-Level but you can emulate it by defining a Likelihood to die by Random due to that Desease.

Brief: Due to you can't know and plan all relevant Things with always sufficient Precisions like Weather is effectivly still not totally deterministic for Humans you have to Deal with Likelihood this or that Way if you want to implement Weather you can't forecast precisely without Unsureness.

Regards, MK

[fabi]

I have made some more progress.

There is now a github repository for CS.
Note that you need to merge it into Wesnoth's data dir.
https://github.com/fendrin/CombatShore

I only test on the latest development version.

There is no content (campaign or mp scenario) yet.
You can start the test scenario "wesnoth path/to/your/data_dir_merge -t" and play a little with the new units.

[fabi]

Again, some progress.
Every single unit of the default faction is now present in the game,
although not every feature they offer is supported yet.

I also managed to lift a simplified implementation of the rotsprite algorithm for rotating the unit artwork.
It is used to produce the 4 missing facings that can't be produced by flipping or by the old limited rotation imagepath function which was only able to rotate in 90 degree steps.
The feature will soon be commited into our repository at github.

Last but not least I have made progress on a prototype which supports transporters.
Mounting units already works like a charm, the unmounting still suffers from lacking gui support.

[fabi]

On a none personal note, there are good news for every BattleIsle fan:

The German company "KING Art Games" finished a successful Kickstarter campaign for a sequel/remake of BattleIsle.

Battle Worlds Kronos

Turn based strategy, made in Germany.
Check it out, I will do so.

[fabi]

Progress update:

1)
Height Levels (deep dived, dived, floating, ground level, low level flight, medium level flight, high level flight, orbit) are now implemented and working by using the [unit_type]'s [variation] feature.
This includes weapons which can only be used from certain levels and/or reach only certain ones.

The c++ engine features added for this:
Support for a default variation in [unit_type].
Support for filtering by a unit's variation id (list of id is supported as well).
Translatable names for [variation].
Some updates to the help browser would be nice, it gets a little crowded now and is not easy to use, but it will be delayed until a first working prototype is ready.

2)
Fuel consumption.

Syntax:
In [unit_type] or [unit]:
fuel_consumption=12 # Moving one hex field consumes 12 fuel. (maybe mileage= is a better name?)
fuel_tank=1200 # The amount of fuel a unit can carry at maximum.

The example values lead to a unit with a range of 100 hex fields.

Support for refueling is on the way.

3)
Cargo

Syntax:

Code: Select all

# the cargo unit:
[unit]
      weight=14 # The weight of the unit
[/unit]

# the transporter unit:
[unit]
      [cargo_bay] # multiple cargo_bays per unit are allowed
            slots=5 # this cargo bay can hold 5 units (optional, if not giving an infinite amount of units can be loaded)
            max_weight=32 # each unit mustn't be heavier than 32 (see the weight attribute in [unit]) (optional) 
            max_total_weight=108 # The sum of all cargo units mustn't be greater than 108 (optional)
            [entrance] # multiple entrances per cargo_bay are allowed
                  in=yes|no         # The entrance can be used to load cargo 
                  out=yes|no       # The entrance can be used to unload cargo
                  docking=yes|no # The entrance can be used to switch into another transporter
                  movement_cost=3 # The (cargo) unit looses 3 movepoints when using this entrance
                  [filter_self]
                        # The transporter must match this unit filter for this entrance to be usable.      
                  [/filter_self]
                  [filter_cargo]
                        # A unit must match this unit filter to mount the transporter
                  [/filter_cargo]
            [/entrance]
      [/cargo_bay]
[/unit]

The gui already supports mounting units, just by moving them on the hex field occupied by the transporter.
Unmount is on the way.

4)
Support for ranged weapons is still missing.
This is the last bigger issue for the conversion to be ready for a first working release.

[fabi]

The height a unit is flying at is now shown by a shadow.
The higher the unit flies, the larger the shadow, but also more transparent and more set off.

Sadly the shadow isn't moving with the unit but jumping afterwards.
Thus I could use some assistance with animation WML.

[fabi]

Sadly the shadow isn't moving with the unit but jumping afterwards.

Managed to solve the problem.

Thus I could use some assistance with animation WML.

This is still true for including some attack/defense effects.

[fabi]

Today I was busy with converting ASC's buildings.

After converting some nice buildings like "Airport", "Small Vehicle Plant", "Depot" and others,
I stumbled upon another one, hidden in a file called "bld_asc_atomkraftwerk.asctxt".

Inside the file the "Name =" attribute (which is, as you easily can guess, the equivalent of Wesnoth's [unit_type]'s name= attribute)
is hold in English language again: "Nuclear Power Plant".

The file is quite short compared to other building's descriptions, only 65 lines at all.
The "Description =" and "Info_txt =" attribute is missing.

The former is quite similar to the WML attribute with the same name, while the later usually provides more detailed informations on the object.
That leads to thinking about why they are missing, wondering if the author simply thought that the name tells enough.

The parent= attribute points to the town base unit (yes, towns are buildings in ASC which can be conquered),
which makes sense at a gameplay point of view.
It's also not that far fetched considering that most of such buildings are placed in urban regions.

Armour = 1000, translated into 1000 hitpoints seems quite much in Wesnoth context, but is a fair amount compared to an heavy tank's 800 and the 10,000 of the quite resistant "Big Headquarter", if you consider that a single hit by an armor breaking weapon like a human carry-able Bazooka leads withe near certainty to a breakdown of the cooling circuit, resulting in similar events to those we could watch in Japan, luckily from a save distance in my case,
even when the hit does not reach the reactor core.

This is true for every nuclear power plant running in Germany, and I guess also for every single one in the world, considering that the German government claims that our plants are the most secure in the world.
Recently watched a documentation about nuclear energy, and guess what, the nuclear facilities in both, France and Sweden, are also the most secure in the world. (Not counting Omicron Persei 08)

The "Functions = matter_converter" means it consumes "material" (one of the three resources in ASC, beside "energy" and "fuel") and produces "energy".
The term could be no more true for any other energy producing facility, as physicist will confirm.

And it is quite an efficient one:
For 1000 fuel and material you receive 10,000 energy, the "material" just vanishes, no need to spend any further thought about it.

There are units in ASC which provide a certain level of damage to their neighboring hex fields when destroyed.
Not so for this one, if it sustains the 1000 points of damage it just disappears into nowhere like most of the other units in the game.

All in all, a quite useful object, beside the relative high costs for building it.

During the conversion process I considered to just keep it out of Combat Shore.
The original BattleIsle series never included it, like any kind of nuclear, chemical or biological weapon.

On the other hand, it could make some nice addition for designing interesting scenarios where you fight for a greater purpose than usual.
But how should the destruction of such a building being handled?

Just making it a defeat condition similar to the loose of a story immanent character seems silly.
"Oh no, we have lost Landar! We can't continue without him."

At the end I just converted the building mechanically, like every other unit.

How to put it onto game mechanics, code the unthinkable but yet not impossible without trivializing the tragedy of the event?

No other unit, being it far more complex than this one took me that long to convert.

Thank you for staying that long with my thoughts.
Also, please excuse the very long and thus hard to read sentences.

I have made the text that long because I didn't had the time to make it any shorter.