Josh Hornsby

Student at Cardiff University & Freelance Developer

About Me

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.

Working on real life projects is what gives me the most inspiration to make excellent products. Most of my work is done in java, producing plugins for game servers to add functionality or gameplay. However I have also worked on websites for people (writing HTML, CSS, JavaScript and NodeJS code) as well as Linux dedicated server maintenance which I do on a regular basis.

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.


Click to View My Qualifications

My Skills

I've worked with the most popular database systems, including: MySQL, MongoDB and Redis.
I mostly work in Java, but I also can code compliantly in C, C#, C++, Python, Javascript, PHP and Lua.
I can write website backends (Java, NodeJS, PHP, etc..), and front end Javascript, HTML and CSS.
I'm able to manage Linux and Windows servers, including initial setup and continued maintenance.

Qualifications

University

Currently studying Computer Science at Cardiff University

A-Levels

Information & Communication Technology A
Business Studies B
AS Accounting B
AS Use of Mathematics B

GCSEs

Information & Communication Technology A*
Physics A
Chemistry B
Biology B
Mathematics B
Business & Communication Systems B
English 1st Lang CIE 0500 (inc speaking/listening) C
English Literature C
Geography C

Minecraft RPG


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:

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:

new AssemblyModification("StardewValley", "Farmer", "setMoving",
new string[] { typeof(byte).FullName }, 158, true, new string[] { "ModLoader.Program.OnPlayerMove();" }).Inject(assemblyDef);

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#.

Survival Trail


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.

See source here: https://github.com/JokHornsby/TrailGame

Minecraft Skywars


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.