Insights from Kartridge Developer Survey

Part of our philosophy when building Kartridge was to be a platform that served the needs of both players and developers. In addition to focusing our efforts on making a player-friendly platform, we’ve also been making sure to treat developers fairly, which involves regularly talking with developers to find out what tools and features they need. In this way we can try our best to tailor the platform to the service of developers rather than forcing them to conform to us. This is why we invited a small group of indies to join an early advisory council and why we have been showing off early builds at conferences while taking lots of notes.

As part of this endeavor, we recently sent out an email to everyone who signed up for our Kartridge developers update emails (which you can do at https://kartridge.com/developers/). To our delight we had a fantastic response rate, even for the somewhat long survey. So first off, a big thank you to everyone who took the time to fill one out!

The survey turned up a few interesting results that we thought would be worth sharing broadly. These results are based on over 300 responses, though it is a self-selected group so it’s definitely not a rigorous randomized study. Also, all questions were optional after the initial company size ones, so you’ll see varying numbers of responses on each.

First up, let’s see who filled this out.

So we’re looking mostly at single-person developers, with very small teams making up the majority of the remaining respondents.

We also asked them what they considered themselves in the industry.

It’s not too surprising to see a similar distribution.

As an amusing aside, 5 respondents have 25+ people, of which 4 said they were “Medium indie developers” and 1 said it was a “Small indie developer.” Yet we had 3 companies identify as “Large (‘triple-I’) indie developers”! Who were they? Two with 10 - 24 people and one ace flyin’ solo (and yes, it’s a reasonable claim from this person).

In any case, let’s get to the topics!

Refund Policy

We’ve done a lot of thinking and research on refund policies. Here’s the question as it appeared on the survey:

Our current plan for a refund policy is to not allow refunds at all once a game is installed or if the purchase was over two weeks ago. Refunds would only be given if the game is non-functional for the user or never installed.

This policy is roughly consistent with GOG, Humble, itch.io, Green Man Gaming, Big Fish Games, and Uplay. Only Steam and Origin, to my knowledge, allow "any reason" refunds.

Most of the developers felt it was right. A good chunk felt it was leaving out some valid return reasons (false advertising called out specifically, which we will likely incorporate), while 8% felt like customers should be able to return for any reason. A bunch of write-ins make up the rest.

A small contingent wanted to give the developer the choice to pick a more relaxed refund policy. This is an interesting idea, but one that we’re not going to take for a few reasons: a) it’s confusing for players to have inconsistent policies and b) we don’t want developers who don’t choose the looser policy to receive criticism from players. By having it as an option developers would be almost forced to accept it.

DLC and DRM

DLC is a very commonly requested feature and one that we are definitely going to be adding. But there are two primary ways to handle DLC: by downloading additional files or by using an API for an ownership check. We wanted to know which method developers preferred.

In a near-perfect 4-way split we discovered that we really need to support both methods. But this led to another question. An ownership check API would enable a very light form of DRM.

This has been a hot topic in PC gaming among players and developers. Historically some DRM has caused significant trouble for legitimate customers, though today few players are bothered by lighter DRM. We also heard feedback from some developers that they wouldn’t use Kartridge without an option for DRM. We generally want to err on the side of giving developers more choices, so we decided to just ask what they thought.

Somewhat to our surprise, the vast majority (over 80%) had no problem with DRM, with nearly half of the developers planning to use it if available. Almost no one felt that the existence of optional DRM on the platform would be a deal-breaker for them. We saw similar results in a follow-up question about 3rd-party DRM.

Game Engines

While on the topic of APIs, we wanted to get a sense for what engines or technologies were most important for us to support with our SDK from the start.

Not surprising to see Unity in the lead here, and Unreal takes a solid 2nd place for engines. A lot of developers, though, are rolling their own custom C++ and C# solutions. Open source is driving some games too, with both Phaser and Godot getting some love.

“Early Access” Functionality

One of the most common requests we have received is support for something akin to Steam’s Early Access program. We want to support this, but what exactly do developers mean when they request such functionality? Is it something we can build quickly, or are there a lot of requirements we would need to hit?

The vast majority of developers are happy with just clear labeling and a forum for feedback/discussion. About 6% felt that it also needed a standardized survey, and another 6% thought there were other features that would be necessary. This helps us focus our efforts, avoiding over-designing features and instead getting them out to developers more quickly.

Thank you again to everyone who filled out the survey, and we’re excited to open the closed beta up to more developers and players in the coming months!