AI Chapter · Lesson 1

🤖 Why is game AI different from machine learning?

ChatGPT and AlphaZero are both "artificial intelligence" — yet they operate on completely different principles. In game programming, rule-based AI is the clear winner: predictable, debuggable, and writable in minutes.

⏱ 30 min

🎯 Rule-based AI · Decision Making · Game Feel

1The AI spectrum

Type	How it decides	Advantage	Disadvantage	Example
Random	Math.random()	1 line of code	Unpredictable, doesn't feel intelligent	Random move every turn
Rule-based	If-else, weighted decision	Fast, predictable, debuggable	Doesn't learn, designer writes all the rules	Turtle AI, Galactic AI, Castle enemies
Tree-based (BT/FSM)	State machine, decision tree	Complex behaviour, easily extensible	More design work	RPG NPCs, FPS opponents
Machine learning	Neural network, Q-learning	Human-level or better	Millions of training hours, enormous complexity	AlphaGo, OpenAI Five

The game developer's reality

In most commercial games — including AAA titles — rule-based AI is used. Not because developers don't know machine learning, but because rule-based AI is predictable, debuggable, and deliberately beatable. A player doesn't want to play against a perfect AI — they want something fun.

2Core principles of good game AI

✅ WHAT WE WANT

▸ Beatable — but not easy
▸ Makes mistakes sometimes — feels more human
▸ Reacts to player behaviour
▸ Different across difficulty levels
▸ Fast decision (max a few ms/frame)

❌ WHAT WE DON'T WANT

✗ Perfect decision every frame
✗ Sees all game state (cheating)
✗ Instantly reacts to every change
✗ Follows a predictable pattern
✗ Millisecond decision time

Comparing the AI of our three games

Turtle Race — target-selecting AI: which egg is best? Timed decision, intentional error.
Castle Siege — pathfollowing AI: enemies travel a fixed lane in waves, no individual decisions.
Galactic Conquest — strategic AI: territory evaluation, three action types, noise-distorted decisions.

🧠 Why is AI not perfect in most games?

Because developers can't write better AI

Because playing against a perfect AI is frustrating and not fun — mistakes make it feel more human and beatable

Because processors aren't fast enough

Because the rules of the game don't allow it

AI Chapter · Lesson 2

🐢 Weighted Target Selection — Scoring System

The simple "nearest egg" heuristic isn't enough. A real decision system simultaneously weighs proximity, energy needs, obstacles, and risk — in a single score.

⏱ 60 min

🎯 Weighted scoring · heuristics · multi-factor evaluation

1Basic AI vs. weighted AI

🐢 Turtle Race

Let's see the difference between the current simple AI and a weighted decision-maker:

Simple AI — proximity onlyJavaScript

// ❌ SIMPLE: only looks for the nearest egg
G.objects.forEach(o => {
  if (o.type !== 'egg' || o.done) return;
  const sy = o.y + G.scrollY;
  if (sy > AI_Y - 60 && sy < AI_Y + 100) {
    const sc = 90 - Math.abs(o.x - a.x); // distance only!
    if (sc > bestSc) { bestSc = sc; best = o.x; }
  }
});

// Problem: if 2 eggs are equidistant,
// but a seagull is behind one of them — the AI doesn't notice

Weighted AI — multiple factors at onceJavaScript

// ✅ WEIGHTED: proximity + energy + risk together
function scoreTarget(obj, ai) {
  const sy  = obj.y + G.scrollY;
  const dx  = Math.abs(obj.x - ai.x);
  const dy  = Math.abs(sy - AI_Y);

  // 1. PROXIMITY SCORE: closer = better (max 100)
  const distScore = Math.max(0, 100 - dx * 0.8 - dy * 0.3);

  // 2. VALUE SCORE: energy item more important when energy is low
  let valueScore = obj.type === 'egg' ? 50 : 0;
  if (obj.type === 'energy') {
    valueScore = ai.energy < 40 ? 120 : 20; // super valuable at low energy
  }

  // 3. RISK PENALTY: nearby seagull reduces the value
  let riskPenalty = 0;
  G.objects.forEach(threat => {
    if (threat.type !== 'gull' || threat.done) return;
    const gsy = threat.y + G.scrollY;
    const threatDist = Math.hypot(obj.x - threat.x, sy - gsy);
    if (threatDist < 60) riskPenalty += (60 - threatDist); // nearby = penalty
  });

  // Final score: all three factors combined
  return distScore + valueScore - riskPenalty;
}

// Usage — head towards the target with the best score
let bestScore = -Infinity, bestX = W/2;
G.objects.forEach(o => {
  if (o.done) return;
  const sy = o.y + G.scrollY;
  if (sy < AI_Y + 120 && sy > AI_Y - 80) {
    const sc = scoreTarget(o, a);
    if (sc > bestScore) { bestScore = sc; bestX = o.x; }
  }
});

The golden rule of weighting

Different factors have different units ("pixels" vs "energy%") — they need to be normalised (brought to a 0–100 scale) and then weighted. Determining the weights is a playtesting question: try it, feel it, adjust it.

2Complete example: adding surface bonus to the decision score

Adding a surface-based bonusJavaScript

