Main responsibilities:

• Valuable prototyping of gameplay mechanics, dialogue system and inventory early on in the project.
• Developed Bystander AI and exposure system.
• Implemented and helped design hidden in plain sight gameplay.
• Developed “leech” type enemy AI from prototype to final version.
• Developed Boss AI for Big Bug, First iteration of “Craig” boss AI and further work on “Yarl” final boss AI.
• Performance optimisation and general bug-fixing.

I joined the project not too long after its start so I have worked through and contributed to the initial vertical slice milestone, through to alpha and the final release.

My initial time was spent prototyping a variety of gameplay mechanics and systems used in the game, some of which underwent further iteration and made it into the published game. I helped added features to the pistol and the magnet gun (that would go on to become the magnet gloves) and made the first iteration of the heal spray. I worked on the initial dialogue system that had branching paths, and a scanner-based mini-game that would allow the player to discover the NPC’s alignment and the correct path through the branching dialogue. Tied to this was the triggering of follow-on behaviour for the AI, such as unlocking a door for the player if they navigate their dialogue correctly. This work was later folded into the Utility AI system as AI Tasks.

After some time working on gameplay mechanics and prototyping, I moved to the AI team and helped build out the newly adopted Utility AI system for our AI which was replacing earlier alternatives that I did help prototype. Along with writing more general code to be used in agent behaviours and considerations, I mostly working on the human bystander AI and a number of bosses in the game, the Big Bug and Craig in particular.

Working closely with design and animation, I expanded the human NPC behaviour that would respond to the player’s actions like using MIB gadgets or weapons, or trespassing where they weren’t supposed to be. This formed a pillar of the game in the form of “hidden in plain sight (HIPS)” gameplay where how well the player keeps their activities from the general public will have an impact on their mission score. If NPCs became suspicious of the player then they would need to have their memory wiped with the franchise’s famous neuralyzer before the player could continue. I helped rework this exposure mechanic and the NPC’s behaviour when they were cautious (Would follow the player making it harder for them to perform their agent duties) to panicked, where NPCs would run away and hide.

I worked on the Leech enemy AI from prototype to final form. This is a special enemy type that can jump at the player and latch on to the player, creating a fun VR interaction of pulling the leeches off and throwing them away. These jump and latch behaviours needed to be coded up to work alongside the standard Utility AI decisions and behaviours set up for the leech.
There were also two other leech variants: The timebomb leech that would start a countdown to explode once latched to the player, and the sleeper leech, a leech that was too large to latch on to the player so would just slam into the player but would start asleep encouraging the player to sneak past else risk waking them up.

For Craig, the giant leech boss, I quickly iterated its behaviour and repositioning as the player moves through the sewer sequence. Working with design, we quickly iterated the introduction and progression through the physical space which has largely remained unchanged.

My proudest work is on the bug boss. A fan favourite of the original film and I really wanted to do it justice in the game. The boss sequence went through a number of iterations but still felt quite lacklustre. With the boss arena being staged in a nightclub I pushed for the boss fight to make use of the environment, and we arrived at a responsive dancefloor that changed to reflect the current state of the boss. A notable feature is the dance floor activating as the bug reveals itself and jumps down from the ceiling. With additional work to codify distinct phases with each new phase providing an escalation in the attacks the Big Bug has become a standout of the game.

Towards the end of the project I was involved in the normal bug-fixing that happens to improve the quality of the game and remove problematic edge cases. I was also involved in optimising the performance of the game. This mostly involved ensuring all meshes that could be culled were included in view volumes and view volumes were properly configured so that it would be possible to cull out all unneeded parts of the levels that were not viewable by the player. This optimisation work also involved using the profiler in editor play mode and with local builds to identify the causes of dips in performance, and then apply fixes whether that be moving vfx/shaders to the bootstrap scene to prewarm them, or to rewrite costly calculations.
Overall, a really enjoyable project where I’ve learnt so much.

I joined the Gang Beasts team when I first started Coatsink. It was a small team where my lead was working on the next-gen port whilst I was handling bugs and other issues.
We had weekly meetings with Boneloaf and managed my tasks using Clickup. Whilst bug-fixing I liased with qa for more information on certain issues and attended their internal playtest sessions.
I did get an opportunity to prototype a new game mode, similar to the football mode but with an always moving ball and barriers akin to Blockout. It was fun to get the chance to add something in to an established game and do some design work which I also enjoy.

It was a great experience where I got to work on a wide number of systems in the project.
These include, but not limited to:

