Growing Up

Gaming has always been a passion for me; now, I know most people say this, not very original, but I only started to realize what it could be whenever I started adapting stories I wrote into playable experiences. RPG Maker became the tool that allowed me to create my 100s of pages of stories into bite-sized chunks that I could put in front of people.

I didn’t know what a switch was, how to balance values, or anything like that, but I did understand how to make quirky dialogue in dialogue trees, meta narrators, and how to hide a good easter egg. Even though these games weren’t anything to write home about, I still roped my friends into making their own games on RPG Maker, and built connected stories. My friend, Jacob, taught us other tips and tricks since he was already coding and it became a great gateway into my life as a programmer. I realized during this time that even though RPG Maker was a basic tool, that great games could be made with it such as one of my favorite games: To the Moon.

Around this time I also discovered other 3D engines and ways to bring my games to via free software like Blender and UDK. Jacob and I built out shooting games in Blender, via the scripting language and when we found that to be only so impactful we dove into Unreal’s Development Kit. I scoured the documentation, the web, and the files themselves in little ways to modify the game into a shooter that I saw fit: I adjusted firing rate, bullet effects, changed maps with BSP brushes, and I remember building an intricate mine of glowing white moss.

High School

When I got to high school I got my first taste of “real” programming. I took a Java class with Jacob, and we dove head first into expanding our game dev ambitions. For our final projects we made “Nex Castellum”, a tower-defense game where players create their own labrynthine paths to the center of our structure. Jake and I were the perfect team as we put together our technical and creative juices to make a unique tower defense that made it so that you could force the enemies down one corridor and then change the path on them.

This game featured flame turrets, homing missiles, oblong blocks to create longer paths, bullets that dispersed into different shape, and more. The them was a zombie apocalypse that started upon parasites crash landing on earth, which then in the 11th hour of the game players realized that this was the first wave of an alien attack, evident by our cheesy alien sprites. This game was a part of our final project and it was terribly balanced, it chugged once you got too many enemies on screen, and there was no win-state… but it was a rush. Unfortunately, my flash drive with the game broke and I lost the screenshots of the game, but it was empowering to know that I coded the experience and it gave me a greater sense of self-esteem. Aside from creating your own zombie death maze, the game had some pretty sophisticated pathfinding given our skillset and “charming” sprites and artwork. It is the kind of idea that I would love to revive at this point in my career and put on mobile or steam.

Aside from working on this, I also made a game for my friend’s science research paper that eventually went to the Intel International Science and Engineering Fair that was held in Pittsburg: Article Here. I made a simple game that was inspired by Guitar Hero and other rhythm games that allowed you to move your character up and down on a staff of music. Once players make contact with a note, players would have to sing the note correctly before they could proceed. This expo featured a live demo, which was extremely stressful, but it was an honor to be included alongside the works of so many young scientists.

Undergraduate

Undergraduate was an interesting time for me. Not only was I still playing football, but I was trying to continue my theater career as well. During that time I transferred three from Mizzou to Missouri State University to Evangel back to Mizzou. This was just to continue my playing career with the return to Mizzou being due to an injury and realizing that I needed to prioritize my future career and ambitions with some longevity. So I returned to Mizzou, hung up my cleats, and started to see that programming was the common thread between all of my schools, which set me down the CS path.

While pursuing the CS path at Mizzou, I realized that the major was so packed that I wouldn’t be able to take as many electives if I did CS directly, so I took our Information Technologies track because it allowed me to take an app development course, a networking class, two modeling classes, a cybersecurity course, a game development course, and a VR course. This was the right choice for me considering my interest in too many things, and it was doing this that I found that game development was my passion and the perfect intersection of creativity and technical prowess.

Working with Professor Wang

Taking these courses I met Professor Fang Wang, who became something of a mentor for me during my remaining years at the university. I took as many of the game development courses available, became her PLA(peer learning assistant) where I assisted other students learning Unity, I helped co-found a VR Club, worked as her undergraduate assistant where we made VR Clean Room applications, social work apps, we presented MR and VR experiences to children all across Columbia, and we even collaborated with the football team by developing tools for the QBs and coaches to use in tandem.

In our VR Club, we hosted game nights and also started on some development of game experiences using VRToolkit. We really discussed all things XR and helped work on an AR experience for the Engineering Department and we collaborated with a local VR entrepreneur to test out new equipment and help her with her projects.

App development & Competitions

Aside from games, there were a few applications that I was proud of during my undergrad. One was the app development course mentioned above, which was a cross-disciplinary course that had journalism students collaborating with developers to build applications in XCode. I worked diligently on a baseball stat tracking app for amateur and youth sports teams so that novice statkeepers could better track the statistics of the game. We presented our work to an eclectic panel and it was here that I really learned the value of presentation in addition to product. For a long time I had been prioritizing my technical skills, but this was a reminder that being an eloquent speaker and the ability to sell an idea is an invaluable thing.

I worked on a social media application that allowed users to find events and other users on college campuses sorted on interests called Current. This was my magnum opus application, and like most dream projects I bit off a bit more than I could chew. I did work with a interdisciplinary team and we pitched it in an annual competition and advanced to the semi-finals, but fell just a bit short. Similarly, I worked on an application for another competition that got 3rd place for the incubator competition in town and that application was a law tool that helped you find pertinent rules, codes, regulations, and laws given your location. I will forever value the hard lessons I learned in failure and having too big of an idea. It was a humbling experience to not win some of these competitions whenever I thought I had a better idea, and I learned the place of market validation, and making presentations accessible to my audience rather than overly technical or verbose.

