Post-Mortem: Arena of Mythos

In a previous post, I made a spoiler post about a game I was working on. That game went by the project name “Arena of Mythos”, and I’ve since decided to sunset it. Arena of Mythos was my first serious game design project, so there was lots of lessons I learned while working on it. Here’s a few of them:

What kind of game was it?

Arena of Mythos started as a game design portfolio project. I started working on it with a friend, and we opted to make a tabletop game instead of a computer game to avoid the initial investment of learning a programming platform and just get into the design. Although there were many iterations and three major overhauls that caused the game to vary quite widely, in both play and setting, a few things stayed the same: it was always a large group game (4-6), it had a moderate level of complexity, and players collected cards representing gear, items and class levels to become more powerful.

What went well

Working on Arena of Mythos was a great experience in terms of learning the tools and practices of game design. Before starting the project, I never would have guessed that game designers spend so much time looking at spreadsheets! We also learned early on that iteration was indispensable, and got better at triaging problems to later iterations as improved our intuition of how much work a solution would require or the scope of a suggested change.

We also learned a lot about prioritizing problems in terms of the game’s needs. While it feels productive and looks pretty to pick out placeholder art for your cards, it’s more helpful for the game to figure out why it feels awkward to play. In a similar sense, we learned very well about the player behavior of looking for efficiency before fun gameplay. Leaving in an exploit because “our playtesters know better than to abuse something that would make the game less fun” was not a good idea.

We used character art from Fire Emblem as placeholder. Pictures often communicate more about a playstyles at a glance than stats and ability texts.

We used placeholder art from Fire Emblem because pictures often communicate more about playstyles at a glance than stats and ability texts.

I also learned about how I work and picked up the habit of bringing a notebook around with me so that I could record any ideas that randomly struck me (which was by and large the biggest source of ideas). Since we had a really small team (2 people), we both had access to every part of the project, and I quickly learned which jobs I liked and which ones I didn’t. I think this was especially important because people tend to get better at the activities they like the best more quickly.

For me in particular, I really liked class design. The idea of characterizing the different classes with the abilities they had and trying to design them so that different people could all have a style of play that they enjoyed was something I really felt at home doing. At one point in the game, we even had non-player enemies to kill, and designing those encounters was also fun because it presented a design space where I could make even wilder strokes due to the “stupid nature” of non-player entities.

Quest Card

In some versions of the game, you could complete quests to earn extra money. We also had a “Distance” (DST) mechanic, which pretty much worked like Front/Back Formations in Final Fantasy.

On the other hand, item design and balance were among my least favorite design areas. Those areas were just too broad and required keeping too many other things in mind at the same time (items could be equipped by anyone and classes had to be balanced relative to each other).

What didn’t go well

In retrospect, one of the biggest problems for the game was a lack of theme. At the beginning of the project, we had decided that we were undecided about what kind of theme we wanted… so we just launched into designing the mechanics that we could. “I’m no artist,” I thought “an idea for a theme will probably just hit me sometime along the way anyway.”. Ignoring our lack of theme worked in the short term, but as we hammered out more and more mechanics, finding a theme that would elegantly stretch around all of them became more and more difficult. Theme is actually really important for a few reasons:

  1. It will explain things for you “for free” in all of those times that a mechanic just thematically makes sense
  2. It’s basically the primary way that people first engage with your game
  3. Sometimes your theme inspires you to do things you wouldn’t have thought of otherwise

Putting off deciding on a theme was basically forgetting that we were doing our “physics” in a “frictionless vacuum”. In other words, even though it’s helpful for game design to not worry as much about being constrained by theme, there are a lot of details in that arena (*rimshot*) that can make or break the viability of a product. If we were really trying to take the game to market, we needed to consider the fact that almost no gamers will play a game exclusively for the mechanics, and that you need to bundle the world building and fantasy with it too. Lacking a theme also made it really hard to pitch the game to an artist when it game time to work on looking for that kind of help.

Team management and collaboration ended up being another unexpected obstacle. Just starting out, we had very little idea what kind of help we would need to complete it, let alone what the scope of this kind of project was. Specifically, we hadn’t put very much thought into what kinds of art and marketing needs the game would have, or even the scope of what that work would be. In art contracting, a single card’s illustration is considered a full piece of artwork (because that’s the amount of detail and quality that is standard in games)–a much bigger scope than we had even imagined. Clearly we needed a much larger initial investment than “hey guys, let’s make our own game”. Oh, and have I mentioned the process of actually printing and manufacturing the physical products yet?

The last problem was time/schedule management. Any project that requires three major overhauls is not a practical one, and we probably extended the development of the game a bit too far into its undeath. Of course, any creative person worth their salt will tell you that it’s possible to apply infinite hours to any creative project and still not be done. That’s the reason why companies that make games for a living install safeguards against that eventuality such as reevaluating the project with as objective a perspective as possible as regularly as possible and setting deadlines to ship it at which point you wrench the game from the creative persons’ tweaking hands. Pro-tip: when you’re seriously considering changing a game’s win condition or hook, that’s probably a sign that the whole game needs to go back to the drawing board.

Concluding thoughts

As a product, Arena of Mythos was mediocre at best and not really worth shipping–so we didn’t. However, it was an amazing learning experience where I learned the practicalities of making games and a lot about myself as a game designer in the process. While canceling the project can seem sad because it looks like all that work is going to go to waste, those ideas and mechanics will likely show up in later projects (when appropriate) in a cleaner and better implementation than they would have if the project had continued on. The Back of the Napkin may be quiet for a while, as most of my creative energy is going into non-personal projects now (read: CGC Games), but hopefully me sharing these reflections has been beneficial to you all.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s