// 4. SURFACE BONUS: if the path to the target is on a good surface
function surfaceBonus(targetX, currentDist) {
  // Check what surface the path toward the target runs through
  const surf = getSurface(G.totalDist + currentDist / 8, G.level);
  return surf === 'road' ? 30 : surf === 'mud' ? -20 : 0;
  // On road: bonus (moves faster)   On mud: penalty (slows down)
}

// Full scoreTarget extended:
function scoreTarget(obj, ai) {
  const sy  = obj.y + G.scrollY;
  const dx  = Math.abs(obj.x - ai.x);

  const distScore   = Math.max(0, 100 - dx * 0.8);
  const valueScore  = obj.type === 'egg' ? 50 :
                       ai.energy < 40  ? 120 : 20;
  const riskPenalty = calcRisk(obj.x, sy);
  const surfBonus   = surfaceBonus(obj.x, dx);

  return distScore + valueScore - riskPenalty + surfBonus;
}

✏️ Task

Build a simple scoring system:

Open turtle_race.html, find the updateAI() function
Extend the sc score: if AI energy < 30%, energy items get a +80 bonus
Add risk: if any seagull is within 50px of the target, deduct 40 points
Watch with F12: console.log(bestScore) — what values appear and when?

🧠 Why do we need to normalise different factors (to a 0–100 scale)?

Because JavaScript can't add numbers greater than 100

Because values with different units (pixel distance, energy%, risk level) can only be meaningfully compared and weighted when brought to the same scale

To make the AI faster

No particular reason, just convention

AI Chapter · Lesson 3

🐢 AI State Machine — When the AI "Feels" Something

A good AI doesn't behave the same way in every situation. When its energy is low, it races after pickups. When it's winning, it's more cautious. When it's jumping, it makes different decisions. That's the state machine.

⏱ 75 min

🎯 FSM · AI states · context-aware behavior

1AI states — FSM design

🏃 HUNTING

Searches for eggs, normal scoring.
Condition: energy > 40%

→

⚡ LOW ENERGY

Only searches for energy items, ignores eggs.
Condition: energy < 40%

→

🛡️ DEFENSIVE

Stays in the middle of the lane, avoids edges.
Condition: lives < 2

turtle_race.html — AI state machine implementationJavaScript

// AI states
const AI_STATES = {
  HUNTING:    'hunting',
  LOW_ENERGY: 'low_energy',
  DEFENSIVE:  'defensive',
};

// The AI has its own state variable
const ai = {
  x: W/2, vx: 0,
  energy: 100, lives: 3,
  state:  AI_STATES.HUNTING,  // starting state
  aiTimer: 0, aiTargetX: W/2,
};

// ─── UPDATE STATE ────────────────────────────────────────────
function updateAIState() {
  if (ai.lives <= 1) {
    ai.state = AI_STATES.DEFENSIVE;  // low lives → defensive
  } else if (ai.energy < 40) {
    ai.state = AI_STATES.LOW_ENERGY; // low energy → chase pickups
  } else {
    ai.state = AI_STATES.HUNTING;    // normal → hunt eggs
  }
}

// ─── AI DECISION BASED ON STATE ─────────────────────────────
function updateAI() {
  updateAIState(); // updated every frame

  ai.aiTimer--;
  if (ai.aiTimer > 0) return; // not decision time yet
  ai.aiTimer = 25 + Math.floor(Math.random() * 40);

  switch (ai.state) {

    case AI_STATES.LOW_ENERGY:
      // Only searches for energy — ignores eggs
      ai.aiTargetX = findBest(['energy'], { energyWeight: 200, distWeight: 1 });
      break;

    case AI_STATES.DEFENSIVE:
      // Stays in the middle — low risk
      ai.aiTargetX = W / 2 + (Math.random() - .5) * 60;
      break;

    case AI_STATES.HUNTING:
    default:
      // Normal scoring — eggs + energy + risk
      ai.aiTargetX = findBest(['egg','energy'], { energyWeight: 60, distWeight: 1 });
      break;
  }
}

// findBest: search among given types, with weights
function findBest(types, weights) {
  let bestSc = -Infinity, bestX = W/2;
  G.objects.forEach(o => {
    if (!types.includes(o.type) || o.done) return;
    const sy = o.y + G.scrollY;
    if (sy < AI_Y + 120 && sy > AI_Y - 80) {
      const sc = scoreTarget(o, ai, weights);
      if (sc > bestSc) { bestSc = sc; bestX = o.x; }
    }
  });
  return bestX + ai.aiErr * TW * .4;
}

Why switch instead of if-else chain?

When there are many states, switch is more readable — each case is an independent "behaviour module". If a new state needs to be added later (e.g. AGGRESSIVE when winning), you only need to add one case block, without touching the rest of the code.

✏️ Task

Add a fourth state: AGGRESSIVE

The AI should be "aggressive" when it leads by 10+ eggs over the player
In aggressive mode: aiTimer should be halved (decides faster)
In aggressive mode: aiErr should be 0 (more accurate targeting)
Debug: console.log(ai.state) at every decision — when does it switch state?

🧠 When does the AI enter LOW_ENERGY state according to our implementation?

When the AI has collected fewer eggs than the player

When the AI's energy value drops below 40%

When the AI has lost fewer than one life

When the AI can't find energy for 5 seconds

AI Chapter · Lesson 4

🎮 AI Difficulty Levels — One AI, Three Behaviours