• Lobby/matchmaking issues - joining/merging/syncing costumes
• Costume issues
• User language settings
• Object sync issues during online games
• AI behaviour issues (incorrect target for AI beasts in waves mode)/tentacles and shark pathing on aquarium
• Switch controller issues - adding extra players in lobby
• Level-specific issues - lightbaking, fixing water physics, stability
• Input issues - keyboard vs controller
• Camera issues
• Menu/UI issues - settings not saved/loaded properly, navigation issues
• Wrote unlit shader for confetti lighting issue
• New language character issues
• Created dev PC/Switch/PS4 builds for internal testing.

An experiment implementing the waveform collapse algorithm to generate Pacman levels. I’ve always be interested in procedural generation and wanted to build something using the type of generation for More information about what the waveform collapse algorithm is and how it works can be found here

Generation Steps:

• Set the desired height and width and also pick a palette, then click “Generate” to generate the pacman level.
• Before the waveform collapse algorithm can run, the grid is updated to make room for the ghost box in the center of the grid and a tunnel on the left hand-side. Currently only one tunnel is ever added half-way up the height of the grid. A possible extension is to randomly add one or two, depending on if the desired height of the grid will accommodate them.
• The left half of the level will be generated using the waveform collapse algorithm. Cells will show the possible number of tiles that could fit. As the algorithm runs the possibilities reduce as the grid is filled in. The algorithm starts with the cell with the lowest possibility of tile options and picks one at random. By setting a tile this has a direct effect on the cell’s neighbours and will reduce what possibilities that the cell’s neighbours can be. This is repeated until either the algorithm reaches a cell that has no possibilities or the left half of the grid is complete.
• If the algorithm cannot place a valid tile it will restart. After each tile is placed, the grid is checked that each tile is reachable via a breadth first search. If the newly placed tile creates a situation where not all tiles can be reached, the algorithm will restart.
• If the left half of the grid is proved to be valid it will then be mirrored to the right hand side of the grid. Each tile on the left is iterated over and its mirrored tile is placed.
• Once the grid’s tiles have been completed, the grid needs to be finalised by adding the border to the tiles on the outside of the grid. This is done with a maze-following algorithm that starts in the bottom left corner and walks the perimeter counter-clockwise by keeping the outside of the grid to the right of the direction it walks.
• Once the outside border has been added, the sprites for the ghost box are updated to finish the grid.

At Coatsink we have self-dev days, a couple days each month where we are free to experiment with game ideas, learn new skills etc. During some of my self-dev days I decided I would like to try and emulate the generated dungeon room layout I’d seen in the Rogue Legacy games. In Rogue Legacy, it would use a pool of room layouts, each room having a number of exits but what exits were available would differ on each run. I wanted to make a system that would use a pool of rooms but vary what exits would be used.
Each room details all of its available exits and are added as prefabs made available to the dungeon generation.​

The basic algorithm:

• Begin with the starting room and add all of its exits to a list.
• Pick an exit from the list and randomly pick a new room with a corresponding exit that can be placed without overlapping any other existing rooms. If an overlap is found, pick a new random room.
• Once a new room has been added, add all of its available exits to the exits list.
• Repeat this process until the required number of rooms is met.
• Block off any outstanding open exits to complete the generation.

I added special unique rooms to the generation. These are rooms that there would be a limited number of, e.g. a shop and added some rudimentary means of determining when a special room should be selected over a standard room. It is likely that we would not want special rooms to appear immediately after the start but because they would be a requirement for a successful generation, the likelihood of picking a special room is increased each time a special room is not picked until it becomes a certainty, and will be added next by the algorithm.

Finally I added a simple character controller so I can move between the rooms during play mode plus some cinemachine scripts to follow the player and switch to the new room upon entering it. With the time available we added some simple game mechanics: the boss room is locked and cannot be entered without finding a key that is spawned in a random non-special room. Once the key is found, the boss room can be entered but the doors lock after entry and would only unlock once the boss has been defeated as an example of what could be done.

This game was our submission for the GMTK Game Jam 2022. The game jam lasted 48 hours and the theme was “Roll the Dice”. I was in a team of four but this time I was not the sole developer and was joined by another programmer Will. Whilst I have been using github as source control for all game jam games previously, it was a necessity for both programmers to work seamlessly on the project.

We had a brief brainstorming session of how to implement something to the theme and I suggested a mechanic where you roll a number of dice and where they settled would determine where you and enemies spawned. The number of dice, and challenge, would increase with each level and adding in a reroll feature and we had a simple arcade-y score attack game we felt we could implement in the short time given.

With the two programmers, we split the work up such that I would handle the overall architecture, the dice rolling and general project management, and Will would handle the player movement and enemy logic.
I created separate branches for us to work on and managed merging them into the main branch and building the project for testing and submission.

