Hannibal, named after the general, is a personal project that I’ve been working on a semi-regularly basis. Everything in this game was made by me except for the sounds and character animations. In Hannibal, you control a team of mercenaries, tasked with infiltrating a base (stealthy or otherwise).
In this post, I’ll go over the demo level that I’ve build to test the game on a convention floor. The objective of the demo is to obtain research data and escape with it.
The Demo level – Playthrough & Testing results
The start of the demo level
Hannibal is a tactical game from an isometric perspective which features both melee and ranged combat. The goal of Hannibal is to obtain a cache of intelligence data while either avoiding or defeating enemy units present in the levels.
The player controls a number of units, of which the controls are likely unknown to a beginning player. The controls are similar to an RTS, so to familiarise players with the controls a safe hallway is introduced in which no enemies are present. After the player manages to get a character to move into the second room, a level trigger makes the first enemy walk out into the corridor.
This first enemy is a weakened sword-wielding enemy, which will be unable to significantly threaten the player. There are strategically placed boxes which will generally concentrate the damage of the enemy on only one of the player’s characters. This encounter is designed to introduce the the player to combat.
To date, there has only been one player that lost a character on the first encounter.
In playtesting, about half of the players kite back down the hallway and try to keep distance between their characters and the melee-only enemy. Alternatively, players stand their ground and fight the enemy strait up. This strategy usually results in one of their characters loosing 25% health, in which case the player often discovers and uses one of their characters health pack ability.
To date, there has only been one player that lost a character on the first encounter. The player failed by sending in their characters one-by-one to fight the enemy. After this happened, I reduced the damage of the initial enemy by creating and equipping a special ‘rusty sword’ weapon. This now ensures that all of the player’s characters are able to beat the first enemy one-on-one.
During live testing, I tested two variants of combat. The first is one where the player was able to pause the game at any time to give orders. The second variant was one where the game was slowed overall but pausing was not available. Playtesters preferred the option of pausing but also appreciated the slower movement so both were incorporated in the current design.
The second encounter allows for a stealth approach, bypassing the patrol entirely
In the second section of the map, the player encounters a patrolling set of unaware enemies. The player has 2 choices here, sneak past the enemies or set up an ambush. Players can lose up to 2 characters in this fight. This – by design – does not prevent the player from completing the demo. If they lose the fight entirely (which rarely happens), they can quickly restart the game with F5.
Most players realised that the enemies could be avoided, but chose to set an ambush and pick a fight with the patrol. The main reason provided was that they wanted to experiment with the combat mechanics.
In the third section of the demo, the player reaches the objective
Next, the player reaches the objective. Most players choose to not explore here. When they did, they found three enemies at the end of the corridor. Once the player moves any of their characters into the objective zone, that character obtains the objective item. This gives the character the data pass ability, which will be elaborated upon later. Additionally, an alarm goes off and the camera zooms out to show the level exit.
The alarm goes off, enemy reinforcements stream into the corridor, threatening to cut of the player’s escape
When the player is quick here, they can run back to the end trigger taking only light fire from the chasing enemies. This is also their best chance if they’ve lost any character(s) up to now, in which case they won’t have to avoid the patrol on the way back. Most players aren’t quick though however and need to position their units for a fight.
There are two good positions to take this fight. There is the objective room, where the player can wait for the enemy. And the corridor leading to the objective room, where there is light cover. Although the usefulness of cover is never outright stated (it gives 50% damage reduction), I found that players have a natural tendency to place their characters in cover when its available in a convenient location.
Only the character carrying the data needs to reach the end in order to complete the demo.
On the way back from the objective room, it’s a lot harder to slip past the patrol as they now patrol against your movement. The player will need to take the corridor between the rooms to avoid the patrol. This, along with possible pursuers, make for an exiting dash to the finish.
Only the character carrying the data needs to reach the end in order to complete the demo. If the player loses the character carrying the data during a fight, a glowing trigger spawns on the ground from which the data can be picked up again. Additionally, the data pass ability allows the player to pass the data from one character to another.
Racing to the finish line with only one character left
The game can be played from the zip below:
Controls: Space - (un)pauses the game WASD; middle mouse - move the camera Scroll - zoom camera Left mouse - select / cast ability Right mouse - move / attack 1-3 - character hotkeys L Ctrl - select all characters F5 - restart the game F12 - toggle fullscreen
Game & Level Design
This demo was developed using Game Maker Studio 2, in which the following features were developed by myself:
- Isometric level design, prototyping, and construction
- Barrier placement (doors, cover, enemies)
- Combat encounters (enemy composition, stealth, chasing, initial encounter etc.)
- Level pacing
- Objectives
- Triggers
Coding (GML & HLSL11)
Implementing those features required custom coding, as summarised below:
- Player input
- Movement
- Isometric camera
- Rendering (HLSL11)
- Enemy AI (self learning, heuristic AI)
- Line of sight (GML & HLSL11)
- Pathfinding (optimised A* algorithm)
- Stealth system
- Weapons & Items
- Abilities & Skills
- Animation system
- Procedural level generation
- Data management
- User Interface