Otherworld 1: Spring of Shadows is a dark fantasy adventure game developed by Boomzap and published by Big Fish Games. You play as a woman moving into an old house in the British countryside — only to discover a little girl trapped within a mirror! You then make it your mission to find and save this girl from an evil spirit known as the Shade.

*I joined the Boomzap Otherworld team in May 2011.

†Let's play videos are playthroughs by players / fans. Neither the developer (Boomzap, my employer at the time) nor the publisher have any affiliation with these streamers / youtubers.

2012-2013: Otherworld 2

Otherworld 2: Omens of Summer continues the adventure after you rescue a little girl named Fiona from the malignant and powerful Shade. In this installment, you must barter with or fight against fay creatures from British folklore, such as the Nyx and Banshee, as you and your allies try to stop a cataclysm called the Eternal Winter from happening.

2013: Otherworld 3

The last game in the franchise, Otherworld 3: Shades of Fall takes you and your companions to various fantastical locations to uncover the true origins of the evil Shade. You discover that an artifact known as the Perpetual Prison can seal the Shade. To finish it, you must seek out the Elder Fay, who have long departed from the human realm. It's a race against time and the Shade's minions, as the Shade's power grows towards autumn's end.

2013-2014: Awakening 7

Subtitled "The Golden Age", Awakening 7 is the final installment of the best-selling Awakening series, focusing on events before the main story. As Sasha, you must broker peace between humans and minotaurs in a magical land suffering a drought. You're not alone: various allies lend their hand to your quest — but their true motives remain to be seen.

2014-2015: Monster Roller

In Monster Roller, you play as a Roller — one who hatches, raises, and collects monsters — in order to fight fellow Rollers in the arena, earning fame, fortune, and gold. Whether you prefer to amass a collection of unique monsters, fight in real-time PVP, or want a single-player story mode while offline, Monster Roller has got you covered.

2016-2018: Maria Health

Maria Health is an online platform providing access to healthcare for all Filipinos. This is achieved through an online marketplace for prepaid health coverage as well as a matching process where small-to-medium enterprise owners are presented eligible plans from top HMOs in the Philippines based on factors such as company size, industry, and the like. This application of actuarial logic reduces the time and effort needed to present users with options side-by-side, assisting them in choosing the plan that best fits their needs.

2018-2019: Relentless

Relentless (previously known as Zombie Battleground) is a trading card game (TCG) published and developed by Loom Network, where the cards themselves are on the Ethereum blockchain, guaranteeing the rarity and value of a card. Select a hero — each with their own unique unlockackable skills — to fight in real-time PVP in a post-apocalyptic world of zombies. Trade zombies in the online marketplace with confidence, knowing that there will only be a set number for each card — eliminating the popular luck-based grind prevalent in online collectible games. Rarity is as real in Relentless as it is in the physical world.

*I joined the Relentless team in August 2018.

2020-2025: Copy and Technical Writing, Web Development

I write technical articles while independently developing brochure, blog, and/or portfolio sites for small companies and individuals.

Having been a bit of everything and having gone from game designer to web developer to product manager, I believe that clear, written communication contributes directly to a project's success.

More information

The FAQs page answers questions about my previous jobs, what technical documents I've produced, and so on.

The writing samples page contains links some to apps/docs I've made.

View all the commits I've ever made in GitHub, including my technical writing work.

Here's my resume.

External links:

• My Mobygames page (game design and writing credits)
• My Github

Project Description

The late aughts brought about a renaissance in the point-and-click adventure genre. It all started in an an unlikely place: "hidden object" casual games, wherein a player had to find certain items on the screen, as though the player was a private investigator digging for clues. By combining hidden object games with different scenery, puzzles, and a story to tie them all together, the Hidden Object / Puzzle Adventure (HOPA) genre was born.

Otherworld 1 was published by Big Fish Games at the crest of the HOPA trend in casual PC gaming and at the start of mobile gaming's growing popularity. It stepped up to the plate through the creation of unique puzzle mechanics within a world of dark fantasy — unlike the ubiquitous player-as-detective storylines. Boomzap, my employer at the time, distinguished itself as a development studio specializing in the fantastic and strange.