Super Splash Bros. / Splash Attack

During my final years at Mizzou I participated in a Game Jam with some of my classmates. This was my first experience that probably looks like most other game jammers’s first time: hectic. Our theme: water. We didn’t really understand version control, Github caused us immense issues because it hadn’t yet implemented Unity standards, our team was a bit over our head; unlike most people we actually won. GRANTED, there were 4 teams, but we were very proud of ourselves. The theme was water, and I had the idea of calling the game Super Splash Brothers(this was before the Warriors so I was proud of myself) and the idea was that you were playing in a water gun fight on a map inspired by the sewers in Super Mario:

AUDIO

MHS

I finished undergrad and decided to try and go after my masters at Mizzou. Joe was able to get me a GRA, work as a graduate research assistant, that reduces tuition virtually to zero. Really, this was just an excuse to clarify that games was where I wanted to be and it allowed me to get paid and get a degree while I did it. I came on as a programming GRA on an enormous game that was already years into development, a game with millions of dollars earned via grants, Mission Hydro-Sci(MHS). My focus at first was to help develop cinematics in the game because I had some experience with Cinemachine, Timeline, and making some animations. Little did I know, that this seemingly simple task would be an enormous challenge.

Mission Hydro-Sci was a serious game developed by Adroit Studios, a research games lab out of the University of Missouri-Columbia. The team had made a semi-open world RPG about colonizing an alien planet after your space station malfunctions. Players will learn about watersheds, topology, animal life, and more while they solve puzzles, build a base, and explore a world akin to Earth, but in other ways, drastically different.

But back to the challenge of it all. This was the first project that I worked on that was a massive scoped project made by people who were learning as they went. Now, there is nothing wrong with that, and I can attest to my own projects that I have worked on in my own time(no need to look further than an entry up), but this was the first project that showed me the cautionary tale that is building on a shaky foundation.

MHS had very little continuity aside from the creative director, Justin Sigoloff(a dear friend) and Joe, but aside from that there were probably 30 other people that had been on the project at some point or another and now the team was down to 1 artist and 4 programmers including me. The project had a ton of bloatware with various scripts, add-ons, plugins, and components on GameObjects and in the project that no one was sure what they were doing or if they could be removed. Since this was a serious game there was a robust logging systems to help researchers attain data, but this meant that there was a lot of extra complexity to systems such as saving and checkpoints to accomodate this.

Scenes were constructed in a way that was conducive to collaboration(akin to how games like Firewatch that abstract out quest items and interactables from the environment so that the art team and coding team can work concurrently)but still there were some collisions. We used Perforce which was a valuable experience, but in some ways it was a half-measure and during intense milestones it meant that we still ended up throwing out work or overwriting the work of other people.

Now, this isn’t to say that the game was wholly bad or that the team was in the wrong, this was a multi-million dollar game with plenty of chefs in the kitchen: bosses above the game team that didn’t like games or understand how it worked, faculty that didn’t believe in the cause or the attention this project was earning, SMEs(subject matter experts) that prioritized content over, well, the content of the game, and others. There was turn over during the project, workers of various skills, prototypes that made it into the final game, some items that were reworked more recently than others. I learned a lot about the history of the project, but when I joined it was time to start contributing.

To add all of the cinematics in I first had to play the whole game and I was amazed at how long the game was. There were 6 units, with each lasting anywhere between 20-30 minutes Your character started on a shuttle, crash landed on an alien planet, had to locate their friends using topological maps, support their hypotheses with scientific argumentation, establish a base, discover pieces of the wreckage, find pollutants running off into the watershed, solve puzzles in ancient alien ruins, plant super nutrients to energize plants, experience the shift changing of water, and go on a final mission to save the planet from imminent destruction.

Playing through the game I found several moments that felt like they could benefit from cinematics: establishing shots, character introductions, suggestion of a mechanic, and more. This became a way to break up the gameplay and give an overall more cinematic experience. But the rub was that there wasn’t really a way to add in cinematics currently. My job was to investigate the dialogue system and the quests imbedded inside of GameObjects to try and discern places where this could be done.

After a ton of experimentation and figuring out Dialoguer, I was able to figure out how to enter in these small moments. For each moments I needed to freeze the player, transition cameras, hide unnecessary items, set up set pieces, add new items, progress the quest, and more. This experience gave me a comprehensive view of the project and was helpful as the team started to dwindle.

First, one of the junior programmers left, and then after a few months the lead left, and then after him the other programmer left, leaving just me. My task transitioned from making cinematics to bug fixes and other QoL changes. One of the major improvements that we wanted to add was VO for all of the characters. So during this project I became the VO Director. I found actors for all of the characters in the game, consolidated the lines, wrote new dialogue, coached performers, found an audio engineer, and implemented all of the dialogue into the game. This was a herculean task, but something I ended up being proud of because it gave the game more characterization and personality.