You don't need to write a separate AI for every difficulty level. By changing a single set of parameters — reaction time, error margin, sight range — the AI can be scaled from easy to very hard.

⏱ 45 min

🎯 difficulty config · parameter tuning · playtesting

1Parameter-based difficulty

Every AI-describing parameter can be influenced by the difficulty level. The key is to keep these parameters in a configuration object, not scattered through the code:

😊 Easy

Reaction time45–85 frames

Error margin (aiErr)±0.5

Sight range80 px

Jump readiness50%

Risk sensitivitylow

😐 Medium

Reaction time25–55 frames

Error margin (aiErr)±0.25

Sight range120 px

Jump readiness80%

Risk sensitivitymedium

😈 Hard

Reaction time8–20 frames

Error margin (aiErr)±0.05

Sight range180 px

Jump readiness98%

Risk sensitivityhigh

AI difficulty config — for Turtle RaceJavaScript

// Config array — each level has its own parameters
const AI_DIFF = [
  { // 0 = EASY
    name:       'Easy',
    timerMin:   45,  timerRnd:  40,  // 45–85 frame decision delay
    errScale:   0.5,               // large error — often misses
    sight:      80,                // only sees items within 80px
    jumpChance: 0.5,              // 50% chance it jumps over rocks
    riskWeight: 0.3,              // doesn't flee seagulls as much
  },
  { // 1 = MEDIUM
    name:       'Medium',
    timerMin:   25,  timerRnd:  30,
    errScale:   0.25,
    sight:      120,
    jumpChance: 0.8,
    riskWeight: 0.7,
  },
  { // 2 = HARD
    name:       'Hard',
    timerMin:   8,   timerRnd:  12,
    errScale:   0.05,
    sight:      180,
    jumpChance: 0.98,
    riskWeight: 1.2,
  },
];

let DIFF = 1; // current difficulty

// Initialising AI based on difficulty
function initAI() {
  const dc = AI_DIFF[DIFF];
  ai.aiErr = (Math.random() - .5) * dc.errScale; // permanent error offset
  ai.aiTimer = dc.timerMin;
}

// In updateAI: decides based on config
function updateAI() {
  const dc = AI_DIFF[DIFF]; // current config
  ai.aiTimer--;
  if (ai.aiTimer > 0) return;
  ai.aiTimer = dc.timerMin + Math.floor(Math.random() * dc.timerRnd);

  // Sight range: on easy, only sees things closer by
  const sightRange = dc.sight;
  G.objects.forEach(o => {
    const sy = o.y + G.scrollY;
    if (sy < AI_Y + sightRange && sy > AI_Y - sightRange/2) {
      // ... scoring ...
    }
  });

  // Jump readiness: on easy, doesn't always jump over rocks
  G.objects.forEach(o => {
    if (o.type !== 'rock') return;
    const sy = o.y + G.scrollY;
    if (sy > AI_Y-60 && sy < AI_Y+20 && Math.abs(o.x-ai.x) < 35) {
      if (Math.random() < dc.jumpChance) { // doesn't always jump!
        ai.jumping = true; ai.jumpT = 0;
      }
    }
  });
}

✏️ Task

Add a difficulty selector button to your game:

Create 3 HTML buttons: "😊 Easy", "😐 Medium", "😈 Hard"
On click, set the DIFF variable (0, 1, or 2)
Call initAI() when difficulty changes
Test: does the behaviour noticeably differ across the three levels?

🧠 What does the `aiErr` value represent in the AI?

How many total mistakes the AI has made

A permanent, random offset by which the AI systematically "drifts" slightly left or right — this makes the movement feel more human

The proportion of AI's incorrect decisions (between 0–1)

The error margin of the decision interval

AI Chapter · Lesson 5

🏰 Castle Siege — Enemy Pathfollowing

Castle Siege enemies don't "think" — they head toward a fixed target in the simplest possible way. This is called linear pathfollowing. Yet it feels interesting, because stone pits, the moat, and speed differences add variety.

⏱ 60 min

🎯 Linear movement · speed scaling · obstacle handling

1Castle Siege enemy movement logic

🏰 Castle Siege

Enemy movement is surprisingly simple: they always travel left (toward the castle), and automatically align their Y position to the centre (MIDY). No pathmap, no obstacle avoidance — yet it's effective.

castle_siege.html — updEnemies() movement logicJavaScript

function updEnemies() {
  for (let i = G.enemies.length-1; i >= 0; i--) {
    const e = G.enemies[i];
    const et = ET[e.ti]; // enemy type (Goblin/Orc/Troll)

    // ─── AT THE CASTLE GATE: ATTACK ─────────────────────────
    if (e.x - et.r <= CW) {  // reached the castle wall
      e.atkCD -= DT;
      if (e.atkCD <= 0) {
        const dmg = Math.round(et.dmg * e.dmM);
        G.castle.hp = Math.max(0, G.castle.hp - dmg);
        e.atkCD = 80;
      }
    }

    // ─── ADVANCING: RIGHT TO LEFT ───────────────────────────
    else {
      const sp = eSpdOf(e); // speed: type × surface modifiers
      e.x -= sp * DT;        // always moves left (toward castle)

      // Y axis: centre alignment — doesn't go straight, pulls toward centre
      const diff = MIDY - e.y;
      e.vy = Math.sign(diff) * Math.min(Math.abs(diff) * .008, .5);
      e.y += e.vy * DT;
      // This creates natural clustering: everyone drifts toward the lane centre
    }
  }
}

