This is my projects page. Here you’ll find examples of different games and ideas that I’ve worked on as well as information learned from the experience.
Flutter Firebase Todo
A CRUD Flutter todo project that utilizes Firebase. Mar '24
- Dart and Flutter set up.
- This project required multiple sdks to be installed and modified, which pushed me to become comfortable with command line/terminal navigation and use.
- How to use Google Firebase:
- Storing, retrieving data, and userbase authentication can all be done using Firebase as a framework. I’m sure I’ll be using this again in future projects.
- Separate builds for web and mobile:
- This was primarily developed as a mobile app. The web deployment was an afterthought that was done quickly through Android Studio. If I were to build this again, I would have a separate focus to build this as a web app.
Skømp
This is one of my favorite projects created for Ludum Dare 43. Dec'18.
- Controlling Scope of the Project:
- This project taught me that creating a minimum viable product and then polishing that product often lends for a better gameplay experience as opposed to adding additional features.
- Using Unity’s grid and tile mapping:
- In this project, I learned how to make the most of Unity’s tile mapping. This was utilized for gameplay platforms, foreground, and background to create parallaxing effects.
- Using Unity’s animation system:
- Animation triggers were used to change the player’s rigged body from walking, jumping, and climbing. We also configured movement speed to adjust the animation frame rate change to better showcase momentum.
- Continuous 3rd Party Play-Testing :
- When working on level design, it is easy to get so comfortable with the controls and desired inputs that you can accidentally scale the game into something more difficult than your target audience would likely be comfortable with. Having continuous play-throughs from a non-dev would likely provide proper feed-back needed to correct this.
HARVESTER SALOON
This was a submission for Ludum Dare 52. Jan '23.
- Integration of 2D Art in a 3D Environment
- Utilizing sprite-based art, we aimed to simulate 3D movement. Managing perspectives when the player moves within the bar proved particularly challenging.
- Implementation of Cinemachine Cameras in 3D Spaces
- We employed multiple cameras in the project to switch between different scenes, altering the game’s atmosphere. This skill has been invaluable and frequently used in subsequent projects.
- Maintaining Faithfulness to the Source Material
- While adhering to the original concept, we deviated from the movement mechanics of the original ‘Tapper’. This resulted in unintended alterations to the gameplay experience. For future rebuilds, I would retain the original movement mechanics to preserve the intended gameplay.
CENTIPEDE CLONE
This is a clone of Atari's Centipede © 1981. Created in Unity. I worked on this project Dec '22 - Jan '23.
- Collision Detection and Handling:
- Overcoming challenges related to accurate collision detection and response in a 2D game environment.
- Passing Back Information in a Linked List:
- Implementing a linked list structure to manage and pass information, specifically the centipede’s segments and their behavior.
- Using coroutines in the Game Manager:
- Needing independent timers for game objects not yet instantiated required the use of coroutines to efficiently spawn enemies.
- Player movement controls:
- Because the player movements do not require engine physics, creating colliders for the environment proved to be difficult while still maintaining smooth movements. If I were to recreate this project, I would like to start by examining different options for these controls. A raycast might provide a cleaner collision detection method.
ATOMIC COMMANDER
Inspired by Atari's Missle Command © 1980. This project aimed to take the gameplay of the original and apply it to a larger arena. Created in Unity Feb '20.
- Player movement controls:
- The player rotates around the globe in response to the position of the player mouse. The controls ended up working better for touchscreen devices.
- WebGL resolution & sizing:
- As an unforeseen issue with having the controls based off the mouse position, the screen size created extra difficulties when deploying this project in its WebGL format. Any non-native browser zoom settings will make the controls unusable.
- Randomized enemy spawning positions
- The goal was to have enemies spawn at random times from outside of the player’s view. Creating this randomization by using X & Y coordinates was a challenging learning experience.
- Sticking to a single control method:
- This project ended up feeling much smoother in touchscreen devices. However, the mouse controls seemed to suffer because of this. If I were to rebuild this project, I would only implement a single player control method from the beginning.