We used Early Access to get additional feedback and iteration time on our new combat system before reaching 1.0. Here's how it went.
Game Developer Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.
Game Developer Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.
Earlier installments cover topics such as how Techland centered player feedback in the development of Dying Light 2, how the developers of Insurgency created the architecture for console crossplay, and how League of Geeks created a complex asynchronous multiplayer in Solium Infernum.
In this edition, Shiny Shoe CEO and co-founder Mark Cooke tells us about Inkbound's Early Access period, and how his team mitigated feedback from their active community.
Hello, my name is Mark Cooke, I am the co-founder and CEO of Shiny Shoe. Our studio is best known for our roguelike deckbuilder Monster Train. In May 2023, we released another roguelike strategy game, Inkbound, into Steam’s Early Access program. Inkbound was recently released in 1.0, and we have been reflecting on our first experience with Early Access. This postmortem will outline what we think went right and wrong and will hopefully have some useful takeaways.
After wrapping up Monster Train, its expansion pack, and various ports, we decided that we wanted to continue making roguelike strategy games but wanted to try to expand into online cooperative multiplayer. Inkbound started as another card game, like Monster Train, but we felt we couldn’t make that work well in a cooperative environment after some early prototypes. The pacing was too slow. We pivoted to a hybrid of real-time and turn-based gameplay. In Inkbound, each player has an avatar they control with free movement in a 3D world, but in the strategic battles, the gameplay is turn-based. Players go on roguelike runs in a fantasy world where books create portals into their stories. During a run, players draft powerups to improve their “build” on a mission to defeat the enemy threat who is trying to unravel the world.
Although the game can be played solo, we also support 2 to 4-player cooperative multiplayer. Critically, to keep the pace up, in multiplayer, all players can take their actions simultaneously, including in combat. There is no defined turn order among players. It’s up to players to coordinate to use their abilities effectively. This combat system is one of our core twists and one of the reasons we wanted to use Early Access: to get additional feedback and iteration time on this new model before reaching 1.0.
Players battling a boss in multiplayer. Images via Shiny Shoe.
Speaking of feedback, listening to team and player feedback is a critical component of our development process and we have built a variety of systems to try to make gathering feedback as efficient as possible. Creating a culture of open feedback is a core studio goal. Prior to releasing in Early Access, we tested the game with a few hundred testers to try to both catch as many technical issues as possible, as well as improve balance and game feel.
With the stage set, let’s jump into the specifics of what went right and wrong in our Early Access program.
After releasing in Early Access we received a significant amount of feedback from a variety of channels, some good, some bad, and some requesting major changes. Although it can be painful to listen to negative feedback at times, I believe it’s critical to push through and try to understand the feedback trends. It’s clear to me that some people are better at staying level-headed when reading negative feedback than others. I encourage you to identify those people on your team and have them help summarize the feedback in constructive ways.
We felt we had a solid core game at our Early Access launch but some aspects of how the title was built were not received well by players in a way that blindsided us. More on this later. We absorbed that feedback and made some major pivots during Early Access in terms of game structure and business model. Some of the biggest feature additions included new character classes, new bosses, and a popular feature called “vestige sets” that give synergistic benefits to collecting different items during the course of a run.
Since Monster Train, we’ve shipped all of our games with a feedback mechanism built straight into the game. It has gone so well that I encourage every developer to do this. On PC, we map a key to open an in-game feedback form, and in pre-release builds, put a message on the screen at all times encouraging players to push the button if they have something to say. We also ship this feature into production, though we turn off the always-on prompt.
This system has proven immensely useful. If a player encounters a bug, they have an immediate way to send a report to the development team right when they are experiencing the issue and it is fresh in their mind. The same is true for balance feedback, quality of life concerns, and any frustration that they might be experiencing. When a player sends feedback, they get a free text entry to type in what is on their mind and under the hood, we capture a screenshot, their log file, their save game, and some other gameplay metadata. This additional data is incredibly useful for investigating bug reports and generally understanding the context of the feedback in cases where the written text may not be 100% clear.
In addition to this in-game mechanism, we also encourage our engaged player community to connect with us on Discord and put in the effort to keep that well-moderated and a positive place to offer constructive feedback. Finally, we monitor a few other sources for feedback, like the Steam forums, our support e-mail, and social media. We want it to be easy to reach us.
We designed Inkbound to encourage multiplayer. When playing the game online, players see each other in a central social hub between runs. There, they can optionally chat and party up before going on their next run. As a studio, this was our first big online game, and we decided to go with centralized hosting to ensure multiplayer would be as frictionless as possible.
We had the benefit of deciding to approach it this way from the outset, which enabled us to make technical decisions to support multiplayer and cloud server hosting along the way. We did a lot of research on engine architecture and server hosting deployment architecture, and we did as much simulated load testing as we could before the game came out to look for issues. Finally, before Early Access release, we ran a Steam Playtest, framing it as a “technical test” where players could try out the game and we could see how well our infrastructure was working.
We were quite nervous about this aspect of the project going into Early Access launch day, but, in the end, it went fairly well. All the effort in research, development, and testing in this area resulted in a quite stable launch from a technology perspective.
Players hanging out in the Atheneum social hub. Images via Shiny Shoe.
Inkbound launched as a premium title with optional cosmetic-only in-game monetization. This is not common in the roguelike genre, but with our planned centralized online/cooperative experience, we wanted to try a business model that could support ongoing updates without having to charge for content in a way that segregates the community (like only certain players having access to an area). We tried to be as simple and generous as possible with the monetization design. There were plenty of cosmetics to earn for free, and the system was completely optional. Players could not buy power, and all gameplay was available without interacting with that system.
The decision to incorporate in-game monetization did not go over well with players. We were blindsided by the amount of negative feedback. The complaints were primarily centered around the sense that additional items being sold in an Early Access title is unacceptable. This wasn’t stated by players but I also theorize that between the time we started developing Inkbound in 2021 to its Early Access release in 2023 that in-game monetization in premium games has soured industry-wide.
Even though we did a lot of pre-release testing, I think we were blindsided because business model decisions are basically impossible to test pre-release on PC compared to elements like gameplay balance. Our pre-release community testing crew got the game and everything in it for free, so they did not have the same emotional response to these features as players who were not involved in the project.
Ultimately, during our time in Early Access we fully removed in-game monetization. As expected, this was a popular decision, and I believe the right one for the project. We migrated the cosmetics that were previously available in the game into DLC “supporter packs” that can be optionally purchased on Steam. This is a model that is more widely accepted.
We made a strategic decision to launch in Early Access in English only to maximize our ability to iterate and release content updates without lengthy translation pipelines. Inkbound has a lot of text and game mechanics, and the goal was to empower game designers to change it as rapidly as they saw fit, improving the game and reducing the time it took to release those changes to our players. In that regard, this decision was a success because it certainly simplified the release process and allowed us to patch gameplay rules and systems rapidly.
It’s impossible to know for sure, but I believe that this was a mistake on the business side. Our top refund reason for the duration of Early Access was “no Chinese language support.” The Early Access release is one of your most important marketing beats, and only supporting English certainly reduced our reach during one of the times of maximum visibility. Eventually, we localized into a variety of languages at 1.0, which had been our plan all along, but I’ll always wonder how many players we failed to reach between Early Access that we were not able to reconnect with at 1.0.
At 1.0 we finally completed the Chinese localization. Images via Shiny Shoe.
We designed Inkbound from the outset to support online co-op as one of its core unique features, but also committed to supporting solo play. We found that after launch, approximately 60% of runs were played solo, and 40% were co-op. We received feedback from engaged players in both camps, suggesting ways to improve either the solo or co-op experience. Unfortunately, these suggestions were sometimes at odds with each other.
Our design team found it challenging to support both playstyles optimally, and with the split between runs relatively even, there wasn’t an obvious side to fully commit to. It also caused some friction internally where some folks on the team were advocating for focusing on pushing multiplayer features while others didn’t want to do anything that would potentially cause a purely solo player to be unhappy. For example, adding objectives that require multiplayer.
Ultimately, we stuck to ensuring solo players could experience everything in the game, with multiplayer remaining a fun way to play but not pushed as far as it could have been if we had gone co-op only. In the end, we feel it did work out, but we also wonder if we should have gone solo-only or multiplayer-only.
Inkbound was our first game to utilize Early Access, and we had some surprises that we did not anticipate. In the end, it was a valuable learning experience and I’m glad that we tried it. As we continue to support Inkbound post-launch we also have an eye to the future and are debating internally if and how we will use Early Access on future games. Regardless, we will definitely be applying the lessons learned on this project to our future games.
You May Also Like
