Devblog 10 : Redesigned Terrain

After much consideration, much frustration, and much time, I have redesigned the terrain system.  Instead of players choosing to raise or lower the ground, now they create “bricks” which can be stacked on top of each other.  These are hollow spaces which can be explored, and enable players to craft as much of the 3D space as possible… battle everywhere!

This has a few benefits compared to the old system, the most important of which being that the line between types of space is blurred.  There’s no distinction between natural or urban terrain.  It’s entirely up to the player, creating the terrain becomes part of their strategy.  And because the space is hollow, this should allow many different tactical opportunities for all players on the map.

I really wanted to make a terrain system inspired by a children’s playground, with lots of places to explore in three dimensions.  I feel like I’m close to delivering that experience, which will be really unique for the RTS genre.

Devblog 9 : New Home! New Ideas!

Some of you may [not] have wondered where I’ve been.  Turns out relocating for a new job soaks up a lot of time and money.  I’ve moved from Edinburgh to Belfast.  I really like Edinburgh, and will miss seeing the baby swans in Inverleith Park grow up.  I disgress.

For now Norn Industries is back in the homeland!  The time away from my project has allowed me the chance to reflect, and I have had some ideas… some ideas which will require a lot of work to realise.  But that’s fine.  When I started this project I was under no illusions that it would be easy or quick.

From the start I have wanted to blend buildings and terrain into one big playground the player has complete control over.  Real time map design becomes part of your strategy.  But I’ve always felt nagged that as my design has evolved, it has stayed too loyal to old RTS paradigms.  The building is now navigable in a way it has never been before, but it’s still just a building.  And that just isn’t innovative enough.  My aspiration feels unsatisfied.

It has been said that you should always discard the first idea that comes to mind.  Lots of other people will likely have the same idea.  The second idea should also be ignored.  Less people will have thought of it, but still quite a few.  The third, fewer still realise.  But fourth or fifth?  That may be interesting.

It feels like I’ve redesigned the terrain and building systems enough already.  This will be the fourth iteration of the terrain system, and perhaps the fifth redesign of the buildings.  But the new idea is definitely the best I’ve had yet for this project, and I’m really excited about trying to make it a reality.  I’m also more than a little tired after three weeks of rapid change.  I’m going to enjoy a long sleep tonight.

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.