Relentless TCG (Zombie Battleground)

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.