My Contributions

- Utilising Unreal 5's AI subsystems I created behaviour trees for the monsters and player bots.

- I created a custom FSM for one of the monsters as its behaviours were simple compared to the other's needs and as such could use a less complex decision-making strategy.

- Developed custom behaviour tree task and decorator nodes in C++ to condition check and utilise the rest of our projects underlining code base in Unreals behaviour tree system.

- Implemented animations for each of the monsters using Unreal 5's animation systems, taking advantage of its anim montages to blend between two animations so that the monster can run and punch simultaneously.

- Added bot drop-in/drop-out functionality to the player controller so that when a player joins and there are no more free slots, they attempt to replace a player bot. And when a player leaves, their character is possessed by a bot.

My Contributions

- Worked as the sole programmer on the boss with designers to implement its relevant AI behaviours and mechanics like how it attacks.

- Programmed the boss room's puzzle mechanics and completion functionality in a modular way so that any actions could be attached/detached to a puzzle completion easily in the world outliner.

- Implemented custom C++ behaviour tree task nodes to integrate the unique boss actions into its decision-making.

- Created a cinematics manager that made it significantly easier for designers to integrate sequencer cutscenes and camera pans into the game world through condition checking if puzzles are complete or if specific collisions overlap.

- Helped implement gameplay features like the interactable's world-space UI, providing settings like distance for it to be seen or whether you can see it through other world objects or not.

My Contributions

- I led a team of three other AI programmers to technically design and implement AI systems into the game.

- Devised a pair programming team structure for working on features to help the weaker programmers improve while having the stronger programmers have someone to discuss potential solutions with. This worked out well as everyone on the team was technically minded, it was just a case that some were not as fluent in Unity C# as others.

- Defined the game AI's technical direction and what decision-making methods would be used - based on the core game loop and what my team's prior experience was like.

- Developed player bot AI using an FSM structure as it was what the team were comfortable with and worked well with the objective-based team fights in the core game loop. That being said, in reflection, a behaviour tree could have been a more favourable solution as the bot would feel less rigid with how it acted in-game.

- Helped run the studio's source control by managing my team's branches and helping out with studio merges.

My Contributions

- Developed the original drone shooting implementation and maintained it, primarily on my own, throughout the project

- Made the drone's EMP'd response so that it became a physics object that rolls around and after a set time reboots, all in a function call.

- Created a checkpoint system including a manager which made progress tracking the player significantly easier. It also allowed optional linear progression depending on if backtracking was allowed.

- Implemented the tutorial/checkpoint world-space UI to activate/deactivate based on a certain condition (distance/collision overlap).

- Helped refine the drone's animations so that the projectile spawning lined up with the animation and the drone's disabled state had its according animation.

My Contributions

- This project was a game jam entry to the Wowie Game Jam 4.0, and as such was developed from start to finish within the forty-eight hour time limit. Our team consisted of me and my brother Jacob where I did the programming, he did the art and we both worked on the design together.

- I implemented AI bots that wandered around the screen aimlessly, which gave the player the ability to pick them up and drop them.

- Integrated the AI bots with the job sites around the map, so that if assigned - a bot will gather resources before then returning them to the base.

- Implemented all the animations in the game, from the bots idle and walking to the base flying away at the end of the level.

At the start of the second year of university, we had a module involving SDL2 which was our first time using it. As I enjoyed working in C++ and wanted to get a head start, I decided to attempt an introductory project to replicate the original 1972 arcade game 'Pong' before we restarted.

Overall it was a fun project and gave me a solid foundation of SDL2 but given the significant time I have had to improve since. It is fairly easy for me to spot parts of the codebase I would do differently now.

Red Retro Speedrunner was an entry for 'Brackeys Game Jam 2021.2' and as such was developed from conception to finish within the week time frame.

This was my first attempt at a game jam and while far from perfect, I am content with the result. This project gave me the chance to create gameplay systems I had not worked on before like wall running and a grapple gun.