// ─── SPEED CALCULATION (SURFACE + OBSTACLES) ───────────────
function eSpdOf(e) {
  const et = ET[e.ti];
  let spd = et.spd * e.spM; // base speed × wave multiplier

  // In stone pit: slows to 35% (if pit is on the level)
  G.pits.forEach(p => {
    if (dist(e.x, e.y, p.x, p.y) < s(52)) spd *= .35;
  });

  // In moat: slows to 70% (level-dependent)
  if (SV.level >= 15 && e.x >= CW && e.x <= CW + MOAT_W) spd *= .7;

  return spd;
}

The secret of the .008 multiplier — spring/rubber band movement

The diff * 0.008 formula creates a "spring" effect: the farther the enemy is from the centre line, the faster it pulls back — but never abruptly, always smoothly. This is spring dampening — used throughout games for movement, camera follow, and AI movement alike.

2Enemy types — different behaviour with the same logic

castle_siege.html — ET (Enemy Types)JavaScript

// One array, three different "AI" behaviours — all using the same movement code!
const ET = [
  // Fast, weak — comes in masses, hard to hit
  { name: 'Goblin', hp: 38,  spd: s(1.3),  dmg: 10, gold: 10, r: s(13), col: '#2e7a2e' },
  // Medium — balanced
  { name: 'Orc',    hp: 100, spd: s(0.75), dmg: 22, gold: 28, r: s(18), col: '#8B4513' },
  // Slow, massive HP — hard to stop with tower cannons
  { name: 'Troll',  hp: 280, spd: s(0.38), dmg: 45, gold: 65, r: s(26), col: '#4a5a2a' },
];

// Wave multipliers (hpM, spM) scale these per level:
// Level 15 Goblin: hp=38×3.5=133, spd=1.3×1.8=2.34
// Same code runs, but the enemy is much stronger

Type	Strategy	Effective counter	Less effective counter
🟢 Goblin	Speed — rushes through before towers fire much	Fast-firing tower, hero	Powerful but slow tower
🟤 Orc	Balanced — not extreme in any way	Any standard tower	—
🟫 Troll	HP tank — absorbs projectiles from towers	High-damage tower, stone pit (slows)	Fast, low-damage tower

✏️ Task

Add a 4th enemy type to Castle Siege:

Create a "Shadow Assassin" type: very fast (spd: 2.5), very low HP (hp: 15), flies over stone pits (not slowed by them)
In the eSpdOf() function add: if e.ti === 3, skip the pit check
Add the new type to a wave in genLevel() (e.g. from level 12 onward)
Test: does the Assassin emerge from the moat faster?

🧠 What does the `Math.sign(diff) * Math.min(Math.abs(diff) * .008, .5)` formula do?

Generates random movement on the Y axis

Implements spring-like centring: a force proportional to the distance from MIDY pulls the enemy back, but at a maximum speed of 0.5

Calculates straight-line movement toward the centre

Normalises the enemy's Y coordinate

AI Chapter · Lesson 6

🌊 Castle Siege — Wave System and Enemy Spawning

Enemies don't all arrive at once — they come in waves, with different compositions per level. The genLevel() function generates all the waves for all 50 levels with a single mathematical formula.

⏱ 60 min

🎯 Wave generation · spawn queue · difficulty scaling

1genLevel() — 50 levels from one function

🏰 Castle Siege

castle_siege.html — genLevel(li)JavaScript

function genLevel(li) {
  // Wave count: 5 for levels 1–14, 7 for 15–21, then up to 20
  const wc = li < 15 ? 5 : li < 21 ? 7 : Math.min(7 + (li-21), 20);

  const waves = [];
  for (let wi = 0; wi < wc; wi++) {

    // HP multiplier: grows 10% per level, 22% per wave
    const hpM = (1 + li * .10) * (1 + wi * .22);
    // Speed multiplier: grows more slowly
    const spM = (1 + li * .05) * (1 + wi * .08);
    // Damage multiplier: square root of HP (doesn't grow as fast)
    const dmM = Math.sqrt(hpM);

    // Enemy count: grows with level and wave
    const base = 3 + Math.floor(li * .6) + Math.floor(wi * 1.5);

    // Groups: new type appears with each level milestone
    const groups = [{ ti: 0, n: base }]; // Goblins always present
    if (li >= 3) groups.push({ ti: 1, n: Math.max(1, Math.floor((li-2) * .4 + wi * .9)) });
    if (li >= 8) groups.push({ ti: 2, n: Math.max(1, Math.floor((li-7) * .22 + wi * .4)) });
    // From level 3: Orcs too // From level 8: Trolls too

    // Spawn interval: gets faster per level (minimum 14 frames)
    const ivl = Math.max(14, 56 - li * .5);

    waves.push({ groups, hpM, spM, dmM, ivl });
  }
  return waves;
}

Procedural difficulty increase — why is it elegant?

Instead of entering data for 50 levels by hand, the maths does it. The 1 + level * 0.10 multiplier means: enemies are 10% stronger every level. At level 50: 1 + 50 * 0.10 = 6.0 — a Goblin's base HP (38) rises to 228. One formula, infinite variety.

