Hexode basic Game Design

It is about time to speak a little bit about the game itself, right? What makes Hexode different from other existing titles? And what is this going to feel like? I will try my best to highlight the most important points in the game design. Things are still subject to change, of course. But I think it is important to fix some ideas. As the development is getting me closer to something playable, I feel the need to write this down.

General gameplay presentation and game objective

In Hexode, players fight against each other. Each player commands its own fleet of space ships: destroyers, cruisers and dreadnoughts. The battlefield is represented by an hexagonal board. Hexode is turned based but the turns are simultaneous. Basically a turn goes like this:

  • First all players secretly submit their movement orders.
  • Once done, all ships execute their movement and open fire at the same time.

That’s it! Thanks to this simple mechanics, I plan to make the game quite fast paced.

To win, one has to destroy the opposite flagship. Really simple to understand.

HexMapJS

In order to facilitate the process of validating gameplay ideas, I have decided to build myself a tool to test and showcase them. HexMapJs is JavaScript (Angular and EaselJS) based solution that aims to handle hexagonal boards. I plan to make the tool evolve as I continue to work on the main project. The hexmap.js script is also usable as a standalone script and I welcome anyone to reuse it.

HexMapJS is hosted at https://hexode.xyz/hexmapjs. Full code can be downloaded on its dedicated Github page: https://github.com/jglouis/HexMapJS

Movement mechanics

One originality in Hexode is how movement is handled. One key concept when you have an object moving through space is inertia. An object will keep its speed if no force is applied to it. Tokens are representing huge space ships and it seems only natural to have a bigger ship being less maneuverable than a small one. For instance, a dreadnought at full speed would be unable to stop in one turn. Furthermore, according to the inertia principle, it will keep its speed if no action is taken.

To help represent inertia in the game, each token (=space ships) on the hexagonal board has a movement vector. The movement vector is kept unchanged from one turn to another unless a move order is submitted to the ship. A move order is basically a way to define a new vector movement.

A move order has some restriction:

  • The movement vector cannot be longer than the maximum speed of the ship
  • The difference between the old and new vector has to be below the maneuverability value
  • One player may only submit a movement vector to its own ship

Go here to test the movement mechanics.

Combat mechanics

Each ship comes with its set of weaponry. Each weapon has its own arc of fire, which is visually represented on the board itself. directly after movements are resolved, each ship under an arc of fire will take damage based on the weaponry strength. Combat damage are resolved automatically.

Part of the strategy is to catch enemy ships under the arc of fire of your ships. When several arc of fires overlap, their strength is combined. It is thus critical to coordinate your fleet well.

Each ship has a structure and eventually shield values. When under an arc of fire, a ship has to test if the combined strength of all the weapon exceeds its shields. If it is the case, a roll is made on the damage table to see what happened.


2d6 + damage – structure Effect
12+ Destroyed!
10-11 Cannot submit move order
9 Reduce manoeuvrability by 1
8 Reduce structure by 1
7- Minor damages

This will probably need some adjustment but I think that it is a good thing to introduce a bit of randomness…

Weapons comes in different sizes and shapes:

  • Light lances have the best range and good damage but have a narrow arc of fire
  • Macro cannons are short range weapon designed for close fight
  • Missiles are slow but deadly moving objects

Go here to test the “arc of fire” system.

Command mechanics

The flagship is literally the heart and brain of a player’s fleet. Ships need to communicate between them. Each flagship has a limited range of command. Any ship outside of that range cannot receive order.

I have hopes that this mechanic will generate interesting situations and forces the player to think of his fleet as one single organism. There may even be some subtle things like ships equipped with signal repeaters to convey the flagship orders or, on the opposite, having the possibility to jam opponent’s communication.

 

The dev.

Leave a Reply

Your email address will not be published. Required fields are marked *