Proactive Air Defense

Anti-aircraft units are now much better at defending their area, since they get to shoot first–during the enemy’s turn. Things are a bit confusing now, though, because the chain of events isn’t made manifest to the player. If you lose concentration and accidentally move a plane into the range of an hostile anti-aircraft unit you may be surprised to find your unit suddenly half as strong as it used to be. If you’re really unlucky the whole unit may disappear, with no indication of who fired at it.

In short, this change makes animation a requirement, and not just a feature that would be nice to have. I probably won’t take care of that right now, though.

Automatic Reactions

I haven’t completed any new functionality yet, but I’m working on a framework for managing automatic reactions. This is needed by anti-aircraft guns for instance, since they must be able to react immediately to defend their area effectively. Before an attacking plane is allowed to drop any bombs, all air defense units in range will get a chance to shoot it down.

To make this work I need to decouple the request for an action from actually performing the action, so that other units get a chance to intercept. When the user tries to attack an enemy unit, I now send an attack request to an arbiter object running in another (lightweight) thread. The arbiter asks enemy units nearby if they want to counter the action, and schedules the resulting actions. The schedule is then executed and the results broadcasted to everyone who can see them.

These changes not only enable automatic reactions; They also bring me closer to having networked play and fog of war (which refers to the inability to see where all the enemy’s units are).

Crosshairs

Finally, after a lot of internal changes, you can tell if a unit can be attacked by holding the mouse pointer over it. A red crosshair will appear over it until you move the pointer away again. Here is a screenshot:

The mouse pointer doesn’t appear in the screenshot for some reason, but I was holding it over the crosshair. The selected unit is indicated by a sharp border around its hexagon, and the hexes it can move to are highlighted, just like before. The tank isn’t really supposed to be able to cross the strait in one turn, but I haven’t yet bothered to update the terrain graph completely after I made changes to the hex grid.

Another change that can be seen in the screenshot is an anti-aircraft unit, near Copenhagen. I haven’t written any code for it yet though, so it behaves like a tank

To accommodate the crosshair functionality I wrote a simple quadtree implementation which can map mouse clicks to scene graph nodes quickly. The new code is about 700 times faster than the old one, which searched through the entire scene graph including terrain and all. Working at this made me realize a lot of things about scene graphs and how they should interact with other parts, which will probably help when I set out to speed things up later. Currently there’s an annoying lag when you do many things that require updating the window, because I redraw too much stuff.

Progress and Plans

I have improved some more interface details. Now, when you select a unit, the borders of its hex become thicker until the unit is deselected again. Another change is that units now turn in the direction you move them, so a tank that has just been moved from west to east will face east, for instance.

I’ve been thinking about announcing an early preview version of the game on some Internet forums for feedback, and which features should be included in that case. I don’t want to send out a crappy game with a bunch of half-finished features, but I don’t want to wait until everything is perfect either. Right now, I’m leaning towards trying to get something simple out late this summer.

The features I think must be included in the preview are:

• One relatively large and good-looking map, of let’s say Denmark, with shifting terrain etc.
• There must be some visual indication that a unit can be attacked by the currently selected unit. Panzer General put a cross hair around it if I recall correctly.
• Deployment and movement of lots of units must work flawlessly since you will be doing it a lot.
• The bombers must be counterbalanced by for instance air defense units.
• I must either adjust the hex grid to the terrain or the terrain to the hex grid so that it is always clear if a hex is a land or a sea hex, for instance.

That is it, I think. The other stuff either works already or is not essential. I may be forced to include zoom too when I increase the size of the map if it becomes too hard to get an overview of the field.

The preview version probably wont be much fun to play without sound, animations or surprises, but at least I’ll have something to show. There won’t be anyone to play against anyway, since there is no AI and no server You will have to sit next to your opponent.

Bombers can now Bomb

I’m back to hacking on the game again. I’ve made the bombers able to attack and polished some small things, like how units and flags are arranged inside hexagons.

As you can see, the map is also bigger now, and the panel is placed at the top of the window and contains more buttons. The “toggle view mode” button changes between air mode and ground mode, ie which unit is scaled down when an aircraft shares hex with a surface unit. I know the buttons look awful but fixing that can wait.

Aircraft and Unit Stacking

I have been working on adding aircraft units to the game today. Adding airplanes is more work than for other unit types, because aircraft units can be placed on top of other units. That means I have to write code for arranging stacked units in a way that is both pleasing to the eye and lets players refer to individual units within a hexagon unambiguously.

