Devblog 8 : Weapons and Tactics

Players can create expensive and powerful weapons, and these can be picked up by any unit… friend or foe.  So you’ll have to watch out for thieves.  When a unit dies they will drop their weapon, and again it can be picked up by anyone.

Each weapon is a specialist tool which is best used in a specific situation.  It is possible to use these weapons badly.  One weapon has a superior rate of fire, another has superior damage, another shoots projectiles in a high arc like a mortar, and another is a suicide bomb.

Whether the enemy is fielding superior numbers or superior quality, weapons can be created which, if used correctly, can easily destroy the threat.

Devblog 7 : The Lion the Witch and the Stealth Witch Hunter

I may have taken liberties with the word lion… and there’s no wardrobe yet.  But the last part is definitely accurate.  Each unit in the game belongs to a Clade and a Role.  These two terms represent types which have unique strengths and weaknesses.

The most basic Clade is the Amphibian, and the most basic role is the Regular.  If the player chooses to research more advanced technology they will unlock more Clades and Roles.  Advanced Clades include Mammal, Reptile, and Bird.  Eventually, when I can afford something better than programmer art, the units will looks like robot Egyptian gods; humanoid with animal heads.

Unlocking all basic Roles allows the creation of Regulars, Counters, and Guards.  Counters specialise in defeating their own Clade, but not much else.  Guards invert their Clade’s normal strengths and weaknesses, but not much else.

Advanced unit Roles include Armour, Witch, and Stealth.  These are powerful specialists who excel at specific combat roles.  Armour are very strong, and can absorb a lot of damage from basic unit types.  Witches are fragile, but they can steal enemy units.  Stealth become invisible while they’re not attacking, and deal a lot of damage to witches.

For most units one Armour is an intimidating threat, but the biggest threat to any Armour is one Witch.  Witches can be easily killed by a mob of basic units which would otherwise be destroyed by Armour.  Stealth are the best witch hunters in the game, and can provide invaluable intelligence on the enemy given their invisibility.

 

Devblog 6 : Networking

I wanted my game to be multiplayer from the start.  Easier said than done.  This has made development considerably harder, as networking code is notoriously difficult to implement.  Never mind attempting good networking code.

There were two networking models I considered.  Client-Server or Peer-to-Peer.  They can both be implemented in a variety of ways, but for what I am doing the two options more specifically were an Authoritative Server, or Lockstep.

In a client-server model clients send messages to a server, which does something with them.  In an authoritative client-server more specifically the client only send requests to the server, which makes all the decisions, and then sends orders which the clients must obey.  This design is typical of FPS multiplayer, as it is usually faster.  It sends exact details, like the position of a soldier twenty times a second.

Peer-to-peer models require messages to be sent between all machines involved in a process.  This allows for more precision, but is slower, and harder to get it working properly.  A lockstep system more specifically requires all peers to have exchanged messages with each other, and checked them, before the game is allowed to continue.  Lockstep is a good friend; it will always wait for you.  Authoritative server is a mean girl;  it doesn’t care if you are lagging behind and will not wait.

In the old days all strategy games were lockstep.  This is because it was impossible to rapidly send the exact positions of hundreds of soldiers multiple times every second… given how little data could be transferred over a 56K modem.  Instead peers would send only the commands; select this person, tell them to move there, etc.  But this means that the game must run exactly the same way on every machine, with no tolerance for error.  Implementing a successful lockstep system that doesn’t constantly throw out of sync errors is very hard.

I simply didn’t have the time to do that.  I could however make some sort of authoritarian server.  So I did.  The clients only send player inputs to the server, and the server only sends outputs to the clients.  This clean separation of functionality ensures the server has the final say on every important decision in the game.

There are some exceptions to the rule.  If a player selects soldiers, for example, they expect their user interface to respond immediately.  In cases like this the client is afforded the rare opportunity to send an input and execute its outcome without waiting for the server’s approval.

So far I have implemented networking functionality for almost all of the game’s features.  I have also created a lobby system, allowing players to direct connect to games on their LAN or across the internet.  They can press a button to automatically find any LAN games too.  When in the lobby players can choose their colour, team, and say when they are ready.  Only when all players are ready can the host choose to start the game.  The game waits for all players to load the game scene, then begins play.

 

Devblog 5 : Units

There are four unit types, each with common subtypes.  These types and subtypes have armour and damage bonuses in a rock paper scissors style.  The player has access to as much of this information as possible.  I didn’t want a game which hid information, I wanted it to be obvious so the player can quickly figure things out.

Unit types also have different projectiles.  The most basic unit type’s projectiles simply deal damage to the thing they’ve hit.  More advanced types vary, some deal splash damage, other pass through multiple targets and so deal damage in a straight line, and others pass through everything to only deal damage to the target area.

The player can choose to change their unit’s combat stance.  Aggressive by default, units normally shoot and chase any hostiles they can see.  Defensive units will shoot but not move, and when units are told to Hold Fire they won’t do anything unless they’ve been told.

Units can use their ranged weapon or a melee weapon.  When a unit engages another in melee it forces that target into melee.  This can be useful if you want to deny an enemy unit the use of a powerful ranged weapon.

Players can choose to purchase super weapons, which can be picked up by anyone and enhance the unit’s ranged stats.  If the unit using the weapon dies, it will be dropped and again can be picked up by anyone.

Devblog 4 : Forts

Instead of building a base, players create forts.  Forts are composed of modules, and each module provides the fort with a unique advantage, such as unlocking things to build or increasing construction speeds.  Each fort is independent, and provides its own resources, energy, and technology.  Players can easily choose which floor to interact with by using the mouse wheel.

Players can expand an existing fort, or build a new fort.  New modules extend the fort.  New forts can only be created by first making a building block.  This can then be picked up by a unit, and deployed somewhere else.  Be careful!  Enemies can steal unguarded building blocks.

Forts and modules cannot be destroyed.  They must be captured or disabled.  Bringing a unit to a hostile fort’s console will initiate a shutdown timer.  When this timer expires the module will not be able to be used by anyone.  To reboot the module, a friendly unit has to be brought to the console.

Devblog 3 : Terrain Mode

Terrain Mode is an important and unique part of the design.  The player can purchase tiles in real-time, which modify the map.  How you build it is up to you, terrain building is an integral part of your strategy.  You can create ramps leading up or down, walls, and special tiles which do things like slowing down movement or obstructing vision.

The player is forbidden from making inaccessible terrain, and can easily “paint” many tiles by holding down the left mouse button.  If you make a loop it will autofill the interior.  Players are restricted to modifying terrain on their part of the map.

The system is quick and easy to use, allowing the player to toggle between normal and terrain modes by clicking the middle mouse button, as well as rotating ramps using the middle mouse button.

 

Devblog 2 : More Updates?

It has been a while since the first blog entry!  I’ve been busy with personal stuff and development.  But don’t worry, there will be more blogging from now on.  Part of the reason for this is that a lot of work has had to be done to overhaul core systems, which is unfortunately very technical and not particularly visual.  Programmers; especially games developers, often rush to get something done, and in doing so don’t often create the most wonderful code ever first time.

I’ve been working on networking, units, modules, UI, and terrain systems, making sure the code behind the scenes is as good as it can be.  This will help speed up development in future. Networking code has been by far the most difficult challenge, and there will be more on that later.

Next time I’ll be demonstrating the terrain system, which allows players to create the map as they play the game.