At this point, the team wanted to add in minigames and other side quests in the game which became my next focus. I added different animals across the different maps, blueprints to discover, alien tech to find, and other objectives for the other young cadets in the game. Each had their theme and quest line to progress, and each of these quests evolved the base in some way: new buildings, improved structures, new species of wildlife exploring the base, extra dialogue, and technological advances such as hoverboard speed increases.

The biggest hurdles during this were that our quest system wasn’t really designed to have quests that progressed in this way, i.e. quests that only appeared at certain points, that could stack if you had already collected enough items, that only revealed at certain points, etc. Along this line, I had to find workarounds that felt the same to players but were a bit hacky on the code side.

Along with this, I added little props in the base that players could interact with such as a volleyball to hit around, a basketball hoop to shoot into, and a hoverboard course to jump around for example. I had plenty of ideas of bigger scope, but this was a great way to practice paring down scope and coming up with compromises that could make everyone happy.

I was responsible for anything technical at this point such as creating new builds, version issues, Perforce problems, systems that I had never interacted with before, and more. It was daunting, but also liberating; even though I didn’t create every problem, I had means to solve it, and I definitely had hiccups along the way but I was the person on the team that was responsible for it. Perfectionism has always been a bit of an issue for me, and it was hard to accept some of the issues with the game, but I learned to be proud of c0ntributing to a large project and how hard it is to make virtually anything. I think we all have a bit of ego death when you realize how difficult it is to make games and commendable it is that we as imperfect people make anything.

After a few more months of work, my bosses wanted to move major versions in Unity and we brought in a consultant who I onboarded and worked close with, revealing to him any and all issues that I had found in the project. We worked alongside the lone artist and did a ton with LODs, finding bloat in scenes, occlusion culling, reducing object count, removing superfluous effects, cleaning up databases, and trying to catch anything else that would impact performance.

This move was complicated, and it broke a lot of things along the way, but it was a good last hoorah for me.

Long Play – MHS

Other Adroit Games

My next major project I worked on with Adroit was the Relevate game. Relevate was a modern take on a data entry app, where players are being interviewed by a sassy alien who is learning about human culture via various questions. This slight theming made it a bit more engaging and fun than answering your height and weight for the 1000th time on a form. This was a seemingly simple game, but it had me interacting with other development concepts I hadn’t had to use in awhile, forms, MySQL, backend, databases, and other webservices. This project got me familiar with running Unity games on mobile, different touch controls, and sending users an email via code.

The next project I worked on was Forecast, an application that was used for social workers to help train teachers what types of warning signs to look out for.in their students. This was another application that dealt with social issues, which are important to me because my mom was a Juvenile Officer in cases of child abuse and neglect. Being able to make games/experiences/art that can affect people is my main goal and I love that I am in an industry that can do that. Forecast’s main challenge was creating a rubric and a way to assess players to gauge not only if an answer is right or wrong but to what degree that answer is right or wrong. So I developed a formula for the 20+ questions that accounted for the type of the answer, the amount of correct an answer was, and more all of this parsed together with an Adventure Creator based front end. This dialogue system was a bit simpler, but it had its limitations and we had to find some creative solutions to make sure that questions connected to the right one given how players had answered their prompts.

The final project I worked on during my time at Adroit was a proposals for Pro-Social was a narrative game that taught students how to regulate their emotions in social settings like school. I was the developer, designer, and producer on this project and during this time I instructed the artist on the UI, models, and animations that I needed to make this demo happen. In the demo, the player was a grade school student that is trying their hand at some basketball. Players learn how to move and they get to shoot by themselves a few times before moving on. Via a custom dialogue system, the player had to make split second decisions to practice how to respond to bullies or underachieving students.

It was a short demo, but our work in conjunction with the grant work earned us this project worth over 1.5 million dollars. This honestly was a good note to leave on, but I knew that greener pastures were awaiting me.

Starting at Gold Creek

The next step in my journey was Gold Creek, a small studio out of Des Moines, Iowa that was started by an alumni of my high school, Houston Brayton. Justin was a family friend of Houston and the two realized that they could work together to make better games and I wanted to be a part of that deal as well. During my interview process I was tasked with developed a slot machine with extra features such as max betting, winning from different angles, speed up and slow down feature, I built this up in a night in Unity and then I spent the rest of my time learning Phaser, which was the engine of choice for Gold Creek.

I had heard of Haxe and Typescript, but this was really the first time that I had done much with it because webdev was not my strong suit(I only took one class). So I ramped up as quickly as I could and I was thrown in the deepend fairly quick at Gold Creek. See, what I liked about Gold Creek is that we would be working with prestigious brands like Nickelodeon, Cartoon network, Disney, and others on projects that needed to be good because they were commercial. Now, we all know that not every game commercially sold is “good”, but on the face of it that is the intent of these types of games. That’s what I wanted to work on, branded games and indie games with a team of people I could learn with, grow with, and overachieve with. Gold Creek was a convenient, remote opportunity that allowed me to have a bigger cut of the responsibility pie, and I am happy I took that bite.

It was here that I also got to redeem myself with GitHub. I had used it in some classes after my initial run-ins and got a better idea of how it should be used, but it wasn’t until I came to this company that I really figured out a more efficient workflow with multiple people using branches. GitHub is now my preferred version control system for its accessibility, branching, and interface.

Nick Jr. Games

