ProgrEmily
Game & Engine Programmer
Featured Projects
Spearloom
04/12/2024
Game Project with 5 Frames Games
Spearloom is a small physics platformer made in Godot. I was a tools developer for the project, and later took on the role of graphics programmer when we started thinking about shaders. As a group of 2 programmers and 3 designers, we took this project on as a half-year part-time endeavour to see what we could make in that time. ​ In its totality, the game is a neat demo package demonstrating the specific skills of everyone who worked on it. ​​

The title screen for Spearloom. Our artists did a great job on this.

Editor view of a level from the game. You can see the room bounds for the camera, the room transitions and their directions, and where lights have been placed around the room.

Game view of a level from the game.

The title screen for Spearloom. Our artists did a great job on this.
NES
Minesweeper
26/11/2023
Personal Game Project
This is a project I've been working on for a good couple years on and off, though realistically it was more like a few weeks worth of actual work, maybe a month at most. But it's finally done! ​ The fact that this one was a minesweeper clone is mostly inconsequential - I really just needed some simple game to clone so I could learn 6502 assembly and the NES pipeline for my next NES project! ​ Incidentally, it turns out that minesweeper is not such a simple game, especially with the specific limitations of the NES! That console is very good at running a physics engine, but have too many big loops run in one frame and the whole thing goes crazy! Lesson learned for next time - anything that is going to take a while should go into a buffer and get completed a bit at a time. ​ More information, and the project itself, can be found on my GitHub repo! (https://github.com/SmallCodeDev/NES-Minesweeper)

Press start!

The board at the start of a game

They got all the mines! Look at how cool they look now!

Press start!
Other Projects
Seabound
13/12/2023
Game Project with Equiknight
Seabound, the culmination of a 6-week group project, is a casual fishing game with a key focus on exploration. My role on the project was as a general programmer, and my contribution, accordingly, were the movement controller, settings backend (though not the UI), the camera controls, and the fishing ellispe. You can find my thoughts about these further down. ​ This project was perhaps the most challenging one I've faced yet, mostly due to the group environment; working in a group has been a new and enlightening experience for me, and I've learned a lot about how I work with others. ​ Another challenge with this one was the extremely short time period given to make the game; 2 weeks each for alpha, beta, and gold development, with 3 days per week to work on it. Essentially, it was like a big group game jam, and a lot of things ended up getting rushed because of that. ​ --- ​ Dispite having sunk most of my time into the player's movement, my absolute favourite piece of work that I did was the settings backend, allowing the user to set, get, save, and load settings of various types, stored as strings. It has some limitations (e.g. no variable type specification allows for accidental type mismatch, value must be convertable to and from strings), but overall the system works quite well. It uses an array to store [key:value] pairs, both of which are strings. ​ When a setting is stored, the manager searches through the array, looking for the provided key. If it is found, its value is replaced by a string representing the value passed in (converted using ToString), failing if the type of said value does not implement IConvertible. ​ When a setting is requested, the manager searches through the array for the provided key, and, if found, sets an "out" variable to the associated value (converted to the requested type using Convert.ChangeType) and returns true. Otherwise, if it finds nothing, or the conversion fails, it leaves that value at default and returns false. This is so that, if it fails to find a setting, whatever is interfacing with it can load a default value. Relative to the above, the saving and loading are extremely simple; using the default JSON library provided by Unity, they serialise and deserialise to and from a file respectively. This file is stored in "Application.persistentDataPath/settings.json" - Unity's reference to the correct path to store this kind of information for whatever system it's built for. ​ --- ​ With that extremely verbose exploration out of the way, there's not much more to talk about. We got a lot done in a very short time, and, though I wasn't particularly invested in the project itself, I am proud of my individual contributions, and the finished product is pretty good in itself.

The main menu of the game. The scene in the background is taken from the actual game map.

Sell fish, buy upgrades, and recieve quests here!

Fishing, one of the main mechanics! Here, a quest fish is being caught for the final movement upgrade quest.

The main menu of the game. The scene in the background is taken from the actual game map.
Data
Visualisations
19/08/2022
Learning Project
This project was an exercise I did to learn about a few data structures, and how to implement them, and... well, it certainly does the job! The first structure is a double linked list, which I've depicted as a series of nodes with arrows showing the connections. It's sortable in ascending and descending order, and can be searched for a specific number. The second is a binary search tree, which I've depicted, similarly, as a group of connected nodes, and can be searched for a number, and re-sorts itself if a node is deleted. They're both rather basic, but I think they're solid examples of some fundamental concepts.




Bullet Hell
Demo
26/05/2022
Learning Project
Bullet hell is one of my favourite genres of video game, so as a learning exercise, I thought it would be fun to see how I would do making a tech demo for something of that type! The main spirit of an arcade-style bullet hell isn't exactly here, specifically things like enemies with varying behaviours, scrolling levels to fly over and such, but there's enough of the core mechanics here to call it a successful tech demo.

The green bullets bounce once off the walls before despawning

The red bullets wrap around to the other side of the screen once before despawning

The bubble bullets are attracted to the centre of the screen, and bounce off the edges. If they're hit by a player bullet, they pop, sending a blue bullet your way. After some amount of time, they pop on their own.

The green bullets bounce once off the walls before despawning
Top-Down AI Pathing
& Level Editor
26/08/2022
Learning Project
The AI portion of this project was interesting, and it was good to revisit state machines, behaviour trees, and A* to see where I could improve from my previous attempt, but the main star of the show is the level editor! The levels are stored as binary data, with a header defining the hight and width of the level in two bytes, and a main data portion in which one byte represents one tile. The file size could have potentially been halved if I had decided to use only half a byte to represent each tile. This would still give me a decent 16 tile types to play with, but the level files already took up such a small amount of space that, for this project, it wasn't worth the bother.

Demonstration of the AI Pathing as seen by the end user.

Demonstration of the AI Pathing as seen in debug mode.

Demonstration of the level editor as seen in debug mode.

Demonstration of the AI Pathing as seen by the end user.
Mario
Clone
16/06/2022
Learning Project
This project was originally intended to be a reasonably faithful recreation of the first level of Super Mario Brothers for the NES, but despite my ambitions, and the fact that I'd done a similar thing on the Godot engine some time ago, this was more ambitious than I had the time for, especially given that I spent a lot of the project time experimenting with SDL2 and OpenGL, and getting something interactive together from scratch. The end result isn't much to look at aside from Mario's usual jumping and running animations, but I'm particularly proud of the sprite and animation system I made for the project. It was an interesting exercise in the kinds of optimisation that aren't usually employed or necessary nowadays, especially when working as graphically high-level as I was. Despite the frivolity, it was interesting to explore and emulate some of the techniques a developer might have used when developing a game like this on an older system like the NES. If you'd like to learn more about the details, the wiki on the GitHub repo details exactly how it works: https://github.com/ProgrEmily/MarioClone/wiki

Mario's animations are based on how they work in the original game

Mario's animations are based on how they work in the original game
Text-Based
Roguelike UI
14/04/2022
Personal Engine Project
This text-based UI system was a project I started to further my C# skills, given that I had less experience with it at the time than C++. Inspired by a small bug fixing exercise involving a tiny text-based adventure game map, I set about trying to make a game engine that would run in a computer's terminal emulator. I ended up dropping the project after a while, when schoolwork got harder and took more of my time, but not before making what I consider to be a very well-constructed UI system. A lot of the UI is explained in the image descriptions, but essentially, the menus are all made up of individual modules that affect each other in different ways, and essentially work like self-contained windows and widgets.

The main tab of the pause menu.

The inventory displays the name, price, image, and flavour text associated with an item.

For example, if a box is placed behind another box, we would want that box to flow into the one in front, rather than being oddly cut off with white space.

The main tab of the pause menu.
Environmental Roguelike
16/11/2021
Game Project by Cert III Team
In the second year of my Cert III at AIE, myself and 3 other students formed a group to design and develop a game from scratch, using the Unity Editor. We had decided on making a roguelike in which the player has no way to directly harm enemies, and must instead lead them into traps to defeat them. I chose to work on AI and gameplay elements such as trap tiles, as well as general optimisation and code cleanup. For the AI, I decided to go with a behaviour tree system, which was a challenging choice for a first shot at AI development, but taught me a lot in the process. We had much higher ambitions than what we ended up with as the final product, but we had managed to make a functional demo that demonstrated the core ideas of our design nonetheless.

A demonstration of a few of the mechanics - stationary (green) and moving (red) enemies, non-damaging weaponry, and fire & pit traps.

A demonstration of a few of the mechanics - stationary (green) and moving (red) enemies, non-damaging weaponry, and fire & pit traps.