My featured projects don’t tell the full story of me as a designer. Follow this timeline of projects to see how I got here — be it through my roadblocks, my failures, or my projects that are just a bit too outdated for the main page.
October, 2023
Repair Rush, a competitive grid-based strategy game, was one of the first solo projects that I’ve ever worked on. While it definitely shows its age, I think it’s important to always look back on where you started.
Wandslinger’s Hamlet, a three vs. three third-person shooter level, was my first level-design centric project. I still look back on it fondly, as it’s what made me realize that I wanted to specialize in level design.
Moai Mayhem was my first experience working on a larger team, composed of eight developers.
May, 2024
During the summer of 2024, I was given the chance to travel abroad to Japan to work an internship for a start-up company developing Golfin, a mobile golf game that allowed players to golf on replicas of real-life golf courses.
Niji no Senshi ~ Warriors of the Rainbow was an ambitious passion project of mine. I worked on it for over the course of about a year, but it had to be out on hiatus while I focused on other things.
Goblin 9-5 was another group project I worked on during my time in college. And through the rocky development challenges, it ended up being one of the best learning experiences I could have asked for.
June, 2025
During the summer of 2025, I had the chance to intern for The Verse working on Karma: The Six Realms — a pro-social game that sought to teach using the six realms of Buddhism. While I was brought on as a game designer, I soon found myself also acting as a project manager, which was a fun experience.
September, 2025
Choo Choo Boom Boom was my capstone project for my senior year of college. As an on-rails shooter, it was a genre that I had never designed for before, and presented me with a ton of interesting challenges for me to overcome.
Specimen 001, a puzzle platformer, was my first foray in using Godot, and an opprotunity to try working on some genres that I hadn’t had the chance to design for before.
Janurary, 2026
Not many college students willingly take on a second capstone project, but being able to work on Prehistoric Pack — a grid-based autobattler — felt like too good of an opportunity to pass up. Luckily, the team felt the same about me and onboarded me as a systems designer.
Another Godot project, The Infinite Arena started as a tech demo for a turn-based combat system I wanted to use in future projects. However, as I fleshed out its systems, I decided to turn it into its very own game.
March 2026
Every year, the Fire Emblem ROM Hacking community does a single-chapter game jam. I finally had enough free time to participate in the fourth installment, so I created Vallicia in Ruin, a prologue chapter to my dream hack.
Now that you have a better idea of what my history is like, let’s start thinking about what the future holds. If you think I could help your next project be special, then click the button below to reach out!
Engine: Godot
Date: September 2025 – January 2026
Specimen 001 is a physics-based puzzle platformer that sees a small extraterrestrial that has crash-landed onto Earth captured by a scientists and subjected to numerours puzzles. Using objects such as fans, springs, and crates, the Specimen must blow, launch, and push a ball around the level to complete the puzzle. I had originally started this project for two reasons: to learn how to use the Godot engine, and to try designing for genres I hadn’t touched before.
talk about learning godot or something idk
As I said, this project was also a way for me to try out genres I’ve never designed for before, namely puzzle games. However, it quickly showed me just why that was the case. While I had planned for a full forty-eight levels spanning across five worlds, each with their own new and unique mechanics, I found myself hitting a wall with the puzzle design after only the first five. While the physical levels themselves were fine, I found it hard to make puzzles in those levels that felt rewarding, while also being solvable. The subtle drip-feed of mechanics — something which was integral to the level and difficulty progression — made the earlier levels in particular very hard to design for, as they had to be simple enough to utilize the low number of elements, but complex enough to not all feel the same. In the end, I realized that I’m just not cut out for puzzle design, a fact that I’ve come around to accept. While I have genres I definitely prefer, I can work well on so many different types of projects (evident by the rest of my portfolio, I hope). If there are one or two I just can’t wrap my head around right now, then that’s a sacrifice I’m willing to make. Plus, I got something even greater than that learning from this project — a new favorite game engine.
Position: Project Manager, Lead Designer
Engine: Unity
Date: June 2025 – August 2025
Karma: The Six Realms is a pro-social game that focuses on the six realms of Buddhism. Using prosocial mechanics philosophioes, the player would journey through these six realms and experience peoples’ issues differently in each, learning and honing skills like kindness and compassion in the process. I worked on Karma during a two-month internshop period at The Verse. The game had fallen behind their other projects, and it ended up falling on me and the other interns to jumpstart the development process once again.
As an onboarding process for the team, I worked on a one-week game jam based on one of the six realms of Buddhism. This jam could be anything — a mood board, a story, a presentation, or, what I did: a game. I decided to base my game around the Ghost realm, where beings called “Hungry Ghosts” are bound by insatiable greed, hungry, or yearning. I figured that this could be a good basis for a simple game loop where the player traverses a city to nourish a hungry ghost, who can finally be freed once it is satisfied and shown compassion. The act of performing tasks for others falls into the prosocial nature of Karma, and ended up being something we considered moving forward with in the game.
As for my work on the team proper, I ended up taking much more of a project management role. With the help of the team’s lead, I ran meetings twice a week and helped set tasks and goals for the group and individuals. Most of my time on the project was during the concepting phase, which meant that meetings mostly revolved around nailing down certain aspects of the game, such as story beats, gameplay mechanics, and art direction. Overall, it was a very good experience, and being able to hone my production skills helped a lot in the projects I worked on after, as I tended to act as my team’s scrum master.
“He combines strong technical expertise, thoughtful product vision, and genuine emotional intelligence. Ethan is an exceptional collaborator and a leader who makes every team he’s on better.”
Ben Simon-Thomas, Co-Founder of The Verse
Position: Level Designer, Scrum Master
Engine: Unity
Date: January 2025 – May 2025
Goblin 9-5 is a co-op dungeon crawler game where two players control goblins on a dungeon’s clean-up crew. During the night, while adventurers are away, these goblins verture around the dungeon to refill and restock traps and treasure, while making sure not to trigger them themselves. This is done by throwing ammunition — and your coworker — to pass objects around the pits and walls of the dungeon. As the player progresses, they unlock more and more floors of the dungeon to work on, each with its own set of obstacles to overcome.
I think one of the most interesting aspects of Goblin 9-5‘s design was how radically it was shifted through tester feedback. Originally, there was going to be no direct interaction between players as a way to incentivize splitting up when necessary. But while taking the game to a weekly QA testing session, a tester simply said “Hey, it’d be cool if I could throw the other player.” Somehow, we hadn’t thought of this before. But that week we implemented it, and both ourselves and testers found the game significantly more enjoyable. And while it did provide a decent shift in scope and design philosophy, it was definitely for the better.
However, there were a lot of hiccups with the game’s development. Due to the nature of the class this game was made for, there was a lot of shifting of team members throughout the duration of the project (it happened at least three times). As such, a lot of time was spent onboarding new people while also dealing with shifting and clashing design philosophies. There were also some issues with implementation pipelines both with art and programming. The programming bottlenecks specifically were the biggest hurdle for me, as it meant that later on in the project, we were having everyone code anything they could, just to get the game functioning. This, along with the fact that I was never really properly aquainted with the codebase, meant that while most of my code worked, it clashed with other systems and was in general just very sloppy. To be candid, this caused a lot of problems for me mentally. I had never faced a situation like this before, and it caused a pretty huge bout of Impostor Syndrome over whether I was a good designer or not. In the end, however, it only motivated me to try harder. I took the following summer to reinforce the basics and start looking at Godot to help reinforce my object-orineted programming skills. And now being on the other end of that process, I can say for sure I learned a lot, and am a better developer because of it.
Design:
Programming:
Art:
Engine: Lex Talionis
Date: June 2024 – June 2025
Niji no Senshi ~ Warriors of the Rainbow was a fan-game passion project of mine that combined two of my favorite franchises — Love Live! and Fire Emblem. Built in Lex Talionis, the same engine as Crypt of the Forgotten, I used the skills I learned from that project to start a large scale campaign with a full twenty-nine chapters (about the length of an average Fire Emblem title). Since the project was almost entirely spearheaded entirely by me, I also was in charge of the art, programming, and narrative aspects. However, naturally, I want to focus on the level design.
As a larger scale project that spanned across multiple chapters, the level design was much different than designing a single, standalone chapter. Now, I had to put an emphasis on drip-feeding the player power (new units, weapons and items, etc.), and balancing around item management and players potneitally not having certain tools at any part of the game. And since the game had a concrete narrative, being able to tie the map design into that narrative let expand the types of map objectives I could use, creating more fun maps. My personal favorites were Ch. 4 and Ch. 7, which both focused around rescuing NPC allies that were in danger, or the planned Ch. 9, which saw the player escaping from a stronger army after losing a large, last-stand type battle.
Unfortunately, I had to step away from the project for a multitude of reasons — burnout, other responsibilities, and just the scale of the project in general. Still, I learned a lot from the experience. For one, it reminded me of my limits as a solo developer. While design, programming, and narrative came easily to me, aspects of the process like art and music took a lot out of me, and were large roadblocks during development. Futhermore, it taught me a lot about the community surrounding a game, and finding a good playerbase. I drummed up support for the game on my social media, but quickly ran into the issue of actually distributing it. I originally chose Lex Talinos because the alternative of ROM hacking has… some legal issues when it comes to easy of distribution. But Lex Talionis also had similar problems regarding the necessary technology literacy to run the build, which made even outsourcing playtesting a bit of a chore, which was a large part of why I decided to stop development. Still, the game was a good experience, and I don’t regret giving it a shot. And who knows, maybe the project will see the light of day again. I’d like it to, at least.
Position: Project Manager, Generalist Designer
Engine: Unity
Date: May 2024 – July 2024
Golfin was a blockchain-centric golf game that sought to combine real-life golf courses with NFT technology to allow people to train their golfers as they played through a campaign and tournmanets. Additionally, thanks to GPS functionality, players would be able to gain rewards while the golf on the real courses the courses in the app were based off of. I worked on this project during a travel abroad opportunity to Kyoto, Japan, and… it was an interesting experience, to say the least.
As I said, Golfin was eveloped using NFTs and blockchain technology, two things I’m not particularly fond of. Beyond that, however, there were a lot of hurdles with how the game was being developed, primarily because the shareholders and higher-ups at the company were seemingly more focused on theoretically generating income, rather than making an actually good game. I think the mechanic that best symbolized this was their proposal to have characters — linked to NFTs, mind you — die of old age, leading players to have to buy more. Not only is this simply not how NFTs function, but I found it extremely predatory. As such, myself and the other intern I was working with spent several weeks designing and pitching systems that found a balance between engaging gameplay and monetization. We eventually landed on a system where characters would age, but still remain usable. Through aging they would learn skills, and you could pay to “prestige” back to a younger age bracket to get more skills, or stay there to influence your stats in different ways. While still monetizable, it left things a lot more up to the player, and didn’t lock people out of the game just because they’ve been playing for a while.
While I wouldn’t trade my time in Japan for the world, my time spent on Golfin definitely could have been better spent. Since, the company behind the game went under and since we weren’t able to keep any of our documentation, the game itself and this website are the only surviving records, for better or for worse. Still, having to deal with monetization and balance the needs of the game with those of shareholders were both very good experiences, and ones that could be useful in the future. I also got to meet a few really cool people and, of course, travel abroad in Japan. I could spend forever talking about how much that changed my life, but instead I’ll just leave you with a few of my favorite pictures from my time there.
Position: Level Designer
Engine: Unity
Date: October 2023 – December 2023
Moai Mayhem is an educational exploration game esigned for 1st – 3rd graders with the aim of teaching them about the Moai statues found on the island of Rapa-Nui — more commonly known as Easter Island. By exploring the different areas of the island, players will learn about the statues’ history and presence on the island.
As one of my first large-group projects, not only did this project teach me more about my role as specifically a level designer, but also the importance of creating good, readable documentation for the rest of the team. At its core, the level design of the game was rather simple, as it is designed for younger children. I still had to make sure key points in each level were spaced apart and flowed well together, but the overall designs were rather simple and had a focus on representing the culture and landscape of Rapa-Nui. Despite the simplicity, however, I still had to make a number of documents for the game, including a Visual Design Document and level diagrams, so that the team could stay updated on the game. I tend to enjoy making documentation for my projects, but working on a team rather than a solo project forced me to make the documentation not just understandable to myself (though I try to keep it organized regardless), but to the rest of the team as well. You can check it out below — I’m proud of it, looking back.
Not only was the experience of working on a educational game a very interesting and fulfilling one, but this project holds a special place on my heart because a lot of the people I worked on this project with ended up being teammates on later projects, such as Choo Choo Boom Boom. So make sure to check out their links below, since they’re an extremely talented and amazing bunch of people.
Designers:
Programmers:
Artists:
Sound Designer:
Engine: Unity
Date: October 2023 – December 2023
Repair Rush is a competitive, one vs. one grid-based startegy game where players command armies of robots to capture properties and take down the other player’s army. For this project, we were given a theme and a genre, being a turn-based strategy game with the theme “As Good as New.” This made me think of how turn-based strategy games like Advance Wars and Wargroove allow you to recover units at owned properties. Contextualizing this as robots being repaired, I landed on the idea of Repair Rush.
Up until this point, I had ony made very small, basic projects — think simple maze games or vertical shooters. Comparatively, a grid-based strategy game was far more complex than anything I had made before. But I’m a person who loves to push himself, so I was up to the task. And in doing so, I felt like I learned a lot about the game development process, and what goes into make a grid-based strategy game specifically. I think the most important skill I learned was how to use Scriptable Objects, which is what I used for all of the units in the game. This wasn’t something that was ever covered in any of my college classes at this point (and never was, unfortunately enough), so learning on my own ended up being very useful, especially when I eventually started using Godot and its Resource system. Beyond this, it also taught me a lot about how to utilize tutorials during game development. I used them a lot for the core systems of the game, but a lot of the more complex systems either weren’t covered or weren’t compatible with the provided code, meaning I had to break away from the tutorial and figure it out myself. And this may seem basic or obvious, but I’ve seen a lot of newer developers get too focused in on following tutorials to the letter, which can often lead to code they don’t understand or utilizing techniques that are way above their skill level. So, I’m glad I avoided that habit early, as it has helped me a lot, given the wide number of engines and systems I’ve had to work in so far.
While the project definitely shows its age, I am very proud of how it turned out, given how new at game development I was when I made it. In fact, the whole reason I made this “My Story” page was to highlight projects like this one — games that don’t fit well anywhere else in my portfolio, but I think are still worth reflecting on. After all, it’s impossible to know how far you’ve grown if you can’t remember where you were when you started.
Bachelor of Science Degree In Game Design
Champlain College, Burlington, VT
Hard Skills
Tools & Software
Project Manager/Game Designer, May 2025 – August 2025
The Verse, Berkeley, California (Remote)
Project Manager/Game Designer, May 2024 – July 2024
Wonderwall, Kyoto, Japan
Choo Choo Boom Boom, In-Scope Studio, Expected May 2026
Level Designer/Scrum Master
Prehistoric Pack, Bonepile Studios, Expected May 2026
Systems Designer