top of page

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

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)

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.

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.

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.

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

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.

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.

© 2035 by Progremily. Powered and secured by Wix

bottom of page