I am not done yet, but it seems to work pretty well now. The screenshot shows German divebombers stacked on top of other units. One of the units is always minimized when two units share the same hex. The unit that is not minimized is the unit that a click on that hex will refer to.

Right now, you cannot select a minimized unit without moving the other unit in that hex somewhere else first, but I plan to make it possible to select the minimized unit simpy by clicking on it. Now mouse clicks are interpreted as referring to hexagons and not to individual units, which worked as long as there was never more than one unit in any hex.

Work left:

• Bombers can not attack other units yet.
• Make it possible to refer to minimized units
• Remove any overlap between units

Battleships

Today I completed support for another unit type–now there are battleships too!

An obvious difference between tanks and ships is the type of hexes they can move to, but another difference is that ships can fire at enemies farther away. So now all units have a range field that controls how far they can shoot. The ship in the middle of the screenshot has a range of two, which makes it able to attack the tank to the right of it.

I have done a lot of refactoring in the Scheme part of the code lately. I’m turning more and more towards an object-oriented style because it fits many of the problems in the game like a glove, but I still use a functional style where it is appropriate.

There are still some problems left. For instance, if a ship attacks a tank two hexes away, the tank is able to return the fire and damage the ship even though it is out of the tank’s range. The tank can not initiate a fight with the ship, but it can defend itself at any range.

Next, I want to add some visual indication of which enemies a unit can attack. For instance, a cross hair could appear around an attackable unit when the user moves the mouse pointer over it.

Terrain-Sensitive Movement

I had planned to work more on the game during the Christmas holidays, but I did not start until a few days ago. But I made some clear progress these last few days.

The algorithm that calculates the set of hexagons a unit can reach now takes terrain into account. For instance, crossing a forested hexagon costs more movement points than passing through a hexagon representing farm land.

The screenshot shows the hexagons the blueish tank near the bottom-left corner can move to. The forest hexes at the top were previously reachable.

At first, I thought all I had to do was associate costs with every edge and sum them up as I traversed the graph, but after a while I realized that breadth-first search (which is what I used before) cannot be used  with weighted graphs to solve this problem (unless all edges have the same weight). So I had to throw away the old search code and implement Dijkstra’s algorithm instead. Took me longer than I expected, but now the code is cleaner and handles weighted graphs properly.

I also simplified the rules for how close to an enemy a unit is allowed to move without having to stop. The new rule is simply that you cannot pass through a hex that is adjacent to an enemy unit. That is all that is needed, really. Thanks Peter E. for making a comment that made me realize how pointless the (relative) complexity of the old method was!

Exploring Troop Mobility Algorithms

Today I am very happy I made the effort to set up a development environment that makes explorative programming easy, and that I chose Scheme. It really pays off!

I have been experimenting with the algorithm for finding all hexagons that a unit can reach in one turn, and being able to see the effect of changes to the algorithm immediately–without restarting–makes it possible to work so much faster. You do not just get rid of the compilation time, you also do not have to set up your test case again after each restart, and having an uninterrupted work flow makes it easier to focus on the problem.

The purpose of the changes I made were to make it easier to block the opponent’s path with your troops. Until now, you could squeeze yourself in between enemy tanks, meaning the defender would have to have a completely air-tight front where every unit stood next to another to block your path.

The first screenshot illustrates the change. Previously, the blue tank was able to reach the hexes in the south by passing through the hexes between the enemy tanks. Now it takes half as many units to block the path, since the tank cannot pass through narrow passages that are bordered by enemies.

The second screenshot shows a situation where a tank has been surrounded by a circle of enemies which it cannot leave without a fight.

One of the reasons explorative programming was so useful here was that I was not sure exactly what I wanted when I started. I defined and redefined the problem as I was solving it. What counts as a narrow passage? Should you be able to step into hexes squeezed between enemies, but not pass through them? Should passage through hexes that are placed between the sea and an enemy be blocked too, or just hexes that are placed between two enemies? These questions would have taken much longer to answer had I used C++.

User Interface Improvements

This week I experimented some more with the terrain graphics. I am definitely getting closer to the right look. The map looks much less flat now that there are more color variations, and the forests blend better with the background. Click on the map to view full size.

The red rectangles indicate that a hexagon is an objective, all of which the attacker must conquer before his time runs out; Otherwise the defender wins. The beige rectangle inside each red one will bear the flag of the current owner–that is, the player who last had troops there.

Now there is also a button for ending the current turn, so you do not have to switch to Emacs and run a Scheme function to do that anymore.