Escape Hack (project codename) is a personal game project that I started as a type of ‘self-enforced’ game jam, intending to take a prototype to Develop Brighton to put into the hands of players and other developers and learn from their feedback.
Clear Constraints
When working on a personal project, it can be easy to plan a project that is too big or immediately start creeping scope. To combat this, I gave myself a series of helpful constraints:
- Steam Deck first – so that I can take the game to Develop and give it to people to play on the spot.
- Single player only – so that I do not need to gather groups to play together.
- 5-10 minute core game loop – so that a busy, tired conference-goer can enjoy the game and ‘get it’ as quickly as possible.
Design
Player Goal
The game sees the player trying to escape a dangerous underground facility. They must ascend floor after floor, all while being pursued by a strange artificial creature.
In each room, the player can choose when to raise the tension: they cannot leave until they activate power in the room, but doing so allows the creature to enter the space and hunt them.
Gameplay Verbs
To escape and outsmart their hunter, the player must master the game’s systemic nature by hacking the technology to create new pathways, distract the artificial creature, and ultimately fight back.
As the player progresses, they discover new hacking programs to aid their escape. Eventually, they’ll discover they can evolve and combine these programs to create new ones, further enhancing their abilities.
Light Narrative
The game is set in the SIGIL universe, using the world-building I have done for that project to ground it and provide context.
A goal of the game is to gradually show the player that the threat of the artificial creature is not malicious, but instead comes from its desire to keep you within the facility, perhaps because of its own deeper emotions towards you.
Technical Structure
When working on small and quick projects, I like to focus heavily on code reusability and keep components as small and simple as possible.
Leaning into Unity’s preference for composition helps greatly with this, as it allows you to quickly test new gameplay behaviour by combining small monobehaviours like ‘LEGO bricks’. Breaking down objects into their smallest possible parts also has the bonus of making systemic behaviour easier to implement later on in development.
Contracts between interchangeable components can be handled using UnityEvents rather than Interfaces, which can slow development due to the need to plan class inheritance.
For gameplay objects such as abilities and items, ScriptableObjects prove very useful, allowing for a lightweight ‘content management system’ where names, descriptions, properties, and behaviour can be designed and then utilised by gameplay monobehaviours.
