Friday, June 22, 2007

Slaughter

What happens if you have a few hundred blood thirsty sword wielding men and a bunch of hungry small dinosaurs? This is the result of one of the performance tests I ran with the improved unit attack code.

I improved the unit attack code to use path finding to direct the unit towards the target.
Moving a unit towards a target for attacking is different than just moving the unit to a specific location. The target may be moving. The requirements are:

- An attacker requires to track its target tightly.
- The attacker should make use of path finding sparingly.
- A target should not be able to outfox an attacker by doing smart maneuvers around obstructions

The improved implementation adheres to these requirements. The attacker has two states:
  • Tracking the target closely (moving directly towards the position of the target)
  • Following a path
If the attacker's movement is impeded while in tracking mode, path finding is done between the attacker and target and the attacker switches to following a path mode. The attacker switches back to tracking mode when it reaches the end of the path.

Now onto some more features!

Sunday, June 17, 2007

A* Implemented

I had a lot of spare time to work this weekend! I've applied the A* algorithm and it works like a charm.

The implementation itself is very easy. I spent more time considering how to integrate path finding with DragonSiege. I made a list of properties that a good implementation of Path Finding should have:
  1. Only one PC must calculate the path for a particular unit.
  2. The processing of Path Finding must be distributed among the PCs.
  3. The server PC must take the responsibility of the path.
I've decided to run the player-initiated Path Finding on client side and dispatch the path the the server. Here is how it works:
  1. The player instructs a units to move
  2. The player PC calculates the path for the unit
  3. The path is sent to the server
  4. The server starts executing the path for the unit by sending movement commands to the clients. The server takes responsibility for the path. (If the path becomes blocked, the server will find an alternative path and communicate this to the clients.)
I fixed quite a few bugs. No broken windows!

I've also implemented semi-transparency for buildings (see screenshot). Whenever a unit is behind a building the building will automatically become semi-transparent. The semi-transparency is a crucial feature. The importance of this feature becomes apparent when critters attack buildings from behind and the building obscures the critters. You hear chewing sounds, but see nothing!
All modern strategy games have this feature.

Well, next up...
  • Monster Dens
  • First shot at game balancing.
  • Game Startup : Player starting points, player lobby?
  • Multi-Player testing : Should work in theory?

Tuesday, June 12, 2007

Fog of War

I added fog of war and the random spawning of monsters from the edges of the map.
The monsters spawning from the edges of the map are easy to kill (only nuisances). They will provide a constant income. (killing monsters provides gold).

Some basic features were added.

  • The income / expense sheet. ( Killing monsters adds to your gold income for the year. And only at the end of the year you acquire this gold. )
  • The mouse cursor now shows the particular action performed when right-clicking. (In the screen shot you may notice the mouse sword icon over the Half-dragon because the Footman will attack the Half-Dragon creature on right-click)
  • The standard strategy game fog of war.
  • Season icon on top right, also displaying the current year number.
  • Simple monster controller. (Monsters pick targets to attack).
A few articles on Path finding:

A* Pathfinding for Beginners
Coordinated Unit Moving
Implementing Coordinated Movement
Smart Moves: Inteligent Pathfinding

Friday, June 1, 2007

Progress Closer to Play

Due to other distractions I took a short break from developing DragonSiege.
But since last week, I'm back in full action.


The world controller controls the progress of seasons, and triggers seasonal events.
  • Growing of farm produce.
  • Triggers yearly consumption of food for each unit
The buildings can be used by clicking on action buttons.
  • Building other buildings
  • Placing units in a production queue
I've also implement tooltips on various gui areas.


The current goal is to implement
  • a particular gameplay system,
  • keep the implementation of the gameplay system contained.
Thereby we have a playable game in a reasonable time, but the implementation is contained and we can swop the gameplay system to accommodate other gameplay systems in future.

The current gameplay system idea is:

The players start with nothing but a Town Hall in an untamed area of wilderness.
A series of monster dens and dungeons are distributed across the wilderness.
The players must tame the wilderness by achieving some objective.
- Conquer all monster dens/dungeons
- Conquer particular monster den/dungeon
The objectives can be expanded at a later stage.
  • Buildings and Units require gold to be constructed/trained
  • Each units require food every year
  • Farms produce food every year
  • Players acquire gold by killing monsters and raiding dungeons.
Players must therefore build farms to support units.
And kill monsters for gold to replace killed units and demolished buildings.

At a later stage I will implement heroes:
  • If a normal unit survives impossible odds (such as single handedly slaying 5 difficult monsters in 1 minute) the unit will be flagged for becoming a hero and the player notified
  • The player can then "recognise" the unit as a hero
  • The hero will then begin acquiring experience to gain levels and abilities.
  • The hero will also require additional gold payable yearly for its services. The player will be able to control the actual gold allocated to the unit.
  • The hero will have a personality and may, refuse to do the commands issued by the player or prematurely run from battle if he is underpaid, or even do damage to allied units (without the intent to kill). A well paid unit may only run from battle if his life is threatened.
  • Only a limited number of heroes will be allowed.
  • Each hero will have a name and a standard voice recording. The player may interact with the hero in some fashion.

I've noticed that Reiner created a mounted knight in March. Graphics for mounted units are quire rare. It is a pity that the mounted knight does not have any attack frames.
It seems that Reiner plans to create attack frames.

I will add the mounted knight as a player unit as soon as attack frames become available.

Next on my agenda:
  • Create monster dens
  • Implement spawning of monsters
  • Implement controllers for monster units.
  • Create gold reward for killing monsters
  • Implement path finding for units
I've implemented a fairly nice path finding algorithm for a previous strategy game before (Siege). Since the very beginning of developing DragonSiege I planned for the later requirement of path finding, so the game implementation lends itself well to implementing a fast path finding algorithm. A nice feature of Dragonsiege is that units push each other out of the way if they collide. (A larger unit will push a smaller unit away and a smaller unit will sidestep a larger unit). The path finding therefore does not have to worry about sidestepping other units.

For those that are interested: the collision detections between units are spacial disjoint. Units only consider other units in its vicinity for collision detection. This allows for a large number of units in the game. (My last test was with 6 000-10 000).
The collision detection also protects the game processing by disabling collision detection for any units more than X number of units appearing in the same vicinity. (Who cares about the collision detection of goblin number 51 if you already have 50 goblins on a pin all pushing and bumping each other for a place to stand)

Anyway, I'm excited to get the first playable version of DragonSiege ready!