Projects

RosterMaster

Early this year, and after playing in the same World of Warcraft Classic guild since late 2020, I stepped up and became an officer in order to contribute to its management and leadership. Nowadays, I have several responsibilities, which span to duties such as taking care of the recruitment of new players, discussing item distribution with the other officers and very occasionally leading raid teams of 10 people. However, my main responsibility is still taking care of organizing rosters for 10 man raids. This involves distributing guild members in different teams of 10 players, taking into account many different factors: their availability, the key roles they can perform, the different characters they have available, whether the items they need from a given raid are also needed by another player, etc.

Making these rosters can actually be very time consuming, and it's also very prone to errors. This is why after some time, I decided to craft RosterMaster in order to automate this task as much as I could. This tool is now capable of generating a list of available players in a given week, checking the validity of the rosters I manually make, and even generate them automatically, among other utilities.

The tool is implemented using Python3. In order to work correctly, a database of the guild players' characters must be kept up to date, which has to be manually populated. RosterMaster reads this data from a CSV file, so it can be generated by using tools such as Google Sheets. In order to know which days each player can raid, several JSON files are read by the program, each corresponding to a given raid day. These files can be easily generated, if your guild's discord uses the Raid-Helper bot. Manually crafted rosters can also be imported directly from Google Sheets.

The tool contains several modules, the most relevant being RosterChecker which checks for validity rosters which are manually made and calculates a score based on different metrics such as buff/debuff coverage, contested loot and whether rostered characters are using their main spec or not. This module also prints a report, providing relevant information to the user regarding each roster.

awc-rs (WIP)

This is my second work in progress attempt at making an Advance Wars clone, my first one taking back to late 2020. Instead of resuming the development of the original project, I decided to start over, using the Rust programming language as a baseline this time, while also trying to avoid some mistakes of the past by taking a design-first approach. What I aim with this project is to make an engine which can be used to recreate the original game, while still leaving room to make some modifications to the formula, such as adding new attack or movement patterns, effects that can trigger after certain events or conditions are met, etc.

This is a work in progress, so there are still some key features missing. At the moment of writing this, a few basic features have already been implemented: basic map rendering, loading of unit/tiles sprites, map/unit/tile data serialization, turn/event/team system and the movement command. Sadly, these are not enough to play a full game, because features such as an attack command or a win condition system have not been implemented yet. These are some of the features planned for the first complete version:

• Scripting Lua API. This would be used to implement effects and unit behaviour without needing to recompile the game.
• Economy. Factory and airport system to dynamically create units during a game.
• Fog of war
• Online multiplayer. Create lobbies for other people to join and play. Something similar to this.

Personal Webpage

What you are reading at the moment could also be considered one of my projects. This webpage is made using vanilla web technologies such as HTML5 and CSS3. After completing Block Buster, I decided to look back at all the progress I made since I started working on my personal projects in 2017. Due to the fact that at first I didn’t remember all the projects I worked on, I thought it would be a good idea to make this webpage for two main reasons:

• Journaling. As a way to remember what I’ve been working on, so my projects don’t eventually fall into oblivion.
• Showcasing my work. So potential recruiters can see that I enjoy challenging myself, spend my free time improving my professional skills and I have the discipline to finish the projects I start.

Later on, I also decided to include a section about the books I've read. I did this as a way to show that I don’t want to improve my skills only through practice, but also by learning techniques and methodologies from professionals with renown.

Block Buster - Game

Block Buster is a multiplayer voxel first person shooter made in C++. It features seven different types of weapons and four unique game modes. In addition, it counts with its own map editor. The maps created using this tool can then be played on by uploading them to the match-making server.

I started this project so I could practice two subjects I was interested in at the time: computer graphics, which I had previously learnt from the LearnOpenGL tutorials, and game networking. It was a great opportunity to try out implementing a Client-Server architecture, a very different approach to the Lockstep technique I used in Archer's Duel development. In order to provide a decent game experience over different network conditions, I did also have to implement fairly common game networking techniques, such as client prediction, entity interpolation and lag compensation. All of them are briefly described by Valve on this article.