The proverbial deep end; Nick Jr. was our biggest licensed client and we were famous for making them what would end up being some of their most popular games: sandboxes. I helped put a bow on the Blue’s Clues & You: Time to Play Store a Toca Boca-inspired game that featured Blue and friends across a food market, a toy store, and general store. Players could interact with various items that we developed using our proprietary ECS… system. I built maps using tiled and created new components for ECS so that all objects and the games could benefit from them. Typescript was a lot more laxed than I was used to, but I enjoyed getting to fill that gap in my knowledge. For years, I had been seeing Javascript code in parallel with C# code, but now was when I started to understand the format and expectations of the programming language.

On games such as store like Blue’s Clues & You: On the Farm we have been nominated for several Kidscreen Awards and with Store we were one of the highest played games in the Noggin ecosystem. We signed on several projects and after this one I was deemed ready to lead and I lead the design and programming on another Noggin game: Kinderwood: Feelings and Friendship.

On this game, I got to really showcase what I could make in a vacuum, managing myself, collaborating with the client, creating interesting SFXs, setting up various scenes, making QoL design decisions, and implementing VO. At this point in 2021 I found Replica Studios and for the first phase of testing we were able to save significant time by utilizing robo VO until Nick Jr. provided the final one. This was a game with a real quick turnaround, but I got more experiencing working directly with the team at Nick Jr. which was cool to engage with properties that young kids were interacting with, but also their expectations and schedules were no joke on the Noggin side.

It would become a recurring issue, but the producers that we worked with on the Nickelodeon side were also under a lot of pressure and that drove up the anxiety of the entire team. I learned here that it is important to develop camaraderie with the ENTIRE team and I tried to do that on projects from there on out.

My next projects was Paw Patrol: Adventure City Rescue which I helped develop one of the 3 minigames. I worked on the heist based/motorcycle chase game. With this game I got to try my hand at some more level design and procedural generation balancing. I worked with CSVs and created several small chunks which then got stitched together to create seamless, less predictable chunks. The biggest issue with this project was how many fun mechanics were removed because the game was feared to be too difficult. See, at Noggin they do a lot of playtesting with children, but because their target demo is so young and the conditions of test are less than preferred, we often have kids giving random feedback which leads to our teams trying to scramble to accommodate a knee jerk reaction to one errant feedback. This game was going to have more power-ups, speed-ups, hazards, broken down parts of the track, but it was so simplified to remove multiple colors of keys and anything to give the game a bit more flavor. This was probably the moment where I really figured out that design was my calling. I was disappointed in putting out a game that I knew we could have done better, if more prepared and that was when I wanted to really start being a part of that decision making process.

The other Nick Jr. titles I worked on were:

• Santiago of Seas: Secrets of El Bravo
• Blue’s Clues & You: Showtime with Rainbow Puppy
• Blue’s Clues & You: Fun on the Farm
• Paw Patrol: Save the Ski Lift

Expanding Horizons

My second wave of projects were when I started getting to work on more proposals and start designing. One of the games that I got to spend a lot of time coordinating, assigning tasks, balancing values, and checking copy was on John Deere: Gain Ground. This project was an infinite runner mashed with a tractor competition minigame. The game was a glorified marketing tool to sell the See & Spray, but it became clear to me that our team really benefited from having someone facilitating others, especially someone with some technical know-how and the ability to communicate with anyone on the team.

With our John Deere game we took inspiration from a game that the client wanted us to reference, which was hard for my ideating brain, but I conceded that most people playing this game wouldn’t be games and it took me back to all of the user experience testing we did in Grad School, which had me assessing the way that older individuals interfaced with websites and application. So we kept the games simple and tried to really showcase why the John Deere items were so impactful and worth buying by making them overpowered in our game.

Adventure Academy

A small section, but I was thrilled that one of the connections we made was with the MMO Adventure Academy on two of their minigames. On Rapid Race, I playtested the game, gave feedback met with the team on the initial meetings, balanced some values, and around this time I transitioned exclusively to designer. On Code Island, I also participated in the original meetings for this project, worked on documentation. This was a great opportunity for our company to prove itself and to get to work with a bigger company on a game genre that usually we would overlook.

Rapid Race

Code Island

Adventure Academy Rapid Race promo

Playside

Like Adventure Academy, I worked on two games with PlaySide Studios. The first was Fantasy Warfare: Legion battle, a reimagination of the autobattlers that the company has made before where we reskinned the experience, tested it, and tested out newer features. For this game I got to redesign all of the abilities, name characters, playtest missions, and get familiar with the layout of the project. This was a sweetspot for me; I got to think of wacky abilities, characters, bosses, and more, but again, I practiced restraint by not blowing up the scope of the game by not adding new character types and abilities. This was a drastic art venture and I definitely spent some time helping with the documentation for the Art Bible, checking that tasks got done in time and assigned out.

The other project that I assisted on for PlaySide was Dumb Ways to Draw 2 which was a sequel to the wildly popular series. Our company was contracted to create new puzzles, themes, and more. Even though I was busier on the list of projects as a part of the move to 1PXL, I still did a bit of playtesting and worked with the artists on a few levels.

Today

1PXL

