Here’s a deeper dive into some of the projects I’ve worked on over the years!
Since both the variety of XR devices and the variety of avatars we want to experiment with are growing, I’ve been working on creating a system that allows us to easily add more of either. To do so, I’ve been applying SOLID architecture principles wherever I can - using Interfaces to invert dependencies and keep device-specific and avatar-specific behavior encapsulated.
One of the latest additions to the Smule Sing! app (now called just “Smule”) is Live Jams, a live video duet streaming functionality that lets two remote users sing together for an audience. The chat room that accompanies the Jam, as well as the signaling messages that get sent during the session to indicate who’s turn it is and what song should play, are mostly built using our existing messaging infrastructure. One challenge of spearheading this project: I wasn’t on the team that implemented the original messaging functionality. So I had a lot to learn, not just about XMPP (the protocol it was built on), but about our system itself. I poured over the source code, asked knowledgeable architects of the system the trickier questions, and wrote some unit tests to help understand behavior and give myself an easy way to test out exactly the code I was adding or modifying.
I directed 3 other Android developers and coordinated with multiple other departments to develop this ambitious, long term feature. Because we wanted this functionality to exist on not only Android, but also Web and iOS, we implemented it as an embedded web app, with handoffs to native Android code for specific sections of the flow, like play-testing your arrangement.
The origins of Fantasy Hip Hop came from a web-based variation on the Fantasy Sports model. We wanted to expand on that idea, bringing it to live in a 3D desktop MMORPG, where the player runs a record label in an explicitly virtual, simulated world, much like The Matrix. It was an ambitious goal, especially for a small team! We managed the scope in a number of ways: focusing on creating a vertical slice first, aiming to release content in chapters, and keeping a modest low-poly art style to target as many devices as possible.
We worked in a game-oriented language called BlitzMax, a variation of BASIC. It offered some interesting benefits: it was cross-platform, open-source, and easy to learn. But also had its shortcomings, the most startling of which we learned rather late in the PROJECT. When running in multi-threaded mode, the garbage collector didn't work properly and leaked memory! We started switching over to two single-threaded processes linked by inter-process communication. We ended up pivoting to making mobile games in Unity shortly thereafter for other reasons, but I learned a lot the dangers of choosing the wrong technology stack. Nowadays, when I'm evaluating third-party technologies, I push past the fancy features or what I'm comfortable with and dig for the risks. Technology that's less widely used is less likely to have ample documentation, users who have already solved the problems I'm bound to run into, or the resources available to fix their internal issues and maintain the library for as long as I need it. Mitigating these risks is crucially important, even if it means sacrificing some nice-to-have features.
In building out this world, I got to work on a wide variety of features. After implementing player movement, I added in a mountable hoverboard and configuring the collision system to allow it to ride on surfaces the player alone couldn’t. I also worked on some simple AI and pathfinding to make enemies follow and attack the player once they were within range. I set up dialogue conversation trees to provide the story driving the world. The vertical slice we created with these mechanics earned us another round of funding and acceptance into a video game startup accelerator.
At this point we realized that our small team would be better suited towards making several smaller games for mobile, as that industry was booming at the time. We adopted a game-jam mentality, iterating rapidly and seeing what would stick. RhymeCraft was one of the first one of those projects. The initial concept was a turn-based rap battle where the player chooses rhyming lines to lower the health of their opponent, and the lines themselves could be crowdsourced from the community. But it felt initially a bit too much like a school quiz. I presented and later implemented game mechanics that turned it into a card game under the hood, adding much more depth and strategy, and making it much more compelling. We released it to the Canadian app store to serve as a quasi-beta test as a single player game, and I started prototyping an asynchronous multiplayer backend. Sadly that feature never saw the light of day, but it was a great opportunity to learn some Javascript and work with Node.js.
The last project I worked on there was Rapper Run, an attempt to capitalize on the Temple Run infinite runner trend. A lot of my focus on this project was on the UI controls, especially the radio playback bar, which we planned to release as a standalone plugin that could be used by other games.
Two of the other games we made, KimYe and Roman’s Rage, were essentially light-hearted dating-sim-style games played through a text-messaging-esque UI. For these, I got to play game designer a bit, drafting spreadsheets of item costs and stats to try to dial in the length of gameplay.
One of my fellow Smule Android Devs and I participated in the 2017 SF Abortion Access Hackathon over the course of 3 days. We joined a very skilled and motivated team to make Termina, a website and Android app that allows the user to learn about their pregnancy options based on their age, state, and stage of their pregnancy. We used the Conductor UI framework to be able to put the app together cleanly and quickly, and had a great time learning to work with a totally new group of people!