This project as a whole, took almost one year to complete. However, most of the time I invested on this project during 2022 was almost exclusively dedicated to developing the client and the game's server.

Block Buster - Editor

This is the map editor tool for my voxel first person shooter Block Buster. It allows users to create or modify maps that can be used in multiplayer games. It provides some basic tools to place, paint or remove blocks, but it also allows for more complex operations through its select tool. Typical functionality such as copy, cut, paste, undo, redo, search and replace, etc. is also supported. Game objects such as weapons, grenades, health packs, teleporters and more can also be placed around the map with the Game Object set of tools.

Providing a map editor was one of the main goals of the Block Buster project. I love when a game I like includes some sort of tool which allows for user created content, such as Halo with its Forge mode or Advance Wars with its Design room, especially when that content can be used in multiplayer gameplay. In my opinion, including such a tool provides huge benefits at a rather small cost: it provides a way to produce free content for your game and keep its community active.

The map editor was the first part of the project I implemented. The first ready-to-use version of the tool took around 3 months to create. However, as the main project was developed, further modifications and optimizations had to be made.

Block Buster - Match-making Server

This program is one of my set of projects which are part of Block Buster, my voxel multiplayer first person shooter. The match-making server provides a REST API which is used by the game clients to find, create and join multiplayer games. Additionally, it also allows users to share the maps they created using the map editor. Unlike the other Block Buster set of projects, this one is made in Rust, instead of C++.

Another of the main goals of the Block Buster project was to provide online multiplayer functionality. A subset of issues that arise when making this decision have to do with how the client connects to a game server. Does the player have to type the server's address they wish to connect to? Do they simply press a button which then puts them in an apparently random match? Or can they choose a match within a list of already created games? The first case was a path that I already explored when I was working in Archer's Duel, so I opted for the third option this time.

Disclaimer: As you may have noticed, due to the project's name you might have thought that I had chosen the second option, and you'd be almost right. That was the first idea, which gave birth to the project and its name, but it was never implemented. I opted for the server brower approach very early on development, the name stayed the same, however. So I do agree that it may be a bit misleading.

rs-lag

rs-lag is the first project I developed in Rust. This program works as an UDP proxy to simulate network conditions. Different network parameters, such as RTT, jitter, packet loss, packet duplication and packet unordering can be configured through its command line interface.

After a few years practising C++, and experiencing some of the common problems that arise when using it, I thought it was a good moment to try out a new programming language. I had already used C#, when working on some of my Unity projects, and I was also tired of Java, because we employed it a lot during my bachelor, so those two were not an option. I particularly enjoy low level languages because of the degree of control they provide, but I also don't like to miss out some of the handy high-level features, such as containers or a basic OS abstraction layer. In my opinion, Rust has the best of both worlds.

Developing this program was a nice opportunity to put into practice what I learnt reading the book. At this time I already had started what would be the foundations of the Block Buster project, so I knew that I would have to test its networking implementation somehow. After checking that Rust provided basic UDP sockets functionality, the decision was already made.

AWC (Advance Wars Clone)

AWC is probably my most chaotic project. By its name, you may think that this is simply another Advance Wars clone, but it's actually a library. A library I made with the intention of providing some core functionality to implement any 2D turn based strategy game. It was my first project to support Lua scripting, which can be used to create maps and units. I also made a CLI implementation of chess using the library in order to test how it would be used in actual projects.

I said this project was chaotic because it lacked a clear vision. When I started the development, I didn't clearly know what I wanted this project to be. At first, my intention was to make an Advance Wars clone. But then I thought that with a good design (which I didn't achieve) I could reuse some parts of the program to make my own original strategy game. After that, the idea of making a library came up. I wanted to detach the game logic from its representation after all...