2The Spawn Queue — arriving in order

castle_siege.html — wave spawn logicJavaScript

// Starting a new wave
function advWave() {
  G.waveIdx++;
  if (G.waveIdx >= G.waves.length) { lvlDone(); return; }

  G.phase = 'spawning';
  const wd = G.waves[G.waveIdx];

  // 1. Fill the spawn queue with all group members
  G.spawnQ = [];
  wd.groups.forEach(g => {
    for (let i = 0; i < g.n; i++) {
      G.spawnQ.push({ ti: g.ti, hpM: wd.hpM, spM: wd.spM, dmM: wd.dmM });
    }
  });

  // 2. Shuffle — they don't always arrive in the same order
  for (let i = G.spawnQ.length-1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i+1));
    [G.spawnQ[i], G.spawnQ[j]] = [G.spawnQ[j], G.spawnQ[i]]; // swap
  }

  G.spawnT = wd.ivl; // timer until first enemy
}

// Update loop: removes one from the queue every ivl frames
if (G.phase === 'spawning') {
  G.spawnT -= DT;
  if (G.spawnT <= 0) {
    if (G.spawnQ.length > 0) {
      spawnE(G.spawnQ.shift());  // shift = removes the first element
      G.spawnT = G.waves[G.waveIdx].ivl; // restarts the timer
    } else {
      G.phase = 'fighting'; // all spawned → fighting phase
    }
  }
}

Queue data structure — FIFO

The spawn queue is a FIFO (First In, First Out) list: what we put in first comes out first. In JavaScript, an array implements it with push() + shift(). The shift() removes and returns the first element — O(n) slow for large arrays, but here there are at most ~30 elements at a time.

✏️ Task

Modify the wave system:

Find the genLevel() function — what is the wave count on level 10? (wc value)
Add a "Boss" wave at the end of every level: 1 Troll, but with 5× the HP
Implement: for the last wave (wi === wc-1), the groups consist only of one Troll with hpM × 5
Test: can you feel the difference in game difficulty?

🧠 Why do we shuffle the spawn queue (spawnQ) randomly?

Because JavaScript arrays don't maintain order by default

So the order isn't predictable — if it were always Goblin→Orc→Troll, the player would know exactly when the Troll arrives. Randomness makes it unpredictable and more interesting

Because forEach doesn't guarantee ordering

Technical reason: push() doesn't guarantee ordered extraction

AI Chapter · Lesson 7

🚀 Galactic Conquest — Hex-grid AI Basics

In the Galactic Conquest turn-based strategy game, the AI evaluates six neighbouring hexagons each turn and can perform three types of actions: expand, attack, reinforce. Simple rules produce complex strategy.

⏱ 90 min

🎯 hex coordinates · neighbour search · aiTurn()

1The hex-grid coordinate system

🚀 Galactic Conquest

galactic_conquest.html — hex neighboursJavaScript

// Finding the neighbours of a hexagon
// In offset coordinates (not axial), even and odd rows are shifted
function hexNeighbors(col, row) {
  // Hex centre in pixels
  const { x: cx, y: cy } = hexCenter(col, row);
  const nbrs = [];

  // Go through all hexagons — neighbour if close enough
  G.hexes.forEach(h => {
    if (h.col === col && h.row === row) return; // not its own neighbour
    const { x, y } = hexCenter(h.col, h.row);
    const d = Math.hypot(x - cx, y - cy); // Pythagorean distance
    if (d < HEX_R * 2.1) nbrs.push([h.col, h.row]); // closer than 2.1 × radius
  });

  return nbrs; // [[col1,row1], [col2,row2], ...] (usually 6 neighbours)
}

// Getting a neighbour: getHex(col, row)
function getHex(col, row) {
  return G.hexes.find(h => h.col === col && h.row === row);
}

// Helper functions for the AI
function playerHexes() { return G.hexes.filter(h => h.owner === 'p'); }
function aiHexes()     { return G.hexes.filter(h => h.owner === 'a'); }
function totalStr(owner) {
  return G.hexes
    .filter(h => h.owner === owner)
    .reduce((s, h) => s + h.str, 0); // sum of all strength values
}

Why search for neighbours using pixel distance?

For hexagonal grids, axial coordinates (q, r, s) are mathematically more elegant, but pixel distance also works correctly: if two hex centres are closer than 2.1 × radius, they're neighbours. The 2.1 multiplier provides a small tolerance for floating-point rounding errors.

2The AI's turn — building the candidate list

galactic_conquest.html — aiTurn() candidate listJavaScript