1Pxl is a company associated with Gold Creek and it is the combination of Gold Creek’s team and 1st Playable’s team. We have worked together on various proposals, we’ve assimilated culture, released multiplatform games, and are working on new projects right now. It has been a process of learning new tools such as SVN, which is closer to Perforce in my experience but not quite as intuitive. Working with 1PXL I also got used to some new aspects of development such as scoping, content management systems, extensive prototypes, weekly reports, Mini-GDDs, documenting calls, and other responsibilities. During this ramping up, I learned a lot of how and why another company has arrived at certain conventions and it became clear to me what aspects of the companies day to day that I would like to be preserved.

Pickleball Smash

Pickleball Smash is an arcade, multiplatform, multiplayer, pickleball game published by GameMill Entertainment that can be found on Amazon or bought at Targets, Best Buys, or Walmarts. On this project I was the lead designer and this was my first console release and it came with a litany of unique challenges and lessons.

This was an interesting project for our team just from the start. We moved from one publisher to another at the beginning of 2023 and after a successful pitch we went full speed ahead on this project. We worked froughly from January to August on the project with a bit of pre-production beforehand. With a small budget of <500,000 dollars, and a short timeline considering the multiplatform target, we had little margin for error and plenty of places that we could have misstepped. Even though the game won’t sell a billion copies, it was a great experience, and it helped shape my experience as a game designer in this industry.

Starting off, I had little exposure to pickleball beforehand. I had a family friend, Sherri, who played regularly, but aside from that I didn’t have a major connection. I tried my hand at tennis growing up, but I was better at hitting the ball out of the court rather than keeping it in play. But I did enjoy sports games, especially the Mario Tennis games and Wii Sports. Sports games have always come fairly naturally to me with my favorite ones being the Madden series and the fantastical Mario Superstar Baseball.

Now simulations are great, but in my opinion a game that makes bold design decisions that prioritizes the fun(like Mario Superstar Baseball), will always pique my attention. So, when this project came up I knew that I would do everything I could to make sure that the game felt more like an arcadey, wacky experience rather than a hardcore sports simulation.

There were quite a few expectations for this game:

• Multiplayer
• Multiplatform
• Leading Platform = Switch
• Customization
• Built around pre-existing 1PXL tech
• Motion Mode
• Minigames

As a team, we deemed that Mario Tennis Aces was our closest competitor. But this brought up an interesting aspect: would a pickleball game actually play like tennis? The immediate answer was yes, just on the fact that it was a racket sport, but that was when I began diving in trying to understand what pickleball was, how its rules facilitated its different gameplay, and ways that we could differentiate it from tennis games.

The main differences between pickleball and tennis starts with the ball. The pickleball is bigger, but lighter, given that it is similar to a wiffle ball. This means the ball floats a bit more, and because the playable space is smaller and the ball can only be served underhand, the maximum speed of the ball is definitely lower. This has opened up to at first a more casual audience, but it has become more and more popular and a part of the zeitgeist more and more.

As mentioned before a pickleball court is significantly smaller, than a tennis one meaning that players don’t have to move as much to cover space which puts less stress on the joints, This makes sense why this game has skyrocketed in recent years, it is a game that is familiar but optimized to work in badmitton sized areas.

The last notable difference is the non-volley zone, i.e. the Kitchen, which is an area right in front of the net that players aren’t not allowed to stand in and hit the ball.

After reading through several rulebooks, watching professional games, and interviewing players, I started stubbing out some initial gameplay ideas. I was really drawn in by the concept art that our concept artist drew up for the characters as seen below:

These characters, to me, spoke to the array of ethnicities, age groups, and backgrounds our publisher wanted to represent. See, even though pickleball skews older, the sport is picking up in popularity with different groups and our publisher and producers wanted to make sure that we tried to frame pickleball as exciting and accessible. I was under the impression that we should lean into bespoke, pickleballers from a range of demographics.

Whereas games like Mario Tennis Aces has the benefit of a cast of memorable characters from across the years, but in much the same way, games like this can benefit from archetypal, easy to read themes for characters and that can help us stand out in the marketplace. I proposed a story in a world where pickleball is the big thing and the most popular sport in the world. Not a joke exactly, but a hyperbolic version and play on the fanaticism of the pickleball craze. These characters would be one part pickleballer and one part professional wrestler with gaudy costumes, moody personalities, bombastic egos, and special techniques given their theme. This felt like a nice compromise and a tongue in cheek/meta approach to making a pickleball game.

Each character would have had unique skills such as a Racket, a punk rock player with a penchant for cheating, or Chef Fala Phil(falafel), a chef that likes to play close to the kitchen. These characters, inspired by pickleball terms and puns, would have been ultra stylized caricatures to teach real players the archetypes of the sport while really doubling down on wacky abilities. For example, astronaut Dink could send a ball into the lower atmosphere with his special, while Dilly, a cowpolk that is the quickest shot in the west, could cause the ball to ricochet like a shot in a spaghetti western, making it extremely difficult for players to catch it off the rebound.

One concern posed by this approach was the idea of representation and “harmful stereotypes”, but I was a big proponent of using these characters to represent a wide swath of people and cultures while being intentional not to be offensive, i.e. honoring and truly representing folks while embracing a goofy vibe overall. Ultimately, our team decided that it was best to not do a roster of bespoke characters, but instead our boss thought that giving players customization options would be the best compromise.