Despite the fact that I am not entirely happy with how this project came out, I think it was a good opportunity to achieve some goals: practising unit testing and Lua scripting integration. At the moment of writing this, I'm still unsure whether I'm going to continue this project some day or if I'll end up redoing it from scratch, maybe even in a different language, such as Rust. Only time will tell.

Space Rogue

Space Rogue is a game where you play as a bounty hunter doing a scavenge mission on a territory packed with hostile spaceships. During your mission, an old massive star died, triggering a supernova which you must escape from. The game features three different weapons and two different game modes:

Race: You must escape from the explosion while dealing with enemies and different obstacles along the way.

Scavenge: You need to recover 30 resources. However, you'll still need to fight enemies and avoid the explosion.

This was a group project I made with some friends using the Unity engine. Due to COVID-19, most of my friends and I were stuck at home, so one day that we were particularly bored, I proposed (initially as a joke) that we should make a game together. To my surprise, the idea was actually very well received. We decided that everyone should bring some game ideas that we could then discuss. After careful consideration, we realized that most of these ideas were too ambitious, so we thought the best plan would be to work in two groups of four people and make a fairly simple game in three weeks or less. That way, everyone could get some practice working in making games as a team.

The game was initially planned to be a Jet Fighter clone, but due to my previous experience with procedural content generation we decided to take a fairly different approach. The obstacles and enemy placement would be different each attempt, and the scenario is pseudo infinite. To keep it simple, we opted to design only three types of enemies (which are implemented using steering behaviours) and three types of weapons or power ups.

This project was made by the team I was part of, (very originally) called Team 1. The game made by Team 2 is a very funny and bizarre take on Mario Kart, appropriately called Mario Car: Wild & Furious. Make sure to check It out here. Make sure to browse its repo as well.

World of Warcraft Bot

After playing the game for around 3 months and watching so many bots running wild, I decided to make my own. Given the game was 15 years old at the time, I was sure that making my own would be feasible, as there should be a decent amount of information online about how the game works internally. I also saw this as a great opportunity to deepen my knowledge about reverse engineering and game development.