The dice were effectively cubes that were given a small force in a random direction plus gravity enabled to have them fall to the arena below. I added logic to re-activate any dice that were cocked or landed on another dice until all dice were flat at rest. From there, the dice would determine spawn locations for the 2D player sprite, enemy sprites and any treasure sprites that were rolled.
If I was to do the dice rolling mechanic again I would perhaps have set result positions and have the dice move and animate into position.​

The GMTK Game Jams are always popular, this jam in particular has over 6,000 entries. That being said a lot of our feedback was really positive and we were rated in the top 12% so we didn’t get featured on the YouTube channel but I think there’s a really cool game here with a bit more polish and further exploration into the mechanics.

For this jam I teamed up with my artist friend from earlier jam submission Office Secrets to enter the Zeno Jam 5, a jam that lasted three days with the theme “Light Attracts Bugs”. We decided to make a cute puzzle game where levels are solved by turning on and off lights that encourage Scrawny, the protagonist, to reach the goal.
In this jam, I opted to do some up-front architecture setup and laid the groundwork with a bootstrap scene that would contain the common manager prefabs and scripts so each level scene could be easily tested from the Editor and wouldn’t require starting from the normal entry-point of the game.

We opted to take a relaxed pace and whilst the game was complete and well presented, it ended up with only a small number of puzzles. We perhaps could have added more but we decided to go with what was feature complete rather than add something that could have ended up half-finished by the time the jam was over.

The main feedback from our peers was that our game was great but lacking in content but even despite this it was voted 4th overall in the jam which we were of course pretty pleased with.
I believe that with a jam this short the main focus is to prove a mechanic works and to satisfy the theme, not necessarily produce a full game ready to be published and I strongly feel we achieved that.

I took part in Narrative Imperative Game Jam #1 in a team of four. The jam lasted for two weeks and the theme was “This is bigger than you”.

I was the only developer in the team and also acted as project manager/producer arranging catch-up calls and handling assets from art, narrative and audio.

We knew we wanted to make a game involving some kind of conspiracy and with narrative being the focus of the jam I was keen for your choices to matter, ideally utilising the “person will remember this” concept from Telltale games. Whilst we didn’t end up doing that I did program a dialogue system that would branch based on previous responses made.

We ended up having three distinct endings which we mapped out using Miro which allowed us to collaborate and quickly throw ideas and flows together. The jam was a little different in that rather the submissions be scored by the other entrants of the jam, this one had a panel of judges and cash prizes for the top 3. Whilst that wasn’t the main reason for participating, we came 2nd in the scoring and won a small prize as a bonus!

My first game jam working in a team of six where I was the sole programmer. The jam had the theme of Big and took place over two weeks in a more relaxed setting so I did an hour or two each evening during the jam. The team very quickly arrived at the idea of playing with scale and a story of a girl trapped in a dollhouse.

I was the one to offer the idea of selecting two objects, one highlighted in red, the other blue, like Portal and have the objects swap their size. I put together a concept quickly using a bounce easing function on the object scales which won the team over and they began to work on puzzles and theming in the game.

The jam was set up to make teams after listing your area of expertise so it was a new challenge to work with people I’ve never met before but it was great working with people from other disciplines and we managed to make something that feels cohesive.

Most notable about Esther’s Story is that the narrator’s lines are fully voice-acted and it includes a cut-scene video for the game’s ending. I had not done any programming with cut-scenes before but with the Video component it was straightforward enough and the art, animation and music folks did a great job!

My submission to the Game Dev London x Into Games Global Game Jam 2022. The game jam lasted 48 hours and the theme was “Duality”. I designed, programmed and sourced assets entirely on my own.

Inspired by Enter the Gungeon and Captain America I chose to create a simple top-down game where a soldier finds a shield that can be held in defence or thrown at their enemies.
Despite the short length of the jam I added an in-game tutorial to teach the player the controls.
Results and feedback can be found here

This was my submission for Zeno Jam 4. A short 2 day jam with the theme “I Am Everywhere”

I almost immediately knew I wanted to make a “snake” type game but with the condition that the board has to be completely filled before reaching the exit, which is the doggo’s ball. I originally had a concept of a world eating snake borrowed from mythology but opted for a lighter tone with the doggo that’s just trying to reach its ball.

A count of the number of unoccupied spaces is kept and a level is deemed complete when this count is zero when reaching the exit. This does mean that there is no one set solution for each level. So as long as the player has filled the board when reaching the exit it will be treated as a success.

I sourced the art and sound assets but couldn’t find a fitting dog sprite and with the short time constraints I opted to create my own - I’m by no means an artist but the character was popular amongst the jam community. Results and comments can be found here