function aiTurn() {
  if (G.phase !== 'ai') return;

  // Energy income: based on difficulty
  const dc = DIFF_CFG[DIFF];
  const income = energyIncome('a');
  G.aEnergy = Math.min(G.aEnergy + Math.ceil(income * dc.aiEnergy), 99);

  // 3 actions/turn on easy, 4 on hard
  let actions = 3 + (DIFF === 2 ? 1 : 0);

  for (let act = 0; act < actions; act++) {
    const myHexes = aiHexes();
    if (myHexes.length === 0) break;

    // ─── BUILD CANDIDATE LIST ────────────────────────────────
    let moves = [];

    myHexes.forEach(h => {
      hexNeighbors(h.col, h.row).forEach(([c, r]) => {
        const t = getHex(c, r);
        if (!t) return;

        // Player's hex → ATTACK candidate
        if (t.owner === 'p')
          moves.push({ type: 'attack', from: h, to: t,
            score: t.str + STYPES[t.type].energy }); // weak + valuable = better target

        // Empty hex → EXPAND candidate (if energy available)
        if (t.owner === null && G.aEnergy >= 3)
          moves.push({ type: 'expand', from: h, to: t,
            score: STYPES[t.type].energy + .5 }); // more valuable sector = better
      });

      // Weak owned hex → REINFORCE candidate
      if (h.str < 3 && G.aEnergy >= 5)
        moves.push({ type: 'reinforce', from: h, to: h, score: 2 });
    });

    if (moves.length === 0) break; // no possible moves
    // ... sorting and execution in the next lesson ...
  }
}

The three action types and their scores

attack score = t.str + t.energy — weak (low str) and valuable (high energy) hexes are the best targets.
expand score = t.energy + 0.5 — sectors with higher energy production are more useful.
reinforce score = 2 — fixed value, less important than offensive moves.

✏️ Task

Analyse the Galactic Conquest AI logic:

Open galactic_conquest.html, find the aiTurn() function
Add a console.log: how many candidate moves were there in a given turn?
Change the reinforce score from 2 to 10 — when does the AI reinforce?
Observe 5 AI turns: does it always choose the same action type?

🧠 Why exactly `t.str + STYPES[t.type].energy` as the attack score?

Random — any formula would have worked

Because the AI simultaneously prefers the most valuable and easiest-to-capture hexes: low str is an easy target, high energy is a valuable prize — adding them together gives a good heuristic

Because it's the only mathematically correct evaluation

Technical limitation: other values don't fit in a float

AI Chapter · Lesson 8

🚀 Galactic Conquest — Selecting and Executing the Best Move

The candidate list is ready. Now it needs to be sorted by score, the best one selected, and the battle executed — with a random dice roll. The outcome of battle is never certain.

⏱ 60 min

🎯 sort + noise · combat resolution · action execution

1Sorting and selecting the best move

🚀 Galactic Conquest

galactic_conquest.html — sorting and executionJavaScript

// ─── SORTING: by score + noise ───────────────────────────────
// Noise (randomness) makes it unpredictable — large on easy, small on hard
moves.sort((a, b) => {
  const noise = DIFF === 0 ? .8 : DIFF === 1 ? .3 : .1;
  return (b.score + Math.random() * noise) - (a.score + Math.random() * noise);
});

// Best move: the first element after sorting
const mv = moves[0];

// ─── EXECUTION: depends on action type ──────────────────────
if (mv.type === 'attack') {
  // Combat: AI strength × difficulty bonus + random vs. defender strength + random
  const atk = mv.from.str * dc.aiBonus + Math.ceil(Math.random() * 3);
  const def = mv.to.str + Math.ceil(Math.random() * 2);

  if (atk > def) {
    // VICTORY: takes control
    mv.to.owner = 'a';
    mv.to.str = Math.max(1, mv.from.str - 1); // combat weakens the victor too
    mv.to.flash = 18; // visual feedback
  } else {
    // DEFEAT: the attacking hex is weakened
    mv.from.str = Math.max(1, mv.from.str - 1);
  }

} else if (mv.type === 'expand') {
  // EXPAND: claims empty hex for 3 energy
  G.aEnergy -= 3;
  mv.to.owner = 'a'; mv.to.str = 1;

} else if (mv.type === 'reinforce') {
  // REINFORCE: +2 strength for 5 energy
  G.aEnergy -= 5; mv.from.str += 2;
}

Why doesn't it always execute the best move?

Adding Math.random() * noise to the score means the AI sometimes also picks the 2nd or 3rd best move. On easy (noise=0.8) it picks almost anything, on hard (noise=0.1) it almost always picks the best. This single line is what makes the three difficulty levels truly different.

2The mathematics of combat — why is there always risk?

Combat probability — easy to calculateJavaScript

// AI attacks: str=4, aiBonus=1.4 (hard), random 1–3
// Atk minimum: 4×1.4 + 1 = 6.6  maximum: 4×1.4 + 3 = 8.6

// Defender str=3, random 1–2
// Def minimum: 3+1 = 4  maximum: 3+2 = 5

// Win chance: almost certain (atk min 6.6 > def max 5)
// But! If AI str=1 and defender str=3:
// Atk maximum: 1×1.4 + 3 = 4.4  Def minimum: 3+1 = 4
// → Win chance: ~10% — AI rarely attacks such a hex

// That's why the score = t.str + t.energy heuristic is useful:
// low str → easier to capture → higher score → AI prefers it
const atk = mv.from.str * dc.aiBonus + Math.ceil(Math.random() * 3);
const def = mv.to.str                + Math.ceil(Math.random() * 2);
const win = atk > def; // simple comparison — but never certain due to randomness

✏️ Task

Modify the combat mechanic:

Add a "flanking bonus": if the AI has 2 neighbours adjacent to the target, atk gets +1 bonus
Implement: const flanks = hexNeighbors(mv.to.col, mv.to.row).filter(([c,r]) => getHex(c,r)?.owner === 'a').length
Add: const atk = mv.from.str * dc.aiBonus + Math.ceil(Math.random()*3) + (flanks >= 2 ? 1 : 0)
Watch 10 turns — did the AI become noticeably more aggressive?

