Tag: personal

  • Escape Hack [WIP]

    Escape Hack [WIP]

    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.

  • SIGIL

    SIGIL

    In SIGIL, you play as Wavefront Explorers from Tharsis, the newly born and last remaining society of humanity. Equipped with the best technology Wavefront provides and infused with the enigmatic capabilities of sophian matter, you alone can venture out into the beauty and dangers of the planet Nerene, the newly renamed Sapphire Mars.

    Discover half-terraformed geography, delve deep into the ruined mega-city arcoviums of Humanity One, and face the myriad dangers the unknown will throw at you. Do everything you can to uncover the dark secrets of humanity’s past and the grand mysteries of your own cosmic future.

    Time is short, and Tharsis must survive.

    A Hard Sci-Fi, Low-Combat TTRPG

    SIGIL is a hard sci-fi game partly inspired by TV shows such as The Expanse and For All Mankind, and books such as Project Hail Mary. As much as possible within the world is grounded in real science. This is a genre that can be challenging to work on: careful rules have to be established during world-building, and players who are less familiar with the genre need gentle onboarding. However, the payoff is that stories set in this genre have the potential to be very grounded and believable.

    Hard sci-fi stories, especially those set in space, open the door to tension that can arise from physical or technological hazards. SIGIL leans into this by de-emphasising combat and instead focusing on ‘Crisis’ as its core conflict game loop. A Crisis is any time-pressure situation where someone’s safety or the players’ goals are under threat. Through this design, SIGIL tells players it is more concerned with saving conscious beings than killing them.

    Visual Design

    A major factor when designing for a TTRPG is how you present gameplay information. Printed sheets in a TTRPG are the equivalent of video game UI elements. However, they do not have the advantage of being digitally malleable; the player must update the state of the game on paper.

    This means that conveying affordance (function through form) is even more important. The player doesn’t just need to know what a ‘UI element’ is for; they also need to know how to manipulate it. Often, as designers, we have to convey this with very little tactility.

    SIGIL is a work in progress, and with each iteration of the game’s character sheets, I aim to make the onboarding and usability clearer:

    • Stats that use specific dice convey this through the shape of their elements on the sheet.
    • Tracks provide places to mark current and maximum values while still using pips that are readable at a glance.
    • Crucial rules of the game are captured in a lightweight form, right where the player needs them.

    Mechanics

    When working on a game with a lot of complexity in its narrative, world, and overall context, it can add real risk if the mechanics are equally heavyweight. When designers sit down to build ‘hard’ settings, it is possible to get wrapped up in the complexity and detail and transfer that over into lots of nuanced gameplay systems.

    With SIGIL, I wanted to avoid this and keep the game accessible; hard sci-fi does not have to equal simulationist. The core of the game centres around an action resolution system that is fast, while producing frequent, interesting mechanical decisions and tying directly into the problems and threats that the player’s Wavefront Explorer characters are facing.

    This action system is complemented by modular, narrative-driven, lightweight mission and item systems that offer just enough structure to align the table, without burdening them with endlessly checking the index of the source book.

  • The Goblet of Harathorn

    The Goblet of Harathorn

    This project is co-owned and co-designed by James Salisbury and contributed to by many more of my friends. Art on this page has been crafted by James and is often inspired by SketchGoblin‘s illustration style.

    The Goblet of Harathorn (GoH) is a long-running fantasy adventure TTRPG project, currently on its 7th design iteration. The game has been created with the intent of providing a D&D alternative to our friend group and as a delightful hobbyist endeavour.

    Over the years, we’ve drawn inspiration from novels such as Terry Pratchett’s Discworld, Garth Nix’s Old Kingdom series, and Brandon Sanderson’s Mistborn and The Stormlight Archives series, and other media such as the video game Fable, or the TV show Avatar: The Last Airbender.

    At its core, GoH is about playing…

    • …a ragtag assortment of unlikely misfits
    • …who stumble, bicker, and grow into something greater together
    • …to shelter their Community against a looming threat.

    The core game loop is a familiar classic, seeing the players supporting their character’s Community, Adventuring into the Wilds of Ara, and fighting the deadly environment, beasts and foes in the Challenges that the world presents.

    Gameplay & Dice

    Our latest edition uses dice pools of custom d10 dice, with outcomes designed to produce an average of 1 ‘hit’ per die. This creates a very elegant bell curve with the average result equal to the number of dice rolled.

    A die is added to the pool for each different relevant Skill the character has. Each Skill is a tag (akin to the tags of Fate or Legends in the Mist) that describes some aspect of the character. By using tag-like Skills this way, we ensure that every roll is a reflection of a character’s backstory and narrative.

    Characters & Traditions

    Unlike most fantasy TTRPGs, where each player usually chooses a single class to play, all characters in GoH are composed of two ‘Traditions’.

    There are 15 Traditions in total, covering a wide range of possible play styles, from The Tinker’s ability to invent incredible items to The Wake’s gift of summoning and binding souls from The Sorrows.

    The Traditions’ abilities are carefully balanced to ensure that each of them is effective while Adventuring and during Challenges.

    Asking the player to combine two disparate Traditions promotes more novel character design and ensures that the characters at the table stand apart from the typical fantasy tropes.

    Conlang

    For Ara, we have created an ancient language that heavily uses compound words to form new words. The language has added wonderful depth to the setting and the campaigns that have run, providing a sense of history and culture.

    You can see that many world-building elements on this page have their ancient language name.

  • The Winter

    The Winter

    The Winter is a short and simple game about a shaman who must defend his village from an insurmountable foe. A foretold winter brings a demonic comet to the forest, which begins to grow, threatening all those around it. You must use a combination of quick wit and the ability to call upon fiery guardians to save the day.

    The game was made for Ludum Dare 34, a competition to develop a full video game in 48 hours that meets the two themes ‘Growing’ and ‘Two Button Controls’. All of the game’s content was created in that 2-day period, except for a small collection of framework code.

    Style

    From the very beginning of the competition, I knew that I wanted the entire game to feature on a single screen, with the only opponent dominating the player’s view. This kept the game simple but also meant that the player could easily lose the shaman avatar. To avoid this, I made him darker than the snow and gave him a lantern to put him in contrast with his surroundings.

    The effects in this game go a long way to selling the atmosphere. Many small effects were necessary to show the player that the environment is cold and harsh. The character’s footprints impress the depth of the snow and the brightness of the flames, as well as the shadows that extend out from light sources, which help to show warmth and draw the player’s eyes to key elements.

    Combat Design

    As the core element of The Winter, the combat needed to be solid and not frustrating to the player while remaining fresh and interesting as the game progresses. The player is given two key mechanics: the ability to dash anywhere on the map and the ability to plant a seed, which will eventually grow into a guardian and attack the demon.

    Without much space to teach the player the basic gameplay, they are instead given a long warm-up time during which the single enemy in the game is very passive. This allows the player to learn the controls in a safe(-ish) space. Here, they will learn that staying near the totems (an intermediate phase between seed and guardian) will heal and revive them.

    To prevent the player from simply camping near totems, the demon will infrequently use an attack that creates an explosion and damages the ground near the player, encouraging them to learn the dashing technique as a way of avoiding harm.

    This conflict between staying near sources of safety, such as cover and the totems, and remaining on the move to avoid damage is the core element of The Winter’s combat tactics. Towards the end of the game, the demon unleashes a vast wave of power which the player must quickly avoid. As this wave takes up nearly the entire screen, they may be forced to completely abandon locations they previously thought were safe.

    Learnings & Improvements

    For this project, I focused heavily on the art and the VFX to deliver on the atmosphere. I kept the gameplay intentionally very simple and the overall experience very short to allow for a lot of polish. However, this means that the game is quite shallow. If I returned to the project now, I would look for ways to create more verbs using the limited set of inputs.

    I would also improve the tutorialisation of the stamina system, as it proved to be unclear for playtesters. Many did not understand that the stamina bar needed to fill again before a new seed could be planted, and that standing still – or standing in the radius of a totem – would fill the bar faster. Lastly, I would work to improve the conclusion of the game to make the moment of victory feel more satisfying and provide a better lasting impression.

  • AU: Abandon

    AU: Abandon

    AU: Abandon is a game about vast procedurally generated star systems, a desperate search for the resources needed to stay alive and the peace and solitude of space.

    There are two key game dynamics in AU: Abandon. The first is how to traverse the star system and also manage fuel levels. Obtaining fuel (in the form of bright and glowing crystals) also consumes fuel. The player must quickly understand the balance and control required to conserve energy in space.

    The second game dynamic involves an ominous threat. Somewhere in space, unknown to the player, lie creatures waiting to hunt down and consume the player’s ship. They are hidden and will either silently follow the player, remaining out of sight unless the player is observant, or emerge as the player searches for the ever more valuable fuel crystals.

    Procedural Generation

    AU: Abandon’s star system map is generated using procedural algorithms so that each time the player experiences the game, it is slightly different. Each detail of the scene is computed from a selection of simple formulas and is used to define many game parameters, from the shape of the planets and the dimensions of the asteroid belt to the colours of rocks and stars.

    While the procedural generation in AU: Abandon is fairly simple, it does help to maintain the feeling of insecurity when the player is navigating the star system, as they cannot predict the locations of resources and monsters.

    Tool Set

    Most of the development for AU: Abandon used Unity3D and Visual Studio 2012. I programmed the game logic and procedural generation in C#. The game is built upon my own set of Unity3D framework classes that provide a powerful event-based architecture, a hierarchical state machine class for complex state interactions, finer control over physics for game characters and many other useful features. I also employed my own Unity3D-focused unit testing library to help test the procedural generation algorithms.

    Learnings & Improvements

    The focus of this project was to utilise my skills in procedural generation and physics for a game experience. A lot of my time was invested in the technical side of the game, which I believe shines through. However, I also appreciate that there are many areas where the design of the game could be improved.

    If I had continued to work on this project, I would have focused on developing a core objective for the player beyond survival and added more to the world and the gameplay to drive the joy of discovery. I would have also made the onboarding curve of the experience more lenient, as the difficulty can feel quite high for players until they have grasped the fundamentals of 0G movement and fuel management. I would have also explored what music and sound effects I could have added to bring the appropriate atmosphere to the game, as well as continuing to iterate on the art and aesthetics to make it even more appealing.

    A key aspect of game development that I learnt about during this project was optimisation. Procedural games can be very taxing for low-end systems, especially when new procedural elements are being generated. This was the first personal project that I worked on where I had to implement a loading screen to cover the heavy work of generating the entire star system, and I often spent time optimising the particle dust clouds to avoid severe hits to frame rate.