Vroom is an arcade racer I created using C++ and the PS4 SDK and is a project I look back on fondly. The project was my submission for a uni assignment where we were asked to create a 2D or 3D game for the PS4. Our only resources were C++ and a basic 2D renderer.

Due to my interest in everything 3D graphics, I decided early on I wanted to attempt 3D. As such, I went through the painstaking process of implementing a custom obj file reader and rewriting portions of the renderer to account for the proper maths and WVP. This went really well, although I did not have the time to learn shaders and as such the colours are very flat.

Once I got the 3D rendering finished and had a car model on screen, it did not take me long to add a simple collision/physics implementation for the driving acceleration and gravity when you fall off the edge. As well as basic AI that can control cars around the track and will shoot shells at you if you're in front of them.

'TP Clicker!' was my first released game. During 2020, with everything going on in the world. One way I kept myself sane was by working on improving my programming and scripting abilities, as I have always been rather fond of learning, especially about game development.

Before this project, I had used Unity for my A-level computer science coursework but had never attempted to create a mobile game in the engine. So this was my chance to delve into that and learn the processes involved.

I created everything in this game from the art, to the questionable design and the C# scripts that run the whole thing. Ultimately giving me experience developing for Android in Unity and integrating Unity Ads into a project.

If you read my piece on my 'Pong' clone, then you might be interested to know that this was my submission for the SDL2 module I discussed. In an obvious way, this project shows a leap in my understanding of how C++ applications are made but also how SDL2 runs as a library.

While still not perfect, 'Gobbie the Gobbo' has a fair bit going for it. To start with, a defined application loop where new objects are created at the start of a frame, marked are destroyed at the end and manipulated during the middle to ensure no nullptr errors during runtime. There is also simple data-driven level reading.

The game has a camera capable of: tracking any object it's assigned to. Layered rendering capabilities to emulate a Z-axis. A toggleable debug render layer to see collisions, fps and toggle a no clip mode. A working UI and -what I am most proud of- a custom animation system, with customisable playback rate - although that is technically not on the camera.

Ultimately this is one of my favourite projects I worked on at uni and intend to release it at some point in the close future.

For one of our earlier modules at university, we were asked to create a variety of tech demos relating to different gameplay features across multiple devices/engines. For this demo we were asked to develop a series of horror game esc mechanics in Unity.

I learnt a lot from working on this demo, from creating a viewable inventory system with collectable items, to subtitles that line up with a voice recording and a keypad mechanic that I am still, to this day, proud of.

This project allowed me to learn more about Unity's scriptable object types and how to effectively apply them to an item inventory setting. It also provided insight into working with other people's custom packages like the cell-shaded highlighting.

This demo saw me further developing my understanding of 3D graphics on top of the knowledge I gained during my PS4 game and taught me numerous lessons in doing so.

To start with, this demo taught me how to write hlsl shaders and a lot of the maths behind different types of illumination models such as phong and blinn-phong.

It also taught me how to apply mtl files to their obj counterparts and the maths behind the ambient, diffuse, specular and emissive components and how to correctly calculate an end result using them.

Going even further, I learnt how to program different light types (e.g ambient, directional, point and spot), how to use dds to draw a skybox in DirectX 11 and how to create a variety of other features I could go on about but I have to stop at some point.

Even though the codebase needs tidying, this project has pushed my understanding of 3D graphics so much further than it was and has taught me so much that I intend to show off in future
projects.

Retro Ruination is a game I made in my first year of university as part of a module to showcase both Unity and Unreal Engine 4 and highlight the different areas that each one excels at.

This was a fun project as due to my previous experience, my understanding of Unity was ahead of what was being taught at the time and as such I spent most of it trying to create as polished a game as I could with art assets of my creation, with exception to the music.

From a technical standpoint, although I have had a solid understanding of object-oriented development for a while and as such am sure the game's codebase proves. Reflecting I can think of multiple gameplay features I would like to rewrite given my more refined knowledge I have at the time of writing.

The primary limiting factor to the game was we could only have a single game level but now I am past that, I may return at some point to flesh out the world a bit more.