In the final game, players can create their own characters, and customize their appearance via options like hats, hairs, skin color, different outfits. Aside from aesthetic changes, players can improve their character over time on different categories of stats such as

Speed
Power
Defense
Finesse
Placement

Each of these categories is rated 1-5 and based on whichever skill a player prioritizes this correlates to an archetype or playstyles of such as “Speedy” and “Spinemeister”.

These stats contributed to different ways that the player functioned such as their accuracy, the amount of curve they could put in the ball, the power of their uncharged swing and more. I worked with the gameplay programmer on this project closely as we developed how players could aim within the court, the different types of swings, the types of curves to use for charging, the apex of shots, and the general rules of the sport. I both documented and peer programmed these systems so that we had as much control and fidelity as possibly as a designer and gave technical support to the programmer and SME insight. Granted, I didn’t know everything, but there was places where pooling our knowledge together and intuiting how the system should work was important. For example, certain swings can only be used in certain situations, for example a player cannot serve overhanded in pickleball, so a smash was not going to be possible at that point.

We utilized a CMS to try and capture as many data points about the different types of shots, which were a curve, a volley, a dink, and a drive and how those shots operated as players charged up their swing. Certain swings needed to constrain within the court while higher risk shots needed to be penalized if the players relied on them too often. It became a big venture to balance the game and find this interplay of how each of the shots worked both on their own and with different statistics.

Aside from balancing the shots, I was also responsible for creating the different statistics for the AI. We quickly realized that AI characters would require difficulty modifiers and tendencies. So I worked on giving characters preferences on the types of shots they liked to use and the situations/conditions they would use them. For example, creating a character that ramped up in difficulty over the course of the match could be accomplished via conditions like adding new shots after the score reaches a specific threshold. The programmer and I spent a lot of time coming up with ways to give the game as much expression in this way, but there are some things that would have been nice to do. For example, sometimes character became a bit predictable if you were able to identify what their theme was, and the frequency of using some shots could have been tuned better to give characters meaningful themes. Some of this had to do with the location logic and if we would have spent more time on it then we could have had characters that dinked the ball more often or characters that stayed at the very back of the court but aimed towards the front for example.

At one point, we were at an inflection point and we needed a bit more juice for the game. We had the basic rules of pickleball implemented, but it wasn’t as engaging as it should be; so I pulled from earlier references of the game, and we implemented special abilities. At one point, I wanted to give players the 4 main shots, variants of those shots, and a special, but I noticed during playtesting the issue that players had all of these different shots but they weren’t using them. Yes, they had purpose and functionality in a meta that I was envisioning, but it became a bit of cognitive overload. That, plus the fact that there wasn’t really anything flashy made the game feel a bit stale and games became a bit gridlocked. So I proposed that we bring back specials, but instead of one special and those being connected to particular characters, this version would remove the alternate shots and instead give the player 4 special shots inspired by the main 4 swings.

The moonball was the special for the primary swing, with the ball shooting really high into the sky and becoming hard for an opponent to determine where it would land, the Around the Post was the special curve and it caused the ball to spend in a wild parabola with a wicked spin, the fake dink was the modified dink and it appeared like a normal shot until it accelerated after the first bounce, and the smash was the special drive where the player hit the ball with an intense overhead swing that caused the ball to catch fire.

These specials gave the game a bit more of that initial, arcade-like experience that I was chasing and helped us move further away from the simulation gameplay we were not aiming for. Granted, this whole thing took a lot of convincing and justification, and even in the final inspiration I wish there could have been more spectacle and functionality for the different specials, but there were needs to make business decisions as we worked on adding systems like this in the 11th hour.

Other responsibilities I had on this project were conferring with the other designer on the project, creating mini-GDDs, UX mockups, confirming that multiplayer and motion mode were working as intended, testing on different platforms, implementing feedback from QA, conducting playtests, writing dialogue, meeting with our publisher, recording gameplay, testing on device, and more. At the end of a project, it is easy to be frustrated or disheartened by what didn’t make it into the game or how things played out, but one of my biggest takeaways from this experience was allowing myself to be proud of what we had accomplished. Even though the timetable was intense, the goals at times were conflicting, and compromises were made, it was a very cathartic experience to see trailers of the game on channels for IGN and Xbox, to know the game is in actual stores, and to get a copy of the game for myself.

Boardwalk Arcade 2

Boardwalk Arcade 2 is a soon to be released game that will be coming to switch in mid-to-late 2024. It is inspired by games such as Carnival Games on the Wii and Party Arcade on the switch. The game features a boardwalk HUB, 10 games, a prize gallery, a redemption area, and multiplayer to boot. On this game, I worked on the initial concept that we shopped around to several publishers. Since this game was in development concurrently with Pickleball Smash, I wasn’t able to helm this project. What I was able to do was to provide ideation, mentorship, and design support for the lead designer on this project. I was selected by members of management to be a soundboard for this designer and to fill in when I was available.

My main contributions on this project were looking over all of the games and creating a list of feedback items categorized by whether they were something that needed to be done or that the game could benefit from. This took a bit of analyzing and getting to know the lay of the land in the project. I had to investigate scenes in Unity, dive into code, expose new variables, and test proposed changes to make sure that they were possible given the current implementation.

