Saturday, September 17, 2022

Mass Combat with Surprise

 It's easy to just have armies with one number (combat strength) and smash them together. A common strategic element is that of "surprise". In Atlantis, a force with higher tactics skill gains one round of attacks with no counter-attack. This is actually pretty devastating, which has led to attempts to scale it back.

GURPS Mass Combat deals with surprise by giving the losing side a penalty to their strategy skill (they are "confused" until they can pass a strategy check). My previous post showed how critical strategy skill is to combat outcome.

I decided to measure the effect of surprise using two simple forces:

  1. Force 1: One unit of medium infantry (TS 3, cost $30k)
  2. Force 2: One unit of light infantry (TS 2, cost $40k)
Force 1 is stronger and cheaper. This is because light infantry have the "recon" class, which allows them to participate in the surprise calculation.

Because force 1 has zero recon, they effectively never have surprise. Force 2 will gain surprise about 60% of the time (it's random based on a quick contest of skill including strategy and intelligence gathering - 40% of the time there is no surprise).


As-is, the recon boost is clearly overpriced. Force 1 is winning about 99% of the time. Using a scaled sum, force 1 takes about $23k damage, and force 2 loses almost $40k.

I'll wait to try and balance costs until I run some more mixed force battles.

This graph shows the damage from surprise better. There is a slight shift upward in damage when surprise is gained. There's also a slight tick up in cases where force 2 can win (with heavy losses).

Or, if we just show cases where force 1 wins (and scale by the total number of battles of each case):


Saturday, March 19, 2022

GURPS Mass Combat

 I am somewhat of a collector of game system rules. There are many cases where I have read rulebooks and never played the game. I have played a little GURPS, but I have read far more rules than I have ever used.

One of these is GURPS Mass Combat. GURPS is oriented towards individual action - each player has one character (PC), and is making the decisions for that character. Mass Combat is for dealing with situations where the PCs get caught up in a larger battle. It is making trade-offs between player decisions and the larger scope of army action.

As I work on a replacement for Atlantis, I wonder if the Mass Combat rules can provide a framework I can use...

I have the basic elements coded. It's interesting that force composition has probably the smallest impact on outcome - every force is reduced to one number ("troop strength"). And the ratio of the two strengths produces a modifier to the leader's strategy skill (outnumbering your opponent 1.5 to 1 gives +1 to strategy).

The biggest driver is your strategy skill. A higher strategy will allow you to dominate your opponent.

One of the nice things about making it a computer program is I can run thousands of battles in a second. I can then look at the statistics to see what is having an impact.

This is the probability distribution using the rules as written (actually, it's missing the position bonus, which will skew the numbers even worse). The forces are equally sized, with equal strategy skill levels, and choosing "simple attack" each round.

The losing force fights until elimination (100% casualties). This graph shows the damage done to the winner. The blue bars are the probability at a particular level, the red is the cumulative percentage.

The red line shows that about 50% of battles will have the winner come away with maybe 60% damage or less. And 80% of battles will give them 85% damage or less.

There is only a 5% chance of mutual annihilation.



I made one change for this graph. The rules include a -1 penalty for each 5% damage. This means that a lucky win early in the battle will cause the battle to skew rapidly toward one side. I simply removed it.

Now we see 50% of battles will result in 90% casualties for the winner. 26.5% of battles will result in mutual annihilation. No battles result with less than 60% casualties for the winner.

The rules also apply a recover of 50% casualties to the winning side. This is probably heartening for PCs who are happy to see their side win and recover - but it would be devastating in a strategy war game. A battle with equal forces could result in the utter annihilation of one side, with the winner taking 30% losses!

More data to come as I add firepower and cavalry...

Thursday, October 04, 2018

An AI for Atlantis

I've been working on an AI for Atlantis for a while now. Finally have something to show for it!





I created a game with four players (all AIs). The nexus has no exits, so there are random jumps out. They are using pretty much the same strategy - find good hexes and ramp them as quickly as possible.

Friday, March 16, 2018

Rust Monster

Ok, so the more I learn about C++, the more horrors I find. I figure, I should give Rust a try.

Here's a simple program:
fn main()
{
   let x = { 2 + 2 };
   let y = { 2 + 2; };
   println!("Hello, world! {:?} {:?}", x, y);
}

% cargo build
% ./target/debug/hello_world
Hello, world! 4 ()
Now, what happened here? Semicolon is a statement separator, so "2+2;" means "two plus two, and null statement". The last statement in a block is the return value, so y gets the null type (called the unit type in Rust, it always has the null value - "()").

Not the friendliest behavior.

A slight change in style helps here:
fn main()
{
   let x = { 2 + 2 };
   let y: i32 = { 2 + 2; };
   println!("Hello, world! {:?} {:?}", x, y);
}
Now we get a compiler error, and a nice one:
% cargo build
   Compiling hello_world v0.1.0 (file:///usr/local/ned/dev/gitned/rust/hello_world)
error[E0308]: mismatched types
 --> src/main.rs:3:16
  |
3 |   let y: i32 = { 2 + 2; };
  |                ^^^^^^^-^^
  |                |      |
  |                |      help: consider removing this semicolon
  |                expected i32, found ()
  |
  = note: expected type `i32`
             found type `()`

error: aborting due to previous error

error: Could not compile `hello_world`.

To learn more, run the command again with --verbose.

I guess the takeaway is to give type definitions as much as possible, particularly when dealing with blocks...

Thursday, February 23, 2017

Atlantis Updates

Lots of changes with little posting!

In the new game, there is a sizable lake region.  The color difference versus ocean was not sufficient to differentiate them.  I've made oceans darker.

I've also gotten complaints about how unexplored territory is shown.  I've settled on this style, which has the underlying color, with a stippling of gray12 drawn on top.

Most of the development has been in order checking.  I now check the first word of all commands to make sure they are real.  I also check the targets of GIVE commands, and some inventory checking (making sure you don't give what you don't have).  I also check that units doing STUDY have enough silver (based on the skill table - the first turn of studying a new skill will not be checked).

I'm also showing the last seen foreign units in hexes without the current data.  I was having trouble remembering what monsters were where, and where I had seen enemy units.

Tuesday, August 09, 2016

The Palace Job

"The Palace Job" (Patrick Weekes) - An interesting blend of fantasy and steampunk / high tech.  Floating islands suspend by crystals which are changed by the sun (some sort of solar panel coupled to contra-grav?).  A golem which mumbles about its programming as it shuts down.

Impressive overall.

Friday, January 08, 2016

Physics of Star Killer Base

If you haven't seen the latest Star Wars ("The Force Awakens", episode 7), stop reading immediately! :)


****spoiler****
****spoiler****
****spoiler****
****spoiler****




Apparently, there has been some griping about the physics of Star Killer Base.

For example, if the planet can't move, and even one shot substantially drains their sun - then you've only got a few shots from your super-weapon (not to mention everyone on the planet will freeze).

Also, if the weapon drains the whole star, then it is really massive overkill (about 12 trillion times according to one site).


There is a much more reasonable explanation!


The photosphere is the region of the Sun which emits visible light.  The key idea is "It [the photosphere] extends into a star's surface until the plasma becomes opaque"

If you strip off the photosphere, then the star will appear opaque i.e. black (at least, until it regenerates).

Ok, so how much energy can you get from the photosphere (we'll assume the Empire, err, First Order, has sufficient tractor beam and shield technology to extract it quickly and safely).


All of my calculations are in a Google Drive spreadsheet.


Final result?  Yes - there's about 1700 times more power than you need to blow up one planet just from fusing the hydrogen in the photosphere into helium (you could get more power by fusing up to iron).


And how rapidly could you fire such a weapon?

I'm not sure of the fluid dynamics, but keep in mind the regions of the photosphere last about 8 minutes (they are upwellings of cooling plasma).  Which implies it might recharge very rapidly indeed!