The Making of a Great Game: Part 1

Gaming and blockchain should go together like peanut butter and jelly. Sadly, the current state of BC gaming includes games focused on tokenomics, or simple re-skins of existing mobile game titles. Neither of these styles actually satisfies the need for good BC games.

Where are the indie developers? Where are the great gaming titles coming to a chain near you? Most projects building on the blockchain find “play to earn” mechanics easy to deploy and lucrative , so smaller teams rarely build with gaming in mind first. Indie gaming is often an arduous, expensive and lengthy process.

In fact, with a few notable exceptions, most of the game projects on the blockchain began as financial instruments first and foremost, only applying game theory elements or small endless runners on low-effort games as an afterthought.

The truth is, indie gaming development takes time, money and a lot of stamina. It is a constant process to ideate, execute, refine, repeat.

This series of posts are a brief insight into the creative process of Dead Games, and what makes us proud of our games. Obviously, our first major release has barely entered pre-alpha stage, and we have only deployed a beta game (Patient Zero) so this series is both a review on our work thus far, but also a forecasting of what is to come.

We will periodically update alongside development.

Oh, How Long?

To give you an idea of scope, many major AAA gaming titles such as Red Dead Redemption 2 take millions of dollars and multiple years (3–5, sometimes longer) to develop. For mobile games, these can be created in just a matter of months. It truly varies widely, depending on many different factors.

For our first TCG, time to market is likely somewhere in-between.

The phases of game development have various names depending on who you ask, we have broken it down into four stages in this post.

Timeline

• Ideation: Ideation, design and refinement steps should ideally range from about 3–12 months, but for many indie game creators, they have had ideas in their heads for years working on these games in the margins of their time. For us, this stage took about 9 months. Because these things ebb and flow, you are power-cycling through idea, designing and refinement continuously, this is where ideas take shape into a form that can be molded, and delivered.
• Execution: This is the stage that you have the GDD (game design document) ready to go, and you get to start building. Depending on your budget and team size, this stage can be shorter, or longer. As an example: the game logic can be created in parallel as artist work on the UI/UX. Ideally, some of the UI/UX design was done in the Ideation stage so that creatives are simply building the assets during execution. Our team began design of art assets a bit later, although we have access to multiple asset creators with our art studio partners, so we should be able to “make up time in the air” by creating the assets simultaneously as long as our budget allows. For us, this stage is likely somewhere close to 3 months. This is where we are currently.
• QA & Debugging: At this point, with the UI/UX and the game logic built, it is time for debugging and quality assurance testing before marketing. Hopefully your game is well designed, and for a game like ours, with sound game logic, the QA really consists of a lot of balancing the game. Because we are releasing a card game, this process can happen in stages as we release new cards into the game itself.
• Marketing & Release: Often this stage happens before the game is released, and happens in stages concurrently with previous phases. As an example, we are entering in the middle of our “execution” phase, and then will be beta testing, and finally general release. We actually intend for our beta group to be an active membership to give players early access to new cards and early test strategies for feedback to our team on balance etc. Beta tester passes will come with perks such as free drops, limited edition cards and of course, insight into how cards may be played in the game.

IDEATION

Idea & Design Step

Every great game begins with an idea. Early on, our team knew the type of game we wanted to create: a turn based card-style game. This idea itself is not unique. In fact, gaming mechanics are usually quite simple and for card games, the physical nature of cards somewhat limits the kind of decisions you can make. There are only so many logical mechanics that can be utilized in gaming, and they have some basic categories so getting a feel for how you want the game to flow usually gives you an idea of the mechanics to put to use.

Ideation was actually the longest part of our game-dev so far. Our lead creative (EZ) spent literally months iterating on which mechanics to implement, what turn orders and play styles should look like(should it be real time strategy or turn based? Something in between? What games have done that well? What sounds fun?)

Ideation is a long, but fun season, as the possibilities seem endless. Every game you play becomes an inspiration session, every movie you see gives you visual ideas, etc. Without a narrow focus, game designers can get lost in the possibilities.

Also, research plays a heavy role in this phase as well. Basically, you want to know if someone already tried your mechanics before and how it went. For our team, we heavily researched various trading card games such as MTG, Hearthstone, GodsUnchained, Gwent, Yo-Gi-Oh, and many countless others. We also began looking at various mobile and web-based games to look at tech limitations on how our game might be experienced and ultimately decided that we would build for a release on pc/mac first before moving to webGL/mobile.

Lore-building and Story-crating started here as well. What is the story we intend to tell through the game? What world building elements will matter. Why should the gamer care about characters and plot? These questions are crucial in certain game builds, but for a trading card game like ours, the lore (while still important) was less crucial than building strong strategy mechanics at this stage of development.

Stories are very important, even for games that don’t feature a storyline, because they affect the development of card styling elements, UI/UX, future releases, card art, etc. So while this would not be the main feature of our game, Lore and World building are absolutely necessary and cannot be discounted. With our ambitions, these elements become even MORE important.

Refinement Step

After we had enough of a game idea that we could begin to play with, the team went to work on building out basic mechanics in the game. Logic circuits becomes important at this stage. Every decision and action now has consequences and the team had to try and break the logic as much as we could to look for edge cases and imperfections in the game’s basic play. What mechanics can be exploited, what is redundant, what doesn’t work how we intended?

Inevitably we would run into game-breaking rules, or scenarios where existing rules and logic led us into more questions than answers.

The temptation for many game builders at this stage is to try and “plug the holes” in the boat. If a rule creates an edge case, it is tempting to patch the case with more specific rules to address that particular hole. But at a certain point, if your rule is creating too many leaks in the game logic, it’s wise to back up and examine whether the rule itself needs to be fixed or discarded entirely.

Here is an example:

Early on the building of our TCG, we introduced the idea of “ranged attack” cards with certain ranges that can attack or defend other cards within their range. This seems logical enough at first glance, but now consider that a player is attacking with multiple attackers, and that defending players handle the blocking. In this instance, the larger the range, the more valuable the card, it seems that ranged attack cards will almost always be preferred and may become over-powered; a player has virtually no incentive to keep playing low range attack cards. We can choose to balance this by nerfing the range cards, or we can bump the attack power of close up attacks. While this might seem a great solution, it actually makes future card development more difficult because it introduces more complexity into an already complex battle system.

During “refinement stage” was when we began to build out our Game Design Document (GDD). This is an industry standard document most games use in order to build games with clear team communication and reduce inconsistencies. Many current BC games don’t require this type of document, because frankly, they aren’t making games that have much to offer, and don’t necessitate any codifying of the rules and design.

Game Design Documents include more than game rules however. They include design elements, tech stack, User Experience and “customer journey”, ie, how will the gamer enter and flow through the game. It includes which UI/UX elements are needed (health bars, animations, 3d and 2d objects). They become the place where the team is able to refer back for constant reference for all parts of the game.

Our team chose to make our GDD in a series of documents that have a living history, with constant commenting, updating and recommendations from team members as we work. The dynamism of this model fits our team ethos better, and we have pretty strong regular communication. This is not without its barriers however. We have had many calls where we have to go back to the drawing board on a concept that we thought was mostly ironed out, etc.

We have exited the Ideation Stage and we are now hard at work in the Execution Stage. Stay tuned for another post concerning our execution stage and how our game build is coming along. Maybe there will some sneak peaks of how we are building.