It took me 3 months of work while stuck at home due to the pandemic, but I came up with a Bot which was able to farm (that's killing monsters and gathering resources) dungeons repeatedly. You can watch it working in this YouTube video. Here's a extremely summarized explanation of what's going on:

1. A DLL (Dynamic Link Library) programmed in C++ is injected into the game's process, which opens a console window, printing log information. This approach allows us to read/write memory and call game functions within its address space. The memory location of relevant functions and game data were previously gathered by reverse engineering the game's executable file.

2. Periodically, the bot attempts to connect to a Python3 Server to receive the instructions which the player character should perform during a given session. With this, we avoid recompiling the DLL every time we want the bot to do a different activity. The set of actions (a behaviour) are recorded and stored in JSON files using a different Python3 program, which also communicates with the Bot to obtain information from the game. Among the actions that can be recorded and then performed by the bot, we have: Move or wait in a specific location, attract enemy NPCs within a radius, use an ability, kill enemies, etc.

3. Once the set of actions is received by the Bot, the fun begins! In this case, the bot runs through the dungeon attracting some enemies, stacks them in a specific location, and then engages in combat with them. After all enemies are dead, it gathers all the loot from them, and returns to the initial position. Finally, the bot sells all the loot that was gathered to a vendor NPC.

All the testing was done in my own private World of Warcraft server, powered by Trinity Core, an open source project which I had contributed to in the past. Finally, here are some of the tools and libraries that I used while working in this project:

• IDA Pro (Disassembler)
• x64dbg (Debugger)
• Cheat Engine (Memory reader)
• MinHook (Function Hook library)
• xortrs (Compile-time string encryption library)
• Extreme Injector (DLL Injector)

Before this bot, I made another version which had a strong focus on undetection, as I was initially planning to use it in the official servers, and I didn't want to get banned by Blizzard. The first version worked by using a kernel driver to read memory from the game's process. Then, this data would be sent through a socket to a Python3 program which would control the player character by simulating mouse and keyboard input. Additional information was also obtained from the game by reading pixels. Due to the fact that World of Warcraft has its own Lua API, which allows users to create addons to modify the UI or provide some utility for the game, I created my own addon to show data codified as pixel colors. However, only simple tasks such as moving and clicking on game objects could realiably be achieved with this design. Injecting a DLL to call game functions provides much more flexibility, at the risk of being more easily detected by an anti-cheat.

DroidRisk

DroidRisk is an Android malware classification tool which I presented as my Cybersecurity master's thesis. It's implemented on Python3, using the scikit-learn library. My approach is purely based on static analysis with the objective of achieving early detection of malware. In order to do this, I had to train four different AI models, each of them with static features of a particular category, such as Android permissions or the strings found within the app. After ensuring the validity of the results employing 10 Fold cross validation, the program scores 98% accuracy by combining the results of the four models.

The original idea was proposed to me by my professor. I decided to make this project because I thought it would be interesting to work in something related with AI. At that time, I was already planning to make a strategy game some day so I thought that this could be a great opportunity to learn something that I might be able to apply to it.

Due to the applications that AI can have in game development, it was a fun and interesting experience. Previously to the development phase, I had to do intensive research of the state of the art and came up with the idea of using Ensemble Learning after checking that the concept wasn't particularly explored in Android malware classification. Despite the fact that it wasn't necessary, I decided to assemble my own dataset of samples, which was made of around 800 applications, half of them being malware. I found my malware samples using the webpage Koodous, which is a collaborative platform where applications are uploaded on a daily basis and they are classified by many malware analysts. The so-called goodware samples were obtained from Google Play.

You can read the full thesis here.

Archer's Duel

In Archer's Duel you play as an archer defending your tower from the enemy archers. You must destroy their tower before they destroy yours! For this purpose, you can combine up to six different power ups, and a powerful cannon shot that can be unlocked during a match. You can play against the AI or against your friends through its online multiplayer mode.

What started as one of the many clones of the popular flash game Archer, became its own thing after many redesigns that were made during early development. Unlike Archer, I wanted the game to be much more fast paced, so I allowed players to move and jump around their tower, while keeping the ability to charge their shots. Making the gameplay more dynamic, making using Lockstep for online multiplayer almost mandatory, as I needed to have all clients involved perfectly in sync. This adds some input lag when playing online, because all other clients' inputs are needed before rendering a frame.

In an attempt to make each match different, I added six different power ups which randomly spawn around the map and have to be shot by players in order to use them. The power ups you unlock can have crazy synergies. For instance, you can combine the triple arrow power up with the fire arrow one, to start shooting three fire arrows! I did also add a killing spree like reward by giving players the ability to charge a powerful cannon shot, which unlocks by dealing damage to the enemy tower or hitting the enemy archers with your arrows. This way you can try different strategies to win a game.

SDL Pong

SDL Pong is a clone of the classic game Pong. It features three modes: single player, a local multiplayer (using one keyboard) and a very naive implementation of an online multiplayer. In order to make it a bit different, I made the following changes: the ball's speed increases after each bounce and the angle it takes, when hitting one of the paddles, changes based on the distance between the collision point and the center of the paddle.

My first project ever made in C++. After messing with the Unity engine for some time, which I used to make my bachelor's thesis about procedural content generation, I wanted to take a step forward and learn the language that is the standard for game development. This was also my first contact with the SDL set of libraries, which I still use in my projects to this day. Due to the fact that the objective was to learn the basics of the language, I opted to make a really simple game, such as Pong clone.

Needlessly to say, this project is full of raw pointers, memory leaks, and code in general that causes undefined behaviour. Today, I'm happy to say that my knowledge of the language has improved quite drastically and now I avoid most of the common pitfalls that can be found in this project.

QuickCashier

QuickCashier was the name of the project our group decided to present for the subject Project's lab. This subject was part of the last course of my bachelor in Telecommunications Engineering, where up to six students from the different specialties of the bachelor could team up to propose and implement an idea for an entrepreneur project. After discussing many different plans, we decided to opt for one that could solve a very common problem that one of the most profitable industries face during consumption peaks. QuickCashier would be a whole new system which aimed to mitigate crowding and long queues at clothing shops during sale season. This would be accomplished by using a mobile phone app which supported online payment, coupled with a secure method that allowed customers to remove the alarms by themselves, from the products they bought.

For the final version we presented, the system was composed of the following elements:

• Android application: Users who wanted to employ our system would need to download the QuickCashier Android application. This would allow them to use their phone cams to scan barcodes from the products they'd like purchase. Then the application would use these codes to retrieve information about the items by doing a query agaisnt a NodeJS REST API, such at its name and price. Each scanned product would then be added into the shopping cart. Finally, the user could pay for the purchased products by using a credit-card or PayPal.

• NodeJS Server: We implemented a REST API in order to be employed by the Android application and our QuickMachine for some key functionalities, such as user login, handling payment transactions, updating the product-alarm association, which user is using each QuickMachine, etc. It basically works as an orchestrator for all the operations that are involved from the moment the user opens the Android application until they take out the last alarm of the products they purchased.

• QuickMachine: Implemented using a Raspberry Pi 3, the QuickMachine is running a C++ program using Qt libraries, displaying a user interface using a touchscreen. After a user has completed the payment process using our Android application, they can link their purchase with one of our QuickMachines by simply reading the QR code displayed on its screen. Once their purchase is linked, the products bought by the user should show up in a list on the touchscreen. At this stage, the user can remove the alarms from their products, by putting them in the designated space in the device. However, it is only possible to remove the alarm only if the RFID code which is held within the alarm itself, is correctly read by the RFID reader in the QuickMachine. The RFID code is then tested against our Server in order to evaluate if any of the products bought by the customer could have an alarm with that specific code. If this evaluation is correct, an electromagnet is enabled, which should allow the user to physically remove the alarm from that product.

QuickCashier was awarded the first prize by the company Optare Solutions. In addition, an article was published in one of our local news webpages, which you can check here.

Map Gen

Map Gen is part of my bachelor's thesis about procedural content generation . With this tool, 2D tile-based strategy maps can be generated. Some generation parameters can be tweaked to obtain different results. Some of these parameters are: the size of the map, land, mountain and forest density, the amount of resources scattered around the map, whether to trace roads between the bases, etc.

The map generation process is fairly simple, and it somewhat resembles Conway's game of life:

1. The entire map is filled with water tiles.
2. A bounded random number of land tiles are placed in random positions on the map.
3. A random amount of iterations is run. On each iteration, each land tile attempts to expand to its neighbour cells, based on some probability. The chance to expand is reduced on each iteration.
4. Steps 1 to 3 are applied for mountain tiles, but with a tweak: mountain tiles can only be placed on land tiles, instead of any tile.
5. Steps 1 to 3 are repeated for forest tiles. Similarly, forests can only spawn on grass tiles.
6. Player bases are placed in random positions around the map, attempting to maximize distance between them.
7. Optionally, roads are built between the two bases. The path the road takes is calculated using Dijkstra's Algorithm, where each tile is given an arbitrary cost. Water has the highest travel cost, while land has the lowest.
8. As an option, resources are placed around the map. However, in an attempt to reach some balance, we again use Dijkstra's Algorithm so the resources are placed symmetrically. By symmetrically I mean that when a specific resource is placed in a random position at a given distance to a player's base, another one is placed with the same travel distance to the other player's base. That way, both players have the same amount of resources and at similar distance within their reach.

Dungeon Gen

This is one of my four games that make up my bachelor's thesis about procedural content generation. It's a rogue-like shooter where you explore sci-fi dungeons which are procedurally generated. Along the way, you'll find different enemies whose power increases as you go deeper into the dungeon. In order to progress in some levels, you'll have to find keys to open the gates that lead to the next floor. During your exploration, you may also find different weapons which can aid you in your quest.

The process to generate the dungeon is based on binary space partition, which generates a graph model. Each leaf node of the graph corresponds to a room in the dungeon, and the connections between them are made by following the graph. That is, a room can only connect to another only if they have the same parent on the upper graph level. The rooms are connected to each other using corridors, whose path is calculated using the A* algorithm, a variation of Dijkstra's.

The placement of keys is done following the graph model as well, and it's dependent on which room the player spawns. This is necessary in order to avoid generating a dungeon which is impossible to complete, because a key could end up being placed behind its corresponding gate. Due to the fact that the graph represents how the rooms are connected, this situation can be avoided.

MyCraft

MyCraft is another of my four games that make up my bachelor's thesis about procedural content generation . This is of course an extremely limited Minecraft clone. Similarly to the original, you can choose a seed before entering the world which will dictate its shape. Once it loads, you can freely move through a pseudo infinite procedurally generated landscape.

Making a Minecraft clone wasn't necessarily planned before I started the project, but I was sure that it was something that I wanted and had to explore. That way, I discovered that Minecraft's terrain is generated using Perlin noise. Perlin noise is sampled using a vec2 and it has the special property that the closer the sampling indices are, the higher the correlation is between the sampled values. This allows the generation of terrains that look more natural and organic, instead of chaotic spikes or pits that would be obtained if using a different pseudo random number generator.

In order to increase performance during gameplay, I had to do a few optimizations. As in the original game, blocks are distributed into groups, called chunks. Due to the fact that the terrain is generated during gameplay, more chunks need to be loaded as the player moves around the world. However, in order to prevent loading all chunks at the same time, the game will stop loading those chunks which are far away from the player.

MazeGen

MazeGen was the first project I developed as part of my bachelor's thesis about procedural content generation. In this game you can explore different types of labyrinths with a top or first person view. Before you start, you can choose the size of the maze and the algorithm which is used to generate it. Starting from the red square, you need to reach the green one to win!

Including a project which used maze generation as part of a project about procedural content generation felt almost mandatory. There's plenty of research made already on this topic, so I decided to include three different generation algorithms. Mazes generated by each of these algorithms have their own set of features:

• Depth-First Search: Produces a maze with a very long main path, with very short branches. Therefore, it is quite hard to get lost during exploration. Perfect for adventure games
• Prim's Algorithm: Produces a maze with many branches but which are usually short on length. This makes it fairly easy to get lost.
• Space Partition: Mazes generated by this algorithm tend to be quite chaotic, which alternate between very long and very short paths.

As you may have noticed, most of these algorithms come from graph theory. They are used in that field as different ways to explore all nodes in a graph, with different purposes. For instance, Prim's algorithm is used to calculate the shortest spanning tree. The property of these algorithms ensures that the maze will always have a solution, as all nodes or cells can be reached from any other.

Hard Trip

Hard Trip was my first contact ever with game development. It's a game made with the Unity engine, where you play as a soldier who's defending a caravan of three horse carriages from the many threats that exist within the Brenner Gorge, such as bandits and wolves. In order to complete the first (and only) level, you'll have to traverse three main sections, where you may find some key items that will aid you in your journey, known as clues, defended by enemy forces. In each section, there are two different paths that the caravan may take. The caravan will choose one of them depending on the clues you found in the previous section. However, you'll have to take the careful decision of choosing the first path the caravan takes.

This project was part of a subject I had during the last course of my bachelor. It was made in collaboration with students from a different bachelor, who had a subject about game design. The game itself is lightly inspired by a fragment of a novel of José Saramago, The Elephant's Journey. The game was made within the span of four months, with a team of six people: four programmers and two designers. The game underwent many redesigns during development, and due the fact that the none of us had any previous experience using the Unity engine or game development for that matter, the final product may be lacking in the content side. However, we're all quite happy about how it turned out.

Despite the fact that, towards the end, working on the game became quite stressful because we had to meet strict deadlines. However, it was a great experience overall, which I'd gladly repeat.