🧠 What does adding `Math.random() * noise` to the sort condition achieve?

It speeds up the sorting algorithm

It makes move selection unpredictable: the random noise added to scores means the AI sometimes doesn't pick the best move — on easy the noise is large (nearly random), on hard it's small (nearly optimal)

It normalises scores between 0 and 1

It prevents ties during sorting

AI Chapter · Lesson 9

🎯 Galactic Conquest — Strategic Depth and Fine-tuning Difficulty

The DIFF_CFG array and the noise parameter determine the AI's entire behaviour. But what does "strategic depth" actually mean — and how can the AI be extended with further tactics?

⏱ 60 min

🎯 DIFF_CFG · strategic extension · defensive AI

1DIFF_CFG in detail

🚀 Galactic Conquest

galactic_conquest.html — DIFF_CFGJavaScript

const DIFF_CFG = [
  { name: 'EASY',
    aiBonus:  .8,   // AI combat strength is WEAKER (0.8× multiplier)
    aiEnergy: 1.0, // AI energy income: same as the player
  },
  { name: 'MEDIUM',
    aiBonus:  1.1, // AI is slightly STRONGER (+10%)
    aiEnergy: 1.2, // AI gets 20% more energy per turn
  },
  { name: 'HARD',
    aiBonus:  1.4, // AI is significantly STRONGER (+40%)
    aiEnergy: 1.5, // AI gets 50% more energy — expands faster
  },
];

// On hard, AI can win with medium-strength hexes:
// atk = 3 × 1.4 = 4.2, def max = 4 → nearly certain victory
// On easy str=3 AI: atk max = 3 × 0.8 + 3 = 5.4, def min = 1+1=2 → doesn't always win

Resource advantage vs. skill advantage

The aiEnergy multiplier is the "cheating" method: the AI gets more resources. The aiBonus is the "skill" method: the AI fights more effectively. Good difficulty design combines both in doses — on hard the AI is not only stronger, but also "smarter" (less noise, more resources).

2Extending the AI — defensive strategy

Defensive AI extension — protecting the HQJavaScript

// The current AI doesn't prioritise defending its own HQ
// Extension: if HQ is in danger, reinforcing gets priority

function aiTurnExtended() {
  const dc = DIFF_CFG[DIFF];
  const myHexes = aiHexes();

  // ─── EMERGENCY: is the HQ in danger? ───────────────────
  const hq = myHexes.find(h => h.col === COLS-1 && h.row === ROWS-1);
  if (hq) {
    const hqNeighbors = hexNeighbors(hq.col, hq.row);
    const enemyNearHQ = hqNeighbors.filter(([c,r]) => getHex(c,r)?.owner === 'p').length;
    if (enemyNearHQ > 0 && hq.str < 4 && G.aEnergy >= 5) {
      // HQ in danger: immediately reinforces, before any other move
      G.aEnergy -= 5; hq.str += 2;
      addLog('🤖 AI defends the base!', 'a');
    }
  }

  // ─── EXPANSION PRIORITY: valuable sectors ────────────
  const bestExpand = myHexes
    .flatMap(h => hexNeighbors(h.col, h.row)
      .map(([c,r]) => ({ hex: getHex(c,r), from: h })))
    .filter(m => m.hex?.owner === null && G.aEnergy >= 3)
    .sort((a,b) => STYPES[b.hex.type].energy - STYPES[a.hex.type].energy)[0];
    // Sorted: most valuable empty hex goes first

  if (bestExpand) {
    G.aEnergy -= 3;
    bestExpand.hex.owner = 'a'; bestExpand.hex.str = 1;
  }
}

✏️ Task

Add an "aggressive strategy" to the AI:

If the AI controls >60% of the map, prefer attacking over expanding
Implement: const aiControl = aiHexes().length / G.hexes.length
If aiControl > 0.6, multiply the attack score by 2
Test on hard difficulty: does the AI become more aggressive when winning?

🧠 Why does the AI receive more energy income on hard with the `aiEnergy: 1.5` multiplier?

Because the AI chooses more expansive sector types

This is "resource cheating" — the AI doesn't play completely fair, it gets a bonus the player doesn't have, compensating for the fact that rule-based AI can't actually "think better"

Because on hard the AI controls more sectors at the start

Just cosmetic difference, the real difficulty is the noise parameter

AI Chapter · Lesson 10

📐 AI Design Principles — What Have We Learned?

Three different games, three different AI approaches. How do we generalise these? What do we take with us to the next game?

⏱ 45 min

🎯 AI design patterns · playtesting · generalisation

1Comparing the three AIs

Game	AI type	Decision basis	What makes it interesting?
🐢 Turtle Race	Target-follower + state machine	Weighted scoring, timed decision	aiErr (human-like error), states, difficulty scaling
🏰 Castle Siege	Pathfollower (no individual decisions)	Fixed direction + spring Y-alignment	Type variety, wave system, level scaling
🚀 Galactic Conquest	Strategic evaluator	Candidate list + noise-distorted sort	3 action types, noise level, resource advantage

2Generalisable AI patterns

General AI template — for any gameJavaScript

// ═══ GENERAL AI STRUCTURE ════════════════════════════════