Otherworld 1 was also one of Boomzap's earliest forays into porting from PC/Mac to mobile (iOS and Android) with all the attendant details that are meant to be seamless to the end-user: from minor changes in wording (changing "click on x" to "tap on x" till we finally settled on the most neutral "select x" to encompass all platforms) to how to handle zooming and clickzones, especially on teeny-tiny phone screens.

Otherworld 1 won a full five star review from Gamezebo and peaked at #2 on the Big Fish Games charts. Based on localization sales, it did particularly well in Germany; its overall performance expanded Otherworld into a franchise, which continued with Otherworld 2.

My Role and Responsibilities

• A game designer's chief task depends on the stage of development; for Otherworld 1, the majority of my responsibility was to script / prototype / "greybox". In this level design process, a designer will set up all the variables and assets needed for a level within the game, including all text, story beats, puzzles, and adventure mechanics.
• Alongside scripting, I provided PSDs for the artists to use as a base to draw finalized assets. In a remote-only company such as Boomzap's, prototyping the entire game and providing PSDs are crucial protocols for communication between the designers, animators, and artists.
• At the end of my 6-month training period, I was given the project to finish till it shipped (gold milestone) in January 2012.

What is Greyboxing?

Adventure games are split into levels (chunks of gameplay with a set location, theme, and/or objective) where the main character typically finds clues to solve a mystery, catch a murderer, etc. Game design in this context is the structure of these tasks (solving a cipher, reconstructing a suspect's alibi, etc.) in such a way that the player wants to know more about the case or world they're in. Through a variety of puzzles, interactions with the scene in front of them, dialog, and cutscenes, the player appreciates the world they're in and wants to keep playing, as they're active participants in an unfolding story.

These interactions (picking up clues, etc.) within the level are entirely playable through high-level scripting logic written by the designer, with placeholder assets. The programmer's job, in contrast, is to provide the tools for the designer to design. By designing the level before any finalized assets are made, any artist, animator, or fellow designer can get a feel of the game and visualize the assets through their function, not just a game design document.

Project Specs

†Android and iOS builds are no longer available from BFG's Play / App Stores.

*Let's play videos are playthroughs by players / fans. Neither the developer (Boomzap, my employer at the time) nor the publisher have any affiliation with these streamers / youtubers.

Production Gallery

Other Media

I had a brief talk at an industry convention (Casual Connect 2012) about the company design process. The talk used Otherworld 1 for its samples. (Warning: the audio is loud.)

External Links

• What is scripting in game development?
• Quick And Dirty Prototyping: A Success Story — a Gamasutra feature written by my supervisor, outlining the company process

Project Description

Following Otherworld 1's success, Otherworld 2 was greenlit and pre-production began immediately after shipping Otherworld 1. Otherworld 2 continued the trend of exploring folklore in the UK. It explored a wider world than the first Otherworld, while staying true to the theme of dark fantasy featuring fay creatures who sometimes helped — or hindered — the main characters.

Otherworld 2 had a non-linear level design where the players could choose what location / level to explore after the first hour; this was achieved through the use of flags which would trigger events that I wrote myself, without the need for a dedicated programmer.

Management-wise, my goal was to get the best possible person working on what they did best — as reflected in the art. The Otherworld franchise's art style was heavily influenced by Thomas Kinkade, and Otherworld 2's landscapes and scenery exemplifies this.

Otherworld 2 was again a success and a third Otherworld game was greenlit.

My Role and Responsibilities

As the team lead, I was present on the first day until the game shipped — all twelve months of development.

• I focused on high level design, writing, training artists and designers, and meeting milestones.
• I wrote nearly all the in-game text in Otherworld 2, except the strategy guide, which was provided by the publisher.
• Internally, this project developed the skills of artists and designers. The art and design team learned the basics of animation: tweens, softbodies, skeletal animation (rigging), and the like, which then translated to a better understanding of how to create and cut up assets for animation use.

Project Specs

†Android and iOS builds are no longer available from BFG's Play / App Stores.

*Let's play videos are playthroughs by players / fans. Neither the developer (Boomzap, my employer at the time) nor the publisher have any affiliation with these streamers / youtubers.

Production Gallery - Narrative Design in the Lighthouse

A primary conceit that the Otherworld series delved into was that fay creatures affected human lives and influenced human history. In Otherworld 2, the design team explored the belief in gremlins during World War 2 by exploring an old lighthouse that was shut down after the war.

Research is always part of design work: one cannot simply show a lightbulb in a lighthouse (that would be ridiculous) — we made sure to show a fresnel lens, a Mk V diving suit, and a Spitfire plane, to give the lighthouse a sense of history and realism.

The design team also believed that player choice would increase engagement, even in a story-driven genre. While typical games in the point and click genre were completely linear, Otherworld 2 allowed the user to choose what location to explore first: a misty forest, a lighthouse, or the mountains.

Bug Gallery

Fixing bugs usually took up the last month of development, from beta (also known as the content complete milestone) to gold. We'd submit a release candidate (RC) in the last week of the beta period, and if they accepted the RC, that build would be considered gold master.

Project Description

Pitch work on Otherworld 3 started immediately after Otherworld 2.  This was my first time writing a pitch and game design document (GDD) from scratch. After a month in pre-production, Otherworld 3 was formally greenlit, marking the start of development. In Otherworld 3, you (as the main character) now have a concrete plan — to finish the Perpetual Prison — to stop the Shade, rather than simply responding to the threat of the Eternal Winter or exploring the fay world. I conceptualized the Perpetual Prison, envisioning it as a pyramid, a tomb fit for a king, which was meant to foreshadow the reveal of who the Shade truly was in the pantheon of fay creatures in the Otherworld.

Production was smooth for Otherworld 3, given that it was the third game and the team had spent two years together. This resulted in a total development period of only ten months, our fastest development period yet.

Despite process improvements, the Otherworld franchise was cancelled after initial pitch work on the final winter-themed game which would have resolved the story fully. At around that time, other Hidden Object Puzzle Adventure (HOPA) franchises within the company I worked for were wrapped up as well. I was reassigned to write an entirely new story for an existing franchise, which became the game Awakening 7.

My Role and Responsibilities

• I reprised my role as designer and lead for Otherworld 3, this time writing the pitch and GDD fully, following company and publisher guidelines.  
• Additionally, I was able to train and keep a junior designer for much of Otherworld 3's development, who helped greatly in the level design. (Typically trainees "graduated" to own a different project within 3 months.)
• I continued scripting and writing for much of production, transitioning to production / project management when handling client (publisher) feedback and change requests to the game.

Project Specs

†Android and iOS builds are no longer available from BFG's Play / App Stores.

*Let's play videos are playthroughs by players / fans. Neither the developer (Boomzap, my employer at the time) nor the publisher have any affiliation with these streamers / youtubers.

Production Gallery

Project Description

Awakening 7 was  made during the tail-end of the single-player, offline adventure genre under a try-before-you-buy business model. At around this time, the business model was shifting towards free-to-play. Despite the decline of "traditional" these Hidden Object Adventure Games (HOPAs), Boomzap invested in video improvements, which were applied to Awakening, giving it a more cinematic treatment than previous projects.

The project's production was the largest I'd handled for any game during my time in Boomzap. Each major character  — a ranger, a little girl, several minotaurs, and even a dragon — had an individual 3D model, and the cinematics were no longer confined to painted landscape backgrounds, a stark contrast to previous projects, in which cinematics were strictly in between at least 30 minutes of gameplay, with no 3D assets at all. There were also more voice over assets for Awakening 7 and more cutscenes / interstitials, spaced every few puzzles apart.

While I rarely made requests to the programmers on game engine improvements, I did request a specific feature for Awakening 7: the use of interpolations (linear, cubic, bounce, elastic, etc) in the video editor. Up until that point, interpolations were done manually. This small quality-of-life improvement powered up even the most junior of artist-animators who would have otherwise spent a few hours tweaking keyframes in order to create a realistic animation.

Awakening 7 launched in November 2014. By then, mobile and free-to-play were the dominant platform and business model. Resources were moved to those departments. I was assigned to design games for mobile, beginning with Monster Roller.

My Role and Responsibilities

My time in Awakening 7 was split between high level, project management duties and narrative design, making sure that the game's story made sense and that everyone on the team was on the same page. While in previous projects the team worked linearly, Awakening 7's team was split between me and a fellow designer (my trainee) working on different parts of the game, so it was important to occasionally check that we hadn't accidentally mixed up our puzzles or story beats. Apart from that, my tasks in writing, designing, and directing my half of the game remained the same as in my previous project.

Project Specs

†Android and iOS builds are no longer available from BFG's Play / App Stores.

*Let's play videos are playthroughs by players / fans. Neither the developer (Boomzap, my employer at the time) nor the publisher have any affiliation with these streamers / youtubers.

Production Gallery — Experiments and Concepts

Previous portfolio pages explored what bugs might pop up in this genre. For EC7, where the focus relied heavily on big, attention-grabbing moments, we did more pre-production and planning to lessen revison times.

Project Description

2015 saw the rise of the midcore genre in mobile games and the emergence of the Chinese market. Fueled by those trends, developers sought to create games with indefinite play times and a free-to-play model, either through subscriptions, micropayments, ads, or some combination of all three. Predictably, the market was (and has been since) dominated by content-heavy, collectible-based, multiplayer games centered on events/arcs with multiple revenue streams. Monster Roller was my team's attempt to give the users options on how they'd play (and/or pay) the game while balancing the "grind" as well as tactics and mechanics.

Unlike other projects, where I pitched to a publisher, from the start of Monster Roller the concept was given to me. I was instructed to make a game using a slot machine design — a gambling mechanism so culturally associated with luck and a lack of control that it's called "the one-armed bandit" — while still ensuring the game itself would be a battle of skill through good player choices, not randomness. This assignment was something of an uphill battle, working in reverse to convince players "we're not luck-based, really!" We were also mandated to make the game fully PvP (Player vs Player) with a single-player campaign for offline play. I did scream, in public, at work, but then I went to my corner and started sketching.

For this project, we researched player expectations on midcore games, specifically deck building games. (As in many studios, Hearthstone was constantly mentioned, though the game bears little resemblance to Hearthstone.) Unlike with pure casual games, midcore games have a built-in language that we could build off of; we didn't have to start with an empty slate in the player's mind.

A Blend of Deck Management and RPG Mechanics

The original inspiration for Monster Roller came from turn-based trading card games and RPG (Role Playing Games) battle systems. In most battle systems familiar to hardcore gamers, a  blow during a fight can either be:

• a regular attack, dealing damage based on a strength stat,
• a critical attack, dealing more damage,
• or a fumble, where the blow doesn't land or does minimal damage.

In classic games like Dungeons and Dragons, the chance or degree of success of that blow depends on the roll of the die. Instead of die, Monster Roller used slots so the difference was in how the RNG (Random Number Generator) was presented.

The linchpin was how well we'd communicate to the player that "it's just like the RNG in your typical RPG!" The typical mapping in a gamer's mind would be that the slots corresponded to random actions (attack, defend, skill/magic, etc.) — we had to make sure it was clear this wasn't what the game would be like. This is not easy, because die make it clear that some variable is manipulated by degree while slots imply that the variable is manipulated is type.

We also kept the concept of a "party" of monsters/companions traveling and fighting together. In most RPG games there are 3-4 active participants in a fight, with the option to swap out. In Monster Roller, in order to give the player more ways to respond to an enemy strategy, we had a total of 6 monsters per battle, with three (which we called the frontline) fighting at a time. The next three monsters in a party were called the bench, and could be swapped out at any time during the player's turn.

Then the slot concept was molded around sensible, well-known mechanics, to work with them rather than against them. Say you're a fighter with an assortment of punches and kicks that do roughly the same amount of damage. They'd all deal a "normal" amount of damage, but are different types of attack. We applied that to Monster Roller (albeit with more clawing and biting) in which a viable strategy would be to create a party that maximized having attacks of the same type — because they all had the same icon, and having the same icon in slot machines means hitting a jackpot.

This introduced the importance of "party management" in a manner distilled for quick mobile gaming sessions. We further built on this system by having roles for monsters: some monsters can attack, but some monsters can heal, can poison the enemy, can defend others, and so on. Thus, the core mechanic of Monster Roller was much the same as many card games: it boiled down to what cards are in your deck, which are then use to create certain plays and card combinations — basic deck management. Below is the Team UI screen which helps users decide on what monsters to group together. Through the creation of a visual and textual language, mechanics such as Roles and Jackpots are clear and intuitive to the player.

Two other ingredients rounded out a player's decision-making process in battle: the order in which monsters play their abilities (the Switchout system), and the Auto-Targeting system, which was influenced by monster elements and area-of-effect. But these systems are beyond the scope of this portfolio. More in-depth information on how we prototyped these systems to work together, and what these systems are, can be seen in my Monster Roller Retrospective (link forthcoming).

The Marketing-Design Connection

Because the game was self-published by Boomzap, marketing and design worked together to get the word out.

• Marketing and design jointly collaborated on the press kit. I wrote all the copy for both iOS and Google Play stores; our Marketing Head edited everything I wrote and provided me with a requirements list with word counts and descriptions.
• Either I or an artist contributed weekly content to a Wordpress blog for a year, detailing the process of creating the game. This also helped Marketing provide content in case they needed to do press work while I was unavailable.
• We attended local gaming cons to spread the word, such as ESGS 2015, where we were able to present a beta build in their indie corner and ramp up awareness of the game.

My Role and Responsibilities

• I did product research, specifically for midcore mobile games, board games, and card games. This included industry research such as compliance for region-specific laws such as COPPA, indie publishing models (Kickstarter was on the rise) and self-publishing analytics.
• I designed the rough look of the UI and the flow for the UX. I decided on the text of the buttons, the grouping of information in each screen, and the way the information would be presented (whether card, list, or some other pattern.) This includes making prototype animation, drawing roughs, etc. The artists would then finalize my sketches.
• I handled the stat balancing, which we did based on percents of a character's HP.
• I handled the events funnel of the game through analytics. We used Flurry to drill down to what stage or event the user had given up on, giving us the opportunity to "smoothen the funnel."
• Through collaboration with the marketing team, we created a press kit with a trailer, screenshots, and text (my contribution) for both iOS and Android stores.

Project Specs

Production Gallery

Whereas my previous adventure / point-and-click games were content-heavy with plenty of story writing and assets, Monster Roller was the opposite, where we made iteration after iteration of new UI patterns and UX tweaks. First we did these on cards, then on Excel, then we went through a new UI again and again. At no phase of alpha or content development was the UI / UX held sacred or final: it could change at any time, and as soon as the next day's build. We stopped touching the UI / UX flows only when we hit beta (content complete).

External Links

• Monster Roller Development Blog (Web Archive)
• Gamasutra feature: self-hosted with correct images | gamedeveloper.com (images broken) | archive on gamasutra with images

Project Description

Maria Health is an online platform providing access to healthcare for all Filipinos. This is achieved through a marketplace for prepaid health coverage as well as a matching process where small-to-medium enterprise owners are presented eligible plans from top HMOs in the Philippines based on factors such as company size, industry, and the like. This application of actuarial logic reduces the time and effort needed to present users with options side-by-side, assisting them in choosing the plan that best fits their needs.

My Roles and Responsibilities

• I coded frontend pages in Angular for a year, following design spec. These included: Contact Us, Cart, various landing pages, and Plan Comparison pages.
• I handled the migration to Vue and Webpack in 2017, rewriting the entire site's frontend into Vue.
• I created a microcopy app in the backend, with shortcodes to every line of text in the web site. Coupled with VWO Insights A/B testing, this allowed the product team to update old copy to a better-converting text anywhere on the site, instantly from the dashboard, and without the need to go through developers. This resulted in faster conversion improvements.
• I wrote documentation on how to use the admin dashboard for use by Sales and Product.
• I briefly wrote Selenium tests (using the Python webdriver) for automated Cart testing.

Project Specs

In 2018, an industry contact got in touch with me for part-time work as a tester with Loom Network, a company that was developing sidechain technology atop the Ethereum chain. I joined the team halfway through production. After a few months of part-time testing, they asked me to join full-time, which I did until the project's completion.

Project Description

Relentless is a trading card game in the same vein as Hearthstone, themed around a colorful zombie apocalypse. It has the standard feature set: PvP, Leaderboards, Events, and the like. The twist in this production comes in the form of "true rarity" in digital card economies. As cards are placed on the Ethereum blockchain, their amount is permanently limited, their provenance (origin) and transaction records are made public, and when "printing" (minting) is done, it's done.

This gives cards a value that cannot be rebalanced to dilution by software updates, unlike when other collectible-based gacha games rebalance their card or collectible economies without transparency. This also prevents booster pack abuse, in which digital card games create a rarity so great a player can buy 100 packs without receiving a powerful or rare card. This is a source of frustration for users in the free-to-play space, and blockchain was Loom Network's answer.

Vertical Slices vs Minimum Viable Products; Static Products vs Rolling Updates

Relentless's process was a blend of web development and game development. While to outsiders the creation of a digital product may look the same, content in video games is frequently not user-generated, unlike social media or CRUD-type apps. The traditional (pre-2010s) goal in early game development, when pitching to publishers, is the creation of a vertical slice — a playable build with core features in place but with limited content, not meant for market release. Then the team would continue to progress, adding assets, testing mechanics, etc., until the team was ready to release a complete product. This is different from the tech industry's minimum viable product where core features are in place for market release with little or even no content, then updated after. Vertical slices of content are not typical of tech, as the end user can provide content, testing, and usage analytics whereas in games the content is provided by the developer.

The old game-making model has changed over the past decade to pick up some tendencies from tech: video games tend to do a bit of both now. They'll still do a vertical slice, but the games themselves are no longer static products that don't update except for patch fixes; these days DLC has turned even AAA video games into a minimum viable product with a price tag of about 60 USD and rolling updates in the form of DLC.

Another difference between tech and games are the 2-week sprints in Agile (more common outside of game development) and the 1-week tasking cycle at my previous employment in a games studio, following a Results Only Work Environment (ROWE). Also, whereas daily builds are enforceable in a game company because of the amount of content produced in a day — it's not just the web developers who are adding content into the product — in Relentless (following a more web dev pipeline), a new build wasn't expected every day until we were closer to release.

Team Communication

In more practical, day-to-day production, terms as simple as localization strings had to be explained as shortcodes (not entirely the same, but for localization purposes, it was). The design team's job was to manage several different team compositions on top of design work. And depending on who you asked, the design team was either "Design" or "Product." Over time these issues were ironed out — the most important thing was making sure game designers and artists could be understood by web/blockchain developers.

Relentless went live in 2019.

My Role and Responsibilities

When I first started the job, I noticed two missing systems. Relentless needed a localization system, and a data export system. In order to get these features in, I agreed to full time work as a Technical Designer, seeing that the team was already well-served by a fellow game designer whose speciality was in board games.

• I served as the link between the games team and the tech team, mediating feature requests and implementation when necessary.
• I proposed and designed tools to offload data export into the build directly from the Design team, specifically the zombie data (stats) and tutorial events.
• I tested the the game to report and clean up minor design and text bugs.
• I handled production tasking to make sure that the artists were fully tasked for the week.

Project Specs

*I joined the Relentless team in August 2018.

Production Gallery — Tool Development

One of Loom's earliest attempts to fix the workflow was to provide a tool to change (export) data. In the beginning, we had little say in tool design. I worked with a programmer but later on had to abandon the export tool as the single-entry webform UI wasn't right for bulk edits. Sweeping changes based on data normalization is common in the industry — how else do game designers change 100 units at once?

From my previous years of experience I made my own bulk export tool using Excel VBA which also configured the upload command.

Compare this with the single-entry webform! Imagine clicking on a drop down box to select a kind of creature 100x (and having to press submit each time) rather than just dragging down an entry to copy similar attributes, which will immediately make 100 creatures of one kind.

Another early design which had to be entirely remade was the tutorial flow. Tutorials are usually one of the last features before the content complete milestone. This frequently results in crunch because the amount of event triggers and custom events in tutorials is done late and tested late too. It was the holiday season and we were out of programmer time, so I wrote the tool based on the programmer's classes with their knowledge and approval, and exported all the data revisions (including in-game dialog).

Personal note

I chose to leave Loom Network due to a change in my stance on blockchain. I realized that blockchain was too energy intensive without providing benefits that warranted such a cost. I also regret working on a project involving speculative marketplaces as Loom hoped would happen with the cards. I have resolved never to work in the blockchain industry again, even as part-time QA or consulting work.