After the lead designer left the company, I filled in during a pivot point and proposed similar changes and QoL recommendations. I leveraged my experience working on Pickleball Smash pertaining to lot check and Nintendo requirements for our QA experience.

Indie

As state from the beginning, I’ve worked on plenty of personal projects over the years, but ever since I began my professional career I’ve been trying to apply the things I’ve learned from my time in this industry, my own game preferences, and the things I’ve learned with supplemental education like GDC talks and indie dev diaries on YouTube. Below are a wide spectrum of demos, proof of concepts, and games that I dedicated time to and that helps shape how I design today.

Millennium Dynasty

Millennium Dynasty was a game inspired by one of my all time favorite games, Paragon, a 3D, 3rd person MOBA developed by Epic. Instead of a fantasy/alien aesthetic, I used the backdrop of a superhero universe that I was developing of the same name. Full admission, when I played Paragon I had no idea how MOBA’s worked, so there were plenty of growing pains and toxicity to wade through. I loved the game on the other side of that, the strategy, the different styles of play, the abilities, the ramping, and the item economy, but I didn’t necessarily love the obtuse concept of towers and lanes for every MOBA.

So, I started working on a proof of concept for a battle arena experience that traded in concepts like lanes and towers with other objectives that would facilitate interesting play. For example, one of my friends really wanted to play with our group, but he didn’t have the necessary schema and game sense to really contribute. He always said “I wish I could farm to help you guys, but not be a detriment in fights”. So this got me thinking, what if there was a game that allowed players of different skillsets genre-wise(platforming, shooting, puzzles, etc.) to play alongside their “sweatier” friends in a game that was one part MOBA and another party experience.

So, Millennium Dynasty the game was born. A multiplayer, competitive, combat arena with a rotating playlist of minigames that prioritized different skillsets alongside fighting inspired by games like Paragon, Overwatch, and Smite. In this game, matches would have down periods in between rounds of mini-games inspired by mobility challenges, survival mechanics, and hero-themed objectives such as saving NPC citizens, mitigating natural disasters like earthquakes, and taking out threats like zombie swarms.

The game had a Cerebro like backdrop rife with unique challenges, and locations that changed based on the current mini-game. This hero assessment simulation meets wargame is akin to ExoPrimal‘s theme, but the blend of different minigames means that players need to depend on a well-rounded team and adapt to any challenge.

Players could customize their hero before the match to bend the cast of characters into powerful variants inspired by the rich lore of comic books that features so many versions of our favorite characters. For example it would be difficult to think of a small ability set for iconic characters like Superman. Is he a tank? Is he bruiser? Can he fly? What about his lasers or his frost breath? Would he be broken if he had super speed? To me the only answer is to have a system that lets you adjust abilities.

For example in the video provided below the player is able to choose abilities for their character, Vapir. Vapir has a kit based around teleporting but with that players can adjust their playstyle to either be offensive or about utility. Players choose between teleports that have greater number of charges vs extended range vs teleporting the player above the battlefield.

Even though this game never reached the polish level that I wanted, this project affirmed my love for creating unique abilities and systems. During my time on this project I got experience with Photon, which gave my game networking capabilities, I developed kits for roughly 7 characters each with their own primary, secondary, two abilities, a passive, and an ultimate. By trying to put aside my perfectionism, I was able to build some unique movement tech, experiment with networking, work with a more robust character controller, posting my work to Itch, and iterating on the project. This is definitely one of those passion projects that is much bigger than me, but it was a great way for me to hone more specific skills and to learn that even if you don’t finish a project that there is still merit to pushing ahead on one.

Cryptopathology / Witch Doctors

Cryptopathology, which eventually became known as Witch Doctors, was a play on words and was a thought experiment that began from the idea of “what if you ran a hospital for monsters”. My friend and I built on this idea with some other friends and started to build out the game idea and systems. You play as a doctor building your clinic for the various monster clients that come you way. We described it as: Overcooked meets Two-Point Hospital with a bit of Don’t Starve Together with a splash of progression, characterization, and monster madness. Our team built up a demo and broke the game into phases of intake, diagnosis, treatment, and discharge.

Players will see monsters enter triage, and they will need to prioritize them and bring them back to the office, but the catch is that some monsters will respond differently to the amount of time you make them wait or they may have more drastic symptoms. Bring them back to the office, use items to assess the problem and treat them correctly, earn money based the speed and efficiency of the treatment, and upgrade your facility so that you can take on bigger and better cases.

https://itch.io/game/edit/757421

Spiritweavers

Spiritweavers was another project that I worked on after playing the game Cassette Beasts, which inspired me to reconsider the Pokemon genre. After brainstorming with some friends, the idea was floated of a tower defense title where the towers are creatures that you capture and train. This idea resonated with me and I threw my attention at the project. We developed the logline: in Spiritweavers, players will navigate a 3D world with their own abilities and they will collect/summon spirits with varying abilities that can be evolved and customized in various ways to defend against an onslaught of automatons. I developed a story about a group of aboriginal people called Spiritweavers, naturalist, shamans that communed with the spirit world and conjure the citizens of that world to aid them in combat.

