When Steam launched in 2003, it was primarily a way for Valve to distribute and update its own games online. Many players disliked it, especially because of its account and internet requirements, but it would eventually transform the games industry.
In 2005, Steam began selling games from other developers, giving them a way to reach players without relying entirely on physical distribution. Over time, it also gave developers tools to update their games and build communities around them.
And it worked.
What Steam did not do was tell developers how to make their games. Valve did not require everyone to use the same engine or programming language. Developers could use Unity, Unreal Engine, Godot, GameMaker, RPG Maker, or a custom engine. Steam was primarily concerned with making games easy to distribute, purchase, and update.
The web could represent the next step in that evolution. Steam reduced the friction involved in buying and distributing games; the web can reduce the friction involved in launching them.
That was not realistic when Steam first appeared. Browsers lacked many of the capabilities needed by modern games, and ambitious browser games generally depended on plugins such as Flash. JavaScript was far less capable than it is today, CSS was largely treated as a styling language, and HTML provided few of the multimedia features developers now take for granted.
The web platform has changed since then, and honestly, the pace of it still catches me off guard. Browsers now handle real 3D rendering through WebGL and WebGPU, JavaScript has grown into a language you can actually build a game loop in without fighting it, and HTML ships elements like <canvas> and <dialog> that used to require workarounds or plugins.
That shift is what made libraries like three.js, Babylon.js, and Phaser possible, and it’s why a three.js demo can now look like something you’d mistake for a shipped game rather than a browser experiment.
A web game can reach players through software they already have: the browser. Players can follow a link and start loading a game without first installing a storefront, launcher, or package. Hardware and browser limitations still exist, but the gap between discovering a game and playing it can be remarkably small.
We have been here before
In the early 2000s, the web was not a viable platform for game development. But that didn’t stop people from making games for it. People were making games for it using Flash. On websites like Newgrounds and on Facebook and on their own websites.
Flash was a great platform for game development. Easy to distribute and easy to play. With it great games were made like FarmVille, Bloons Tower Defense, Fireboy and Watergirl, Happy Wheels, etc.
But Flash was doomed to fail:
- It was not a native platform, you needed to install a plugin for the browser.
- It was not an open standard, it was a proprietary technology owned by Adobe.
- It was not ready in time for the smartphone revolution.
And it failed when HTML5 was released, grew and became the standard for the web.
- HTML5 is a native platform, you don’t need to install a plugin for the browser to use its new features.
- HTML5 is an open standard, it was not a proprietary technology owned by anybody.
- HTML5 is the answer for the smartphone revolution.
With that, the era of Flash games ended, and game developers moved away from the web.
But since then the web started to gain more and more features that make it appealing to develop games for.
The all digital future
Games are becoming more and more digital.
I know it is a hard pill to swallow for some (even for me sometimes) but it is a hard truth that the future of games is digital.
- The PC market is almost entirely digital.
- Sony announced that they will stop producing physical discs for their consoles in 2028.
- Xbox, allegedly, is working on a way to digitize your physical games.
- Subscription services are becoming the norm for games (Xbox Game Pass, PlayStation Plus, EA Play, etc.).
- Publishers can get a larger slice of the pie by selling digital games than physical ones (online storefront cut versus retail and disc production costs).
- Cloud gaming services show up more and more (Xbox cloud gaming, Nvidia GeForce Now, Amazon Luna, etc.).
But the next step is that we won’t be needing to download a game and save it locally on-device. Games will be fully playable in the browser.
In fact some already do that like itch.io that has a full list of games playable in the browser, Newgrounds as well. But those games are not mainstream like AAA games or best-selling indie games.
The moment a web game will break into the mainstream is the moment when the web will be the next logical step for game development.
And that future will happen with a successful indie game.
The upsides of web based games
When making a web based game it is already available to the piece of software that’s easily accessible to every computer owner, the browser!
With it being on the browser it can sometimes be accessible to a user super fast (or at least faster than downloading it from your game library). When you enter the website the game can start to load.
Most indie developers can in fact use basic web frameworks/libraries for their games such as Pixi.js or Phaser for 2D or Three.js for 3D.
If you still want it to run as an executable that you need to download and install in the computer (or you still want to distribute it on platforms such as Steam and GOG) you can wrap it with Electron/Tauri or even NW.js to turn it into an executable. Games such as Game Dev Tycoon and CrossCode have done this already with NW.js. And Cookie Clicker and GeoGuessr Steam Edition have done this already with Electron.
And if you are proficient in engines such as Unity, Godot or GameMaker Studio well you can still use them as you can export them as web outputs.
The downsides of web based games
We are missing a few things for developers to move to web based games.
DRM is an important thing to consider. How will you protect your game from piracy without angering your consumers and without making it harder for them to play the game? We can make it online only but what if our website is down? I don’t have a good answer for this yet, and I’m not sure anyone does, but it’s a question every developer shipping on the web will have to face.
While protection from piracy is important for the developer, there is something more important than that for the player, Performance.
WebGPU is great but is still not as strong as native GPU APIs like Vulkan and DirectX for demanding 3D/AAA-scale games.
Also let’s say you access the game through a domain, the assets would need to be hosted on that domain and that would mean more bandwidth and more storage for the developer. But also it can take time to stream it to the player depending on the connection speed and how big the assets are.
Another point: what about mobile devices? While features are available on mobile devices like WebGL and WebGPU on both android and iOS the performance is not the same as on desktop yet. Should we block the game from being played on mobile devices? because that’s a huge market we can lose if we do that.
These are real technical hurdles, and the web ecosystem will need to keep evolving to solve them.
Indie games will lead the web game dev revolution
Ok, I know you are thinking “but I have seen many indie games that are not successful”. And you are right, many indie games are not successful. But the ones that will be successful will be the ones to set the trend for the industry for the future.
Look at Minecraft, it was an indie game that broke into the mainstream. It is still one of the most successful games of all time. And a lot of games are inspired by it. That game specifically inspired a lot of indie games since then and made the indie game scene what it is today.
Thanks to Minecraft, the sandbox genre has evolved to the survival genre and many games were created after it, like Subnautica, Rust, ARK: Survival Evolved, etc.
Minecraft was the first big example of an indie game breaking into the mainstream in a massive way (yes I know there were other indie games that broke into the mainstream before Minecraft, like Braid, World of Goo and Castle Crashers but Minecraft is the one that blew up in a massive way), introducing many more people to the indie game scene and making indie games a possible career path for many people.
Minecraft set a trend twice: once by turning the sandbox into the survival genre, and once by proving indie development could be a career.
I can bring similar examples with other indie games such as Slay the Spire, Undertale and many more.
On the other hand, let’s look at the big AAA game scene.
Before Minecraft and the indie game boom, the big AAA games were the only games that were successful (in some sense). The AAA scene was dominated by big publishers like EA, Activision, Ubisoft, etc. And the idea behind that type of game was to create a game that is a big blockbuster that is going to sell a lot of copies and make a lot of money for the publisher. And every year they get bigger, longer, denser and more complex.
However with these ambitions it gets more expensive to develop, (and with some games to even maintain) someone will need to pay for it and it’s going to be the consumer.
The moment AAA games started to raise prices from $60 to $70 to $80, with $100 special editions (and will raise it more and more), the core gamer audience started to look elsewhere. And they saw the indie game scene as a possible alternative that would go for a cheap price because they are made by a single developer or a small team and the games were smaller, shorter, less dense and less complex than the AAA games but most importantly more fun to play.
The moment a web based indie game becomes a mainstream hit the web game dev revolution will truly begin.
The fun factor is what makes a game successful, not the platform
At its core a game needs to be fun.
Not to make money. Not to be memorable. Not to have a message.
Just needs to be fun to play. When it’s fun for one person to play they will tell their friends and family about it. Some of them will check the game out and the cycle will continue on and on.
We play games because they are fun. Whether it’s a web based game or a console game or a mobile game or a PC game, it needs to be fun to play.
The platform doesn’t make a game fun, but it decides how many people get to find out it’s fun.
Conclusion
This isn’t a call to move your stack to the web overnight. It’s a reminder that Steam already removed one kind of friction, buying and distributing games, and the next reduction is simpler to name than to build: getting from a link to actually playing.
The hurdles are real: DRM, performance, bandwidth, and mobile aren’t solved yet.
But when a game is fun, reach is what turns fun into a hit. A fun web game spreads by link. A fun Steam game spreads by a link that leads to a store page that maybe leads to a download.
That’s the step worth watching, and the one an indie breakthrough is most likely to prove first.