A lot of what makes Endogenesis fun is finding the patterns of play within the game, and then creating your own. This often manifests as figuring out the optimal strategy of using your skills, and careful planning on how to queue your actions. Because of the amount of flexibility afforded to players within their turn, it’s often possible to go from being last to potentially winning the game in a single turn!
As such, there can often be a lot of complexity and things to take note of within a player’s turn, especially when multiple reaction skills are in play. In addition, players are also building their characters from scratch with customizable skill sets over the course of the game, placing even more importance that players understand the game’s mechanics in order to do well.
With that in mind, there were a few goals I set out to achieve during the initial design phase:
- While the gameplay has the potential to be very complex, I still want it to be easy to learn. I believe that it’s okay to have a learning curve that ends off being very high — as long as it’s a gentle climb.
- I want players to be able to learn the game as they’re playing it, instead of being force-fed a ton of info right at the start. I’ve personally played so many fun games that were a bore at first, given that explanation of the game rules could take as long as 30 minutes before the first turn starts!
- And while unavoidable at times, I want to minimize incidents where players have to stop the game and look through the rulebook for clarification.
In order to achieve these goals, I decided that the core rules needed to be made as lightweight as possible. Instead, most of the game’s complexity would be “stored” in the cards instead. This meant that whenever there’s an interesting or complicated effect, it’s usually brought about by using a card. This method of partitioning complexity meant that card text needed to be written in a comprehensive, self-contained manner so that there was no ambiguity to its effect. Furthermore, keyword usage was kept to a minimum to prevent players from having to repeatedly refer to the rulebook.
Having been testing this approach with Endogenesis, I’ve found that for most part, it works well to ensure a gentler learning curve. New players seemed happy to be able to jump right in and start playing, and allowing players to learn the game while interacting with it helped to keep them engaged, given that they were more aware of the context in which the new concepts were introduced in.
However, a side effect that appeared was that turns taken by new players end up being especially long when compared to experienced players, given that some of the card text can be quite lengthy and challenging to understand. Some players also mentioned that the reliance on card text also made the game feel “heavy,” especially in longer games. To address this, we introduced graphical changes to simplify card text, such as converting commonly used words to icons (such as damage, health, shards etc.), and we looked for ways of shortening text without reducing specificity. For example, whenever a Skill deals damage to a single enemy, the card text was written as simply “Deal X (Damage)” instead of “Deal X (Damage) to an enemy” — only when there were conditions to the type or number of targets would the text be changed to reflect it. These changes went a long way in reducing the “heaviness” of the game, but only to a certain extent. Below is a “before-after” example of a Skill named Shadow Flare.
However, certain cards with complicated effects saw little to no reduction in card text due to their complexity. One example was a Reaction Skill named Warp, which has a somewhat complicated effect with certain conditions.
All in all, this method of partitioning complexity did achieve the desired results, but not without certain downsides. It’s a method that can be helpful in altering the game experience of your product, but only to a certain extent. There’s only so much you can do to hide complexity — you can suppress them in certain ways, but they’ll almost certainly reappear in other ways, and sometimes in unexpected manner.
When I thought back of those games with the majority of its complexity stored in rules — and thus required a lengthy starting tutorial — I realized that many of them benefited from a smooth-sailing and stress-free experience once the tutorial was out of the way. What’s most important, ultimately, is making sure that every bit of complexity you include in your game helps to add depth, and more importantly, fun to the overall experience.
What are some of the methods you’ve used to handle complexity in your games? Please let me know in the comments below!