Danger Crew Best and Worst Decisions: Releasing on Steam
This is part of a series of posts documenting our best and worst decisions in the development and release of Danger Crew. These thoughts serve to help me remember things for future developments - I hope you find value in them, too!
It was originally just a thing for the web
Ever since I started Danger Crew in the Fall of 2015, the plan was to release it as a web game. The game is built in HTML after all, so shouldn’t it live directly on our website?
Since it started as a goofy side project, I even sure we’d ever ask for money at all. As it got more serious, the web game business model would have been something like: play the beginning of the game for free → pay for the rest. I even planned a “pay wall” room in the game where characters would give you snark for not having bought the game yet. You’d be able to see people through a glass wall who had paid and were having tons of fun.
In early 2019, three different people (who never talk to each other) asked me if we were going to be putting the game on Steam. I had not ever considered that Steam was even an option for us because our game was basically a website and not an executable. I did some research and experimentation of wrapping the game as a standalone app and it just worked. (Here’s a post I wrote on CodePen about that process…) By April 2019, we had a release date scheduled on Steam and had completely abandoned the 3-year old plan of hosting Danger Crew on the web.
Why was Steam a good thing?
Steam has a MASSIVE audience built into the platform. Even a game like ours got decent attention and traffic on Steam on launch day when we had practically no following.
Steam takes care of the business model. It’s a clean 1 to 1 transaction. They process credit cards/payment methods, deal with fraud, and have built in Wishlist and Community features. Gamers know Steam and how the process works - we were able to focus on making the game better and not caring about the grossly underestimated logistics of our original website plan.
Wrapping the game as an executable made the game’s runtime performance much better. It was always pretty good in a web browser (because we agonized over the Overworld performance) but would sometimes chunk here or there depending on what else you had going on inside Chrome. Now it runs as a dedicated process by itself.
It was a mind shifter for web development. It’s cool to show that HTML, CSS, and JS can be used in contexts other than websites. If you know some web development, you have the power to build whatever you want!