Student at Cardiff University & Freelance Developer
Computers are a large part of everyone's lives, and this idea has been growing exponentially as I've aged. This has been the main reason for my growing interest in computers, and eventually my discovery of computer science.
Although I enjoy to use Java on a daily basis, my true passion is low level programming in C. I enjoy to be in-control of computers in order to create the most efficient code possible.
Although I do spend a lot of time using computers, I also like to play sports to keep myself both physically and mentally fit. At weekends I spend time cycling on my road bike and playing tennis and badminton with friends. Sports not only help to keep me fit, but also to focus on something different, and therefore relieve stress.
Currently studying Computer Science at Cardiff University
Information & Communication Technology
AS Use of Mathematics
Information & Communication Technology
Business & Communication Systems
English 1st Lang CIE 0500 (inc speaking/listening)
When I first joined Desteria, there was a bug list and intended feature list so long it would barely fit on a screen. However, after 6 months of working there I believe that the open bug list has been drastically reduced and that new features have been rolled out effectively. At this time, I am the Head Developer at Desteria, and work on hiring new staff and keeping our small team on heading in the right direction.
In my time at Desteria, I've had to diagnose and resolve many overly strange and hard to understand bugs. However, due to my highly driven nature when it comes to programming in particular, I've managed to fix them all and learnt a lot along the way. From custom clients to figure out potion lag issues and random packet crashes, to custom Spigot builds and debugging plugins, I've learnt so much just from diagnosing these bugs.
I've also worked on features like custom monthly crate plugins with complicated and player stimulating user interfaces, all created from scratch. As well as more back-end style code including a custom logging system allowing administrators to lookup in the logs across the many realms that we have currently running.
I worked on this project with a client on the side of my college work at the time. The project had
typical RPG elements, such as:
Selectable player classes and subsequent abilities
Mob spawners and custom item drops
Multitude of stats, all possible to change through items, including:
Health, health regen and max health
Mana, mana regen and max mana
Armor damage reduction
Melee and spell damage
Fall damage reduction
Critical damage and critical chance
The most important thing I learnt during this project is how to manage a large codebase as the project grew
to a size I had never personally managed before. I spent time refactoring some of the code every so often, and soon became
comfortable with the large size of the project, and the fact that even I who wrote it would not remember what everything did or where
certain parts of the project were.
I also learnt more about writing multithreaded code, as most of the player management (health regeneration, skill management) is carried out on a separate thread. This turned out well, as such a big project with a large amount of background computation required could have slowed down the server if this work was done on the main thread.
Overall, this stands out as one of my favorite projects, and as my largest so far. Not only did I enjoy it, I also managed to build up a fairly large set of standard libraries for doing common tasks that I still use to this day in other projects. This project stands out as an example in my portfolio that I can work on large projects over a long time, but also helped to prove to myself that I could do it too.
Although the source code for this project is not open source, since it was done for a client, you can see the structure of the project here:
Stardew Multiplayer Mod
This was a very ambitious research project that I worked on in mid-2016, and it's a project I come back to now and then when I have time because it's so fun. I wanted to create a multiplayer mod that could let people play Stardew with their friends. There are various "mod apis" out there, but they didn't give me the control I wanted, so I started to create my own.
The mod loader worked by altering the C# bytecodes in the Stardew exe using a library called "Mono.Cecil". This library lets you load exes into memory, search the bytecodes and do replacements or additions. Then I could hook events into the things that happen during the game, such as picking up an item, and then this event could be sent across the network to other players in order to sync the game between clients.
Since writing code in bytecodes is tedious and time consuming, I wrote some code to compile C# (using the CSharpCodeProvider class provided by Microsoft to access the C# compiler from within a program) into bytecodes and then inject that into any position in the code. You can see an example of this here:
This code snippet injects "ModLoader.Program.OnPlayerMove()" into the setMoving method of the Farmer class. This means that the player position can be sent over the network in the OnPlayerMove method.
This project was a big undertaking, and I never finished it, but that doesn't mean I won't ever go back to it. I learnt some really important things about C# bytecode manipulation and how to read bytecodes, which should carry over to the JVM pretty well, which is useful as I use Java a lot more than C#.
The task we were set was to create a text based game using Python. Still keeping with the theme of a game that is run in the console, we decided to create a user interface in the console by clearing the screen every frame and drawing the user interface on top.
The game involves taking control of a group of survivors during a zombie apocalypse. Gameplay is split up by traveling between cities, scavenging for resources, resting, trading for fuel and food, and the random events that happen while traveling. The main game content is in the random events, where random survivors will have events happen to them, either good or bad, that effect their health or the items the survivors have. For example: "Survivor 1 got their arm stuck in the steering wheel and broke their arm." In this event, that survivor would take damage, and if you named the survivor after one of your friends, there can be some comical situations that occur. The game takes influence from Oregon Trail (1971) and Organ Trail (2011).
The hardest technical challenge was removing flicker when clearing and redrawing to the screen. This was achieved by using the CTypes library to call the Windows API to quickly clear the screen and draw the entire screen content in one call rather than drawing it line by line.
Although the game wasn't a technically challenging implementation, I learnt a lot about working as a team, as this was my first time working with a team rather than by myself or as a duo. I also got to be creative as it was my own project, and having input from other team members during our weekly meetings was a great experience for me. Our game ended up winning the award for best game, as everyone seemed to enjoy our live demos.
I worked on this project with another developer, who focused on creating most of the gameplay code, and I created the network code. This included the queuing system and auto balancing of servers.
Whenever someone queued, and there were no game servers up, the queuing server would spin up a new game instance ready for the players to join. Then, whenever the game finished, that server would shut down. This meant that the servers could deal with any amount of players, with multiple servers being able to be run at a time.
The queuing server would communicate with the game servers over a socket, which is the part of the project that I worked on. Packets would be sent for initialization, players joining and game finish. For initialization, the queuing server would pick a map based on the number of players in a queue and then send that information over to a new game server. The game server would then wait for players to join, then send a packet to the queuing server to tell it that there's no more slots available and that it should lock this server. When the game finished, the game server would send a final packet to the queuing server to tell it that it was done, and then it would shut down.
Because the system worked over sockets, this meant that game servers could be distributed across multiple physical machines and managed by the main queuing system, allowing for a large player capacity.