Resource Conversion

I spent some time converting the graphic resources to the correct format for the graphics device. All the sprites are loaded as textures. For the graphic device the width and height of textures must be a power of 2.

The tasks were:

• Convert sprites to texture sizes
  
• Reduce size of sprite pages
• Add alpha channel to sprite pages
  
• Fix the GUI dependency on textures sizes
• Remove redundant Direct Draw specific sprites

The screen shot shows a soldier colorized according to faction.
My next tasks are:

1. Colorize all player units and buildings according to faction
   
2. Implement mini-map for Direct3D
3. Tie loose ends for play testing (Monster Dens, Units attack enemies on sight)
   

Direct3D

Yet another screen shot of Dragon Siege?

But wait!
I can see through the income - expense scroll!
Yes! indeed you can.
This is one of the free and quite common features available when using 3D hardware to render graphics.

Yesterday I've incorporated Direct3D support for Dragon Siege. The Direct3D details are abstracted behind the graphics subsystem interfaces, so Direct Draw can still be used by simply changing the implementation behind the graphics subsystem interfaces with the Direct Draw abstract factory. However I think the support for Direct Draw will be removed in future. There are no convincing advantages of using Direct Draw over Direct3D.

• Direct3D has a lot of extra features such as rotation, alpha blending and scaling.
  
• The Direct Draw .NET API is deprecated.
  
• Direct3D is a lot faster than Direct Draw since the hardware GPU reliefs the CPU of some processing

OpenGL support will definitely be added in the nearby future.

Using the 3D hardware unlocks a great number of possible features in Dragon Siege. Some of these features were imperative for the progress of the game play in Dragon Siege.
I name but a few:

• Large variety of monster colors and sizes
  
• Proper coloring and identification of player units and buildings
• Semi transparent effects and lighting effects
  
• Use of alpha anti-aliased sprites
  

I'm excited to take on these features!

Parallax Backdrop

In the typical strategy game the top of the map usually ends off unnaturally with plain blackness or an abrupt break in the foreground scenario.

The screen shots of Atu'los online inspired me to end off the top of the map with a parallax backdrop.

I've collected a few suitable panorama scenes for variation and made them tiles.
I know I shouldn't gold plate when there are more important outstanding features, but hey I had to kill an hour or so :)

Double Dragon Deluxe

Here is a screen shot from a game Called "Double Dragon Deluxe" I developed during 2006.
During end of 2005 I gathered a large database of sprite animations from various commercial games. I decided to write a game similar to the famous game Double Dragon. My version of Double Dragon includes graphics from a large variety of fighting games.
Double Dragon Deluxe is also a multiplayer game, where a large number of Players may join. A player may join either as a "Hero" or a "Computer Controller Player". The game will randomly assign control of enemy avatars to computer controller players. This makes the game quite difficult and interesting for the "Hero" players.

Game characters can also wield weapons of different types: sword, baseball bat (as wielded in the screenshot), metal pipe ...

Heroes gain Experience for successful attacks. A hero can use this experience to upgrade attack moves. For example, upgrading the punch attack will increase the speed of punching, add stun effects to the punch move and more damage. Upgraded attack moves have added visual effects.

In the screen shot you will also note some weather effects. The game engine supports area sounds and area weather effects. If a player gets closer to an area marked with these effects, the effects will increase. Such as, rain will start pouring harder, or sound becomes louder.

The game world consists of different areas. Each area consists of 2 dimensional polygon sectors with height attributes. These polygons overlay graphic art tiles as backdrops. Foreground visual tiles can also be added, for example the lamp post in the middle of the screen shot below.
Each sector can have a trigger. A common trigger is a connection between world areas. If a character walks onto a sector just in front of a door the trigger on that sector will transport the character to the world area inside the door. Sectors can also have a type. The ladder is a good example of a sector type. A character in a "ladder" sector will automatically hold onto the "ladder" and climb around if a player issues move commands.

Problems detected with the networking implementation of Double Dragon Deluxe were improved in Dragon Siege.

I will post a download link to the game some time in the future.
See Downloads
See Double Dragon Deluxe Blog

Game Startup

I had some spare time to create a startup page for Dragon Siege. The startup page eliminates the need to edit a game startup configuration file.

The Multi-player testing was a success and the Engine supports the game very well. I can now focus to improve the in-game features.

Game Lobby

I wish I had more time to develop. I was very busy with other things during the past months.
Well finally I managed to distill some time for Dragon Siege out of my life.

The main feature I added is a game lobby.
In the background you will see a local game already running, while the players are in the lobby.
Each player PC runs a local "demo game" in the background while waiting for all the players to join the lobby and the server to start the network game.

I created a local loop back implementation of the networking layer in order to run a "demo game" on each PC. The networking layer was already abstracted so this was quite easy.

I also had to do some refactoring. Initially the entity representing a connected player in the game was the same as the entity representing the Faction (in game group of units usually allocated a particular color). I split these entities in order to make the game state independent of the players connected.

Thus

• a game can run without any players connected,
• multiple players can be assigned to a Faction,
  
• players disconnecting does not affect the game state.
  

I plan to implement unexplored features as well: A player that did not join the lobby before the game started may join a game in progress as an observer, or with permission of a current player may gain control of game entities.

It was a nice exercise writing TextboxControl and ButtonControl classes and handling events in the container Form in a similar fashion as working with Windows forms.

Dragon Siege is on the verge of multi-player testing.

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!

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?
  

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

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!

Wanted: The World Controller

Yes it is snowing with the sound of cold wind and a soft tune bringing the right atmosphere.

Before I can create the source of food and cash I must create a customizable system which controls world events such as the change of a seasons. (Your wheat may grow to eventually be harvested for food, or some seasons the horde of monsters may be more aggressive, or it may rain more often in winter...). The technology advances and the game pacing need be controlled. (At which stage does the more difficult monsters besiege your town walls?).

This world events controller need to be highly configurable to cater for a variety of scenarios and game types.

Gibbed!

New Features implemented

- sounds for Units
- the mini-map
- dynamic custom icons displayed per unit
- buildings can be attacked and are selectable
- blood splatters when units are attacked
- units can be gibbed when sustaining massive damage (see small image where a Half-Dragon hits a larger monster)

I'm currently working on the user interactions on Buildings and Units.

Unit Details

I have added the following functionality:

- Some unit properties e.g. Armor, Life, Damage (critical etc), Portrait
- Selection bar at bottom
- Health bars
- Additional units (from Diablo and Baldur's gate)

The features I'm working on next are

- the mini-map and
- dynamic custom icons displayed per unit
- building creation