Hexmission

Hexmission was developed for the Global Game Jam 2018 game, the player needs to expand across the map by building satalites. The engine used for this game was developed in paralell.

Yesterday, Piers and I gave a talk at our research group meeting about the game we created for Global Game Jam 2018 — Hexmission. The Global Game Jam is a yearly event in which participants attempt to create a game in 48 hours. We take part as part of IGGI, our PhD program. This years theme was, ‘Transmission’. The intro videos this year were flat-out bonkers — I really have no idea what on earth they were thinking.

Anyway, we decided to use the opportunity to develop the engine we are building for CE810 at Essex. Our group used our engine to create a working game we could see what features were missing. We also polished up parts of the engine, which at the start of the Jam were fairly basic. We designed the engine for building turn-based strategy games based on a hexagon grid.

The Game

The hexmission game itself starts showing a reasonably blank screen with the units and a few resources (represented by asteroids) and a few different units. Each team starts with 4 attack drones and a base. Players select the unit they wish to give an order to, then issue the order and then repeat for all other units on their team. The player can choose not to issue an order by pressing the end turn button in the top right.

The objective of hexmission is to destroy the opponent’s units and bases. Entities attack each other by shooting. Units of different types have different health values and units have damage reduction (defence) which can prevent damage being done to the target. Entities move by jumping to a new cell, they don’t pass through intermediate cells. This works fine for the space style games where we can create a fiction to explain it, but it’s also a limitation of the engine — presently we didn’t have time to code a pathfinder capable of navigating obstacles ;P. Each game cell (hex) can only contain one entity (unit or base).

Control Scheme

The screenshot in the above section shows units highlighted with an orange border. The orange border indicates that the entities have not yet been given an order this turn. When the player clicks on one these entities, the cells around the entity are highlighted in one of two colours: blue (movement) or red (attack).

If the player wishes a unit or base to conduct an action there are two ways in which the player can select the action, firstly the most common actions (move and attack) have been folded into a “smart” move option. This means that clicking on a unit, then clicking on an empty cell will move the unit to the cell while clicking on an enemy will cause the unit to attack that enemy. Attack and move options are mutually exclusive — you cannot attack empty cells, and you cannot move into occupied ones.

Additional Actions

The game features some actions which are more ambiguous. It is difficult to tell automatically what the user intended to do based on where they clicked alone. For example, if I click on an empty square am I asking the unit to build a base there or am I asking it to move? To avoid these ambiguities we made the player explicitly select the action from a list.

Everything that happens in the game is exposed as an action, this means that in order to get more of a resource, you need to execute the “get resource” action on your mining base (that you build on top of the asteroids). To avoid repetitive clicking for resource bases, Units or bases can have automated actions. These are actions that will automatically execute if the entity is not given another order. If the entity has multiple actions which can be automatic the first one in the action list is used.

Transmission Range

Bases also have a transmission range, if the player’s units move outside this transmission range, the units will no longer function. Players can extend their range by having their worker units build satellites, which broadcast a small transmission range around them. We, unfortunately, didn’t get the boundary drawn on screen during the game jam, which makes it quite challenging to figure out if you’re going to move out of range. This means the player has to balance using their units to attempt to destroy the opponents’ units with defending their own bases — as losing their bases will result in their units out of range of their transmissions.

Overall, The game jam went quite well. We’ve now got a working game engine (which I’ll discuss in a future post). I’m pleased with the amount of progress that we made but the UI needs some work. As always, the code for the game is available on our gitlab server. You can find our post on the Global Game Jam site.

Screenshots