// 1. STATE MACHINE: determine mode
function updateState(ai, world) {
  if (ai.hp < 20)       ai.state = 'fleeing';
  else if (ai.hp > 80)  ai.state = 'aggressive';
  else                   ai.state = 'balanced';
}

// 2. CANDIDATE LIST: gather possible actions
function buildCandidates(ai, world) {
  return world.targets
    .filter(t => isVisible(ai, t))  // within sight range
    .map(t => ({
      target: t,
      score: scoreTarget(ai, t)     // multi-factor score
    }));
}

// 3. DECISION: best candidate + noise
function decide(candidates, difficulty) {
  const noise = [.8, .35, .05][difficulty]; // easy → hard
  candidates.sort((a, b) =>
    (b.score + Math.random()*noise) - (a.score + Math.random()*noise)
  );
  return candidates[0]?.target ?? null;
}

// 4. EXECUTION: timed, not every frame
function updateAI(ai, world) {
  updateState(ai, world);           // state always updates
  ai.timer--;
  if (ai.timer > 0) return;         // decision delay
  ai.timer = 20 + ~~(Math.random()*30);

  const candidates = buildCandidates(ai, world);
  ai.target = decide(candidates, DIFF); // → target determined
  // The actual movement toward the target runs every frame
}

3The 5 golden rules

🎯

1. Always make it beatable

The AI should not win perfectly. aiErr, noise, and jumpChance all serve this — intentional imperfection.

⏱

2. Don't decide every frame

The aiTimer delay simulates human reaction time. Instant decisions feel robotic — a random interval feels more natural.

📊

3. Keep parameters in a config object

Following the DIFF_CFG and AI_DIFF pattern: keep all AI parameters in one place, no scattered magic numbers in the code.

🧪

4. Playtesting is the real debugger

The best AI parameters can't be calculated — they need to be tried. One session of play reveals whether the AI is boring or frustrating.

🧩

5. Simple rules, complex behaviour

Galactic's 30 lines produce three strategic styles. The Turtle AI's 20 lines simulate human error. The most convincing AI systems are built from simple principles.

✏️ Summary Task

Design your own AI for a simple Pong clone:

The AI paddle follows the ball's Y position — but slowly (spring dampening: diff * 0.05)
Add aiErr: the paddle systematically aims slightly higher or lower
Implement 3 difficulty levels: easy paddle is slower (diff*0.02), hard is faster (diff*0.12)
Add state: if the ball is approaching, "aggressive" mode (faster); if moving away, "idle" (slow return to centre)

🧠 Which is the most effective method for increasing AI difficulty?

Writing completely different AI logic for each level

Reducing the AI's reaction time to zero

Combining parameters: reaction time, error margin, sight range, resource bonus all at once — kept in the DIFF_CFG object so it's modifiable in one place

Letting the AI choose the optimal move every turn (minimax algorithm)

← Back

Phase 4 — Dissecting Games

Home →

Course Overview

🤖 Why is game AI different from machine learning?

1The AI spectrum

2Core principles of good game AI

🧠 Why is AI not perfect in most games?

🐢 Weighted Target Selection — Scoring System

1Basic AI vs. weighted AI

2Complete example: adding surface bonus to the decision score

🧠 Why do we need to normalise different factors (to a 0–100 scale)?

🐢 AI State Machine — When the AI "Feels" Something

1AI states — FSM design

🧠 When does the AI enter LOW_ENERGY state according to our implementation?

🎮 AI Difficulty Levels — One AI, Three Behaviours

1Parameter-based difficulty

🧠 What does the aiErr value represent in the AI?

🏰 Castle Siege — Enemy Pathfollowing

1Castle Siege enemy movement logic

2Enemy types — different behaviour with the same logic

🧠 What does the Math.sign(diff) * Math.min(Math.abs(diff) * .008, .5) formula do?

🌊 Castle Siege — Wave System and Enemy Spawning

1genLevel() — 50 levels from one function

2The Spawn Queue — arriving in order

🧠 Why do we shuffle the spawn queue (spawnQ) randomly?

🚀 Galactic Conquest — Hex-grid AI Basics

1The hex-grid coordinate system

2The AI's turn — building the candidate list

🧠 Why exactly t.str + STYPES[t.type].energy as the attack score?

🚀 Galactic Conquest — Selecting and Executing the Best Move

1Sorting and selecting the best move

2The mathematics of combat — why is there always risk?

🧠 What does adding Math.random() * noise to the sort condition achieve?

🎯 Galactic Conquest — Strategic Depth and Fine-tuning Difficulty

1DIFF_CFG in detail

2Extending the AI — defensive strategy

🧠 Why does the AI receive more energy income on hard with the aiEnergy: 1.5 multiplier?

📐 AI Design Principles — What Have We Learned?

1Comparing the three AIs

2Generalisable AI patterns

3The 5 golden rules

🧠 Which is the most effective method for increasing AI difficulty?

🧠 What does the `aiErr` value represent in the AI?

🧠 What does the `Math.sign(diff) * Math.min(Math.abs(diff) * .008, .5)` formula do?

🧠 Why exactly `t.str + STYPES[t.type].energy` as the attack score?

🧠 What does adding `Math.random() * noise` to the sort condition achieve?

🧠 Why does the AI receive more energy income on hard with the `aiEnergy: 1.5` multiplier?