Gameplay was inspired by Dungeon Defenders, Kena: Bridge of Spirits, and Gigantic with RPG elements pulled from collection games like Pokemon and Palworld. In game, your character could navigate, summon creatures, upgrade them, use their own abilities, prioritize targets, and control your spirits. We brainstormed a lot of different versions of this, but in a nutshell gameplay would be mission based and would involve your character entering battlefields, attacking areas, holding their ground against swarms of enemies, growing your team, and defeating bosses.

We worked on the game for a number of months, but the biggest obstacle with this project is that the scope continued to expand and we felt that as a group it wouldn’t make sense for this to be the first release for us because of our team’s composition. We didn’t have enough character modelers, but our team was 3D centric vs being a 2D team, so the work load just felt too considerable. This is definitely a project that has bones, but this project reinforced this idea that it is okay to pare down and make something simpler so that the whole team doesn’t get burnt out so easily.

Dev Log 1: Summoning

Dev Log 2: Summoning iteration

Dev Log 3: Abilities

Dev Log 4: Spawning enemies and SFX improvements

Dev Log 5: Enemies and damage

Zen Sanctuary

Zen Sanctuary will be our group’s debut release in 2024. Inspired by the mentality of a game jam, we built the prototype and proof of concept in just a few days and since we have been iterating on it to improve it and get it to a more realized state. The premise of the game:

“Create your very own Zen Gardens by finding your perfect balance between made objects like buildings, decorations, and architecture, with the natural: rocks, water, and foliage. Add effects such as wind, rain, and music to set the scene just right. Place interactable objects in your garden to reveal bespoke, tranquil secrets. View your garden from a god’s eye view or go down into the garden to see it up close. Add items to change the zen levels of the space inspired by the 7 principles of Zen.”

In Zen Sanctuary players will craft gardens based around different themes or restrictions or they can build their own safe spaces away from the stresses of the world. Our team picked this idea and I provided design support even though this game was a bit out of my element. I did research on similar games on the store, I started looking into “dad games” like PowerWash Simulator and I tried to understand why these games work in the market.

Our goal was not to get too bogged down by big scoop or ambition, but keep our eyes on the prize for a simple game. Granted, I still wanted to justify the effort we put in and for us to maximize the “promise” of the game. There were a few mission types that we contemplated:

• Players get missions based on the requests of the client for the garden you are building
• Players complete missions inspired by the 7 principles of zen
• Players need to build their surreal zen sanctuary
• Players confront concepts like depression or loneliness and they combat them by building sanctuaries that protect against it
• Player stave off the evils of corporate dystopia by building natural looking sanctuaries

Some of the ideas felt very fruitful or fulfilling in their own ways, but the longer we deliberated the longer that this “short” project was becoming. Our solution was just to create a small set of missions that tutorializes the game and unlock new objects for the player’s free building. A game such as this isn’t revolutionary, but in a nutshell I needed a win, and this project felt like it could accomplish this.

Consulting

Another sector of my life that I have been honing is my ability to consult on projects. As a game designer and programmer there are projects that friends and family bring my way where they either need some insight or help vetting / improving a project. Since I worked on MHS, I have become quite adept at tackling big projects, breaking them down and understanding the project, and helping identify major issues.

One major example is that I worked with a company in 2022 where they handed me a gym builder project and my goal was to improve performance, simplify controls, and add a few features as to get the project in a suitable state for a release that they were several months late on already. I took the project and figured out very quickly that it was made by people who understood code, but unfortunately, didn’t have any idea how to structure their work. The game was in one super class that was 14000+ lines long. In the project the original programmer had written expletive comments in the code base, had left in vestigial code, named items poorly, had redundant function calls, no concepts of OOP or anything.

This was a bit of a herculean task, and I really had to document how the project was set up, leave myself breadcrumbs in the code base to understand the flow, research the software they were using, scour the project for gameobjects in a crowded hierarchy and more. This was a big task, but I deliver on all of the expectations and I built a good working relationship with the client. I scoped out my work, gave them different options, I was amicable and flexible, but also there did come times where I had to be definitive and blunt about the nature of the project and the reality that this was the type of project that they really should consider a sunk cost. I suggested tech for their sales team to purchase to run the game with the least amount of headache, and since I’ve proposed some guerilla marketing efforts for them involving in AR.

Aside from this project, I built a CPQ for a family friend’s company as to help aid in the sales portion of their company. This project has involved creating technical design documentation, paying artists for models, meeting with the client, designing a modular system that can be iterated and rethemed in the future. This project has an interesting pressure on it, and it has had me thinking of ways to both make the product that works for the business as an internal tool, but an external one as well. This has meant I got to flex a bit of my UX skills that I refined during my masters where we were tasked to think about how less tech literate users might interact with an application. I have tried to help the company abstract out their immense technical knowledge into more palatable and consistent layouts for menus, UI, and format for the user.

Along the same lines, it has been important for me to consider what are the best ways to make a tool that can scale and account for new data and information. For example, a change in price needs to be able to be applied remotely or quickly as to not have to redeploy the game every time a change has to come through. This also means making a tool that can last the client long enough for their use and making sure that it is set up in such a way that it is able to easily adapt.

Working on this CPQ has been a long process, but it has affirmed that Unity has so much potential in ways outside of gaming and it is a powerful business tech tool. Games as entertainment is where my heart is at, but I think there are so many industries that can benefit not only from training experience or tools developed in unity, but a gaming mindset that can help companies orient towards fulfilling technological experiences.