My projects
On this page I will record some of the games that I have made, this will be some for uni projects and some i have worked on in my own time. This is all to show what i am capable of and my ability to learn fron doing any given project.
Shadows fortune
- C#
- Unity
- Unity pathfinding
This project was made as some of my university coursework, the task was to make a game in unity using framework they provided. The game I made is a top-down stealth game with a points system to allow replay ability. The game uses the unity engine and utilises the systems within it and includes use of the 2D colliders, 2D rigid bodies and ray casts. Most of the game is made with C# scripts that are implemented into the GameObjects within unity.
During this project I did run into a few problems, two major ones where: when enemies would switch between searching states, they would desync so only some enemies would lock onto the player when they are alerted, and I had problems sideloading the UI to stay on screen when the player would end and restart the game as it was never gotten rid of. The problem with the enemy state changing was that enemies would come out of alert a certain time after the player was spotted but any enemy that spotted the player during alert would restart this timer whereas the others would not and would just return to normal. To solve this problem, I had to make the enemy, send a signal back to the alert controller for seeing the enemy even when an alert was active, so it doesn’t send the end alert signal timer back too quickly. The problem with the UI was that it would stay on screen for a second run of the game leading there to be 2 UI on screen which caused confusion this was solved by simply having the UI be destroyed by the script that controls the end screen and makes that appear.
The game is a stealth game where you have 8 directional movement from a top-down perspective when enemies spot the player, they will chase the player until either line of sight is broken for long enough or the player dies. Within the game there are three kinds of enemies: enemies that stay in place and rotate, enemies that strafe left and right but can only look in one direction and an enemy that will walk around until it spots the player where it hunts them down. Throughout the game there will be large games laid on the floor that give the player points when collected this it to add replaybility as it is more difficult to collect the gems and if the player dies, they will lose points so there is an element of risk and reward.
RPS QUEST
- C++
- Object Oriented Programming
- Github
- Making changes after play testing
This project was made specifically to be used on this portfolio as I thought a C++ Text based game would be perfect to show off my proficiency in C++ and any other programming concepts that would be needed. I use C++ specifically because it is efficient but also just what I most prefer to code in. Throughout the game I use loops to make sure any action the player uses that needs to be repeated can do so, Random Number Generation to make the enemies of the game attack randomly keeping the player on their feet and use of the input stream to allow the player to interact with the game. Due to being made in C++ the game is object oriented and there is a class for the player, the main game loop, the process of encountering an enemy and a class for each individual enemy which is a child of the parent enemy class. The parent enemy class contains parameters for each of the stats all enemies share as well as functions for what the enemy will do when they pick rock, paper or scissors and this can be overwritten by the child classes to change to the unique enemy types. Programming like this makes the code a lot more readable as well as easier to implement new enemies into given sections of the game.
Due to the relative simplicity of the project, I didn’t run into many major problems but there were a few notable difficulties. When I started the project, I was still a little unsure on how object-oriented programming works but as the project went on my understanding grew and I am now quite confident doing it and will be able to employ that in most of my major projects in the future. The other problem is much more specific as throughout the project the user is told to press enter to continue but for some reason C++ allows you to buffer those button presses and this would allow the user to make inputs for actions they have not yet been shown, I didn’t originally think this was a problem as when playing I knew to only press enter once but when the game was play tested I realised this completely broke the game and made it unplayable, to fix this I found a function that would take user input but would ignore any past input "system("PAUSE");". I think this project turned out well but there are a couple changes I will make in the future: I need to start commenting code as this will make it significantly easier to read as well as giving better titles and descriptions to my GitHub commits.
The game uses a somewhat simple game loop as it will be in one of 3 "states" of sort and transition between them to continue playing. The game will start with Text explain what is going on in the narrative before switching to an encounter and once the encounter is done the player will usually be given a choice to go further into the game or retreat to fight more enemies. During an encounter the player will be shown a prompt that alludes to what the enemy is going to do then given a choice of rock paper or scissors and this will repeat until either side loses all its health, if the player loses then the game will reset and if the enemy loses the game will continue.
Multiplayer game
- C#
- multithreadding
- multiplayer games development
- replication
- serialisation
One of my projects in the second year of university was to create a game that is multithreaded in C# that can connect online through a server. This project uses C# and within that uses threads as well as Monogame to connect the systems and display graphics on screen and the input system. The programs connect through another system which acts as the server and can allow one game playing at a time.
When creating this project, I had difficulty learning and implementing the threads to make it multithreaded, in the end I managed it by having each user have a thread for the game being played and for and for the socket that is connected to the other user as well as some more minor threads. This is directly related to the other main problem that occurred during the project that was the network connection and what data to send across the system. This was a problem because I had difficulty getting the packets to serialise and deserialise, this was because the packet classes would not properly deserialise if the classes didn’t have constructers without parameters, so the serialisation algorithm didn’t know what to do. Once the serialisation was fixed the data being set across was proper so that solved the problems with the data connection.
The game starts you out on a menu with two buttons where only one of the buttons works titled “Log in” once that is pressed it finds a server and connects the user to it and allows the second button to work. Once the second button is pressed it starts the game, during the game it waits for another player to join then the game starts. Within the game either player can move back, forth or jump as well as throw and axe and the player to hit the other 3 times wins and which causes the game to reset, and the players are put back to full health.
Physics showcase
- C++
- DirectX11
- Point mass physics
- Rigid body physics
- Using a timestep
During the second term of the second year of university one of the projects I had to make was a physics simulation where everything is programmed by me in directX11. It contains a bunch of cubes that can be manipulated by the user to show off the physics. The framework is capable of point physics and rigid body physics and the framework can apply gravity to the objects and rotating them using quaternions. In this project I have also made a timestep so the system will not run slower or faster no matter the frame rate the program is running at.
There are 5 cubes in the world: 1 in front that can be controlled by the player and 4 behind it that are there to help show off the collision. Each cube in the world has a sphere collider and so when the controllable one is guided into the others, they will all collide appropriately, this will also account for more than 2 spheres colliding at once. Gravity can be turned on by the click of a button but since there is nothing for the cube to fall onto there is an option to turn off gravity and reset the position of any of the cubes. When the cubes collide, it they will rotate but this rotation is assuming that they are spheres as it uses a sphere collider, so this does look a little weird with them appearing as cubes. The user is also given the option to push each cube towards or away from a point in the centre of where everything appears.
A major problem I came across towards the end of this project was with the rotations of the cubes this was because the system only has axis aligned bounding boxes and spheres, the rotations of the cubes will always look inappropriate as without there being object oriented bounding boxes there is not enough data available of the boxes orientation to make it rotate and move appropriately. Another problem I ran into was early on before I had any force system implemented and I was implementing the timestep the box that I was moving to test the timestep was jittery and this showed me it was implemented incorrectly, in the end I found the problem was that when I implemented the timestep I originally made a miscalculation and the delta time ended up being far too low so I had the distance the cube was to be moved much higher as a result and so when delta time was fixed the cube would move much slower and at an inconsistent pace which caused the jittery effect this would also mean the cube would sometimes disappear because it would start moving super-fast which made the problem difficult to deduce.
Graphics showcase
- C++
- hlsl
- Use of ShaderDoc
- utilisation of an obj loader
As a part of one of my second-year university projects I was tasked with creating an engine that can display graphics with lighting in real time. This project isn’t a game but can display graphics in the same way a game would as it uses the same software and methods as used in some games. The objects that are displayed in the world are mostly random. This project uses DirectX11 in C++ to achieve this and uses HLSL for the shader code and during this project I was taught how to use shader doc to be able to debug my program when errors inevitably arise.
The world contains cubes that I have individually programmed the vertices and indices as well as multiple objects that I have pulled from files using an OBJ loader there is also a line as well as some simple terrain below it all and a skybox. Most of the objects in the world move and rotate in one way or another or have their sizes altered as well as two of the objects are slightly translucent and one of the cubes has a texture with completely transparent parts. The terrain was created by marking all the points horizontally on the Y axis before pulling a height map from the files and plotting the height onto each point on the plane that was just made. The skybox was made by creating indices for an inverted cube so that its visible from the inside and making a new shader that renders anything that uses it behind any preexisting object in the world, so the texture is always shown to the user.
A large problem I ran into while making this was difficulties when making the regular lighting shader. The lighting within the shader I used 3 different kinds of lighting ambient, diffuse and specular and when implementing them the problems came when implementing specular lighting. Specular lighting required I send more information across the buffer to the GPU and I had thought the variables would be sent across how they are but this was incorrect as the GPU has no way of receiving the variable names so it requires the data is sent across in the order it should be received so the data on the GPUs end is exactly the same. This could have stayed a problem when I created the skybox shader but by then I had made sure to confirm both ends get the same information.