If we were to follow the advice of most people involved in this peculiar world of game development, one of the surefire strategies would be to publish your game on as many stores as possible, if only to increase visibility. Another potential winning move would be to make the most of the free APIs provided to developers to offer additional features to your audience, such as global leaderboards, multiplayer modes, or in-game chat rooms.
However, this approach comes with several challenges, some of which are far from trivial.
The cost of entry
The first, and perhaps the most obvious, hurdle is that not all stores accept free games. To be clear, the more coveted platforms—like Steam and Epic Games—do allow free-to-play games, but they require upfront fees to publish your game, regardless of its price. For example, Steam charges a $100 fee per game, ostensibly as a measure to ensure quality and prevent spam. While this is a one-time payment and might even be donated to charity, as claimed by Steam, the fact remains: you must pay before your game can even go live. As we’ll explore later, publishing and selling are two very different challenges. Even if you’re willing to pay for multiple stores, publishing on several platforms is not just a matter of money—it requires time and effort. Each store has its own tools, policies, and requirements. While some tools, such as incremental upload systems, are helpful, they’re also unique to each store, requiring developers to learn new workflows repeatedly.
The API dilemma
Similarly, the APIs offered by different stores are another source of frustration. In a world where technologies like JSON and REST APIs are widely embraced for their simplicity and compatibility, it’s puzzling that many store APIs are locked into compiled languages like C++ and C#. This effectively excludes developers who prefer—or are restricted to—other languages. Take Godot, for example. Its primary scripting language, GDScript, is designed to be intuitive and productive, much like Python. While Godot does support C++ and C# integrations, these are less convenient than using GDScript, which remains the go-to choice for many developers. The reliance on compiled languages for web services feels counterintuitive, especially given their historical purpose of optimizing performance on early-generation machines—a concern that feels outdated in the era of cross-platform, web-based ecosystems. The result? Developers who want to use these APIs often face an uphill battle, having to juggle multiple languages and tools to achieve integration.
The scalability problem
For solo developers or small teams, the dream of publishing on many platforms can quickly turn into a nightmare. Large companies or well-funded publishers can assign specialists to each store, ensuring a smooth and efficient process. Indie developers, however, must manage everything themselves, often finding it challenging to deal with even a single store. Now, imagine adding store-specific APIs into the mix. Maintaining deeply different codebases for various platforms throughout the lifecycle of a game can become unsustainable. This is where the theoretical appeal of “widespread presence” begins to crumble under the weight of practical realities.
A need for standardization
Much of this could be resolved if stores worked together to create standardized APIs. Open, community-driven standards could provide a universal ecosystem, allowing developers to integrate features easily across platforms and game engines. JSON and REST APIs already demonstrate how interoperability can succeed on a global scale. Unfortunately, stores have little incentive to pursue such standardization. Instead, we seem to be witnessing an “API war” or “service war,” where platforms deliberately design their systems to foster developer loyalty. By locking developers into a particular ecosystem, stores ensure continued engagement but at the cost of flexibility and simplicity for the indie community.
Conclusion
For an indie developer, publishing on multiple platforms and using store APIs can be an overwhelming endeavor. The lack of standardization creates barriers that favor larger organizations with specialized teams. While the benefits of API integration and a broader presence are undeniable, the costs—in both time and complexity—often outweigh the rewards for smaller developers.
Until the day stores agree to cooperate and adopt shared standards, indie developers must carefully weigh the value of expanding their reach against the burden it imposes. For most, a focused and selective approach may be the only viable path forward.
Top image by Vilius Kukanauskas from Pixabay