How to Make a Web Game All by Yourself

Welcome to my talk, How to Make a Web Game All by Yourself. I appreciate you being here and I think we're going to have a good time. This talk aims to guide you to that elusive finish line and help you ship your own web game all by yourself.

But first, a little bit about me. My name is Matt Hackett, I've been making games for fun in environments like QBasic since I was 12 years old. In 2010, I published one of the earliest pure JavaScript games called Onslaught Arena and I was among the first developers to get a JavaScript game on Steam in the form of a Wizard's Lizard in 2016. Today, I'm working on my new company, Voladria, where I published my book, How to Make a Video Game All by Yourself. I'm also working on two new games, Witchmore and Pixelwasher, the latter of which is being entirely in JavaScript.

Let's jump into my talk, How to Make a Web Game All by Yourself. To begin, you are a producer. Making a game by yourself is hard. It's a much different beast than working on a team where you may have lots of different people with lots of different skill sets. You probably have your own skill sets that you're eager to use on your project. I'm sure many of you are programmers, also probably designers, maybe artists, musicians or writers. These are all fun hats to wear, but to make a web game by yourself, you've got to take off all your hats and consider the project from a high level. So first, think of yourself as a producer. A producer is responsible for shipping a project. Your job is to ship your web game. What you've got to realize is that it all comes down to you. When you're not pushing your game forward, it's not getting done.

So it's easy to get overwhelmed as a solo developer. One way to help with that is to outsource certain parts of making the game. You don't have to make all of your own assets, like sprites or 3D models or sound effects and music and all that. You can make that stuff if you want to, or you can find pre-made assets that you can fit into your project. For me, I usually like to draw all the graphics myself, like for my game Witchmore, but for Pixelwasher, I'm using tons of assets I've purchased from places like Humble Bundle, where I've found hundreds of charming sprites ready to put into my games. The key is deciding when to make your stuff yourself and when not to. In my case, I had an itch to draw a bunch of witches and stuff like that involving witchcraft, but I didn't really have an itch to draw a bunch of modern pixel art to wash. What I had was tons of assets burning a hole in my pocket. Both of these were making me itchy, which is our next topic. Scratch your itch.

It's different when you're on a team, right? On a team, you likely know your role and what you should be doing. On your own, my advice is to find the tasks that are itchiest to you and do those yourself. For the other stuff, outsource them or otherwise find a way to get them done that's not so draining on your time.

If you really want to make your own graphics, you can and should. There's never been so many online tutorials for learning art, nor so many free or open source applications. You can use Krita or The GIMP for 2D images, or Blender for 3D modeling. If you don't want to make your own graphics, there are many places to get free assets. My favorite is Kenny. Here you can find hundreds of sprites, both pixel art and high def, 3D assets, user interface graphics, and more. See also OpenGameArt for lots of free assets you can use right now.

Similarly, if you really want to make your own sound effects or music, you can and should. Web Games benefit from the Audio Element, as well as the Web Audio API, ready to make your game sound great. If you don't want to make your own sound effects or music, there are so many places to get royalty free music like itch, freesound.org, or freepd.com. So focus on your itchiest tasks, the ones you're really excited to tackle. For the other stuff, consider asset packs or similar solutions to fill in the gaps that you don't want to make by hand.

Next, pick a game engine. The biggest game engines of the day like Unity and Godot do have web exports. These web exports can sometimes generate huge files like hundreds of megabytes for some reason, but these engines can be perfectly fine choices for making web games. For the sake of this talk, let's focus on web-centric platforms. Let's say that means an engine is web-first and either already built on web technology or considers the web its primary build target. With those parameters in mind, there are many great options, but for 2D games, it's hard to argue against Phaser. It's lean, it's mean, it's been around for ages, it does all you want, and it's used by some of the biggest names in the games industry. Also, it's actively maintained by Richard Davey, who's a super cool dude and a great dev. For 3D games, I'd take a long look at PlayCanvas, also supported by super cool devs. Personally, I like to write my games by hand in pure, vanilla JavaScript. No libraries, no plugins, just good times with me and my code editor. Yes, I know, that's weird. I also like to use the 2DCanvas API because it's nice and clean, and I love how it lets me make sharp, crispy pixel games, like those found in my new game Pixelwasher. If you're wiser than me, you might consider making a pure DOM-based game. You'll almost certainly have to touch the DOM a little just to set up whatever else you're doing, but leaning into the DOM can be a smart way to make your game quickly and effectively.

The DOM, or Document Object Model, is powerful. It has input elements, scroll bars, buttons, checkboxes, events, cascading style sheets, fancy animations, and text rendering. Do you really want to re-implement right-to-left text? Because the DOM does it right now, out of the box.

So, picking a game engine can be overwhelming, but there aren't really any right or wrong answers. From using Unity or Godot's web export feature, to writing your own vanilla JavaScript like I do, it's all good, so long as it works for you. You just got to make sure you and your engine meet these two requirements. One, the engine allows you to make games you can distribute on the web. Easy. Two, the engine needs to click with you, meaning you understand it, you grok how it works, and it's a comfortable tool for you to use. When an engine clicks, you're happy and ready to continue with that tool.

Now a note on making desktop builds. If you choose a full-featured game engine like Godot, you're already going to be able to export to the web and other targets like the desktop. But if you're going with a native web engine or writing JavaScript by hand, fear not. There are several tools you can use to make cross-platform builds for your game. Among them are NWJS, formerly Node Web Kit, which I think we use for a wizard's lizard, Electron and Tori. There are also plenty of mobile options, but I prefer to focus on desktop.

Now I suggest making the game you want to play. You'll be playing your game a lot as you make it. It's way easier to do this if you actually want to play the game that you're making. Sometimes you might have an amazing idea for a web game that you're sure could be popular but it's outside of the kind of games you like to play. Go ahead and make those games if that's what drives you, but from my experience, they're harder to work on because you come into the project with less domain knowledge and it's usually less fun for you to spend time with it. If you're making a puzzle game, you'll need to attempt those puzzles over and over again while designing them so it's best if you enjoy that. If you're adding a jump mechanic, you'll need to repeatedly play with the jump to get it feeling good so it's best if you enjoy jumping games. If you're adding a complicated quest, like to an RPG, you'll need to repeatedly play through the steps of the quest over and over again to test them during development. So I hope you think it's a fun quest. Since you must perform these tasks hundreds or maybe even thousands of times during development, it's preferable that you enjoy them. You'll be a happier dev and you're more likely to finish your project. So when you're making a web game all by yourself, I recommend making a game you want to play. Unless you want to find the fun, which is a tricky part of the creative process. Sometimes you know the premise of the game, but you're not totally sure what that one driving force is that makes the game hard to put down.

When trying to find the fun, I recommend looking at your game as a toy. And you could make a fun toy out of almost anything. Some of the best toys take inspiration from real life, like bouncing balls, fishing, crashing cars, cooking, or blowing things up. Make toys out of any of those things and you might just have a fun game on your hands.

Additionally, I like to recommend getting lost in the fun of your game. As a developer, you're making a web game by yourself, your game needs to pull you, the only developer, into your game once in a while. You should find yourself kind of wanting to play. You should find yourself working on a bug, but getting distracted by how cool and fun your game is. If that's not ever happening, try to circle back and focus on finding the fun.

Once you've found the fun, polish up the core mechanic. Find the funnest thing and juice it up using tweens, squishes, wiggles, sound effects, music, and all the bells and whistles that we can with our web games. Now for a boss battle. Manage your scope. Your scope is your game envisioned in its entirety. Since you're making a web game all by yourself, it's extra important to keep your scope down because it's just you working on the game and your resources are limited. So look out for this game dev boss coming your way, Scope Creep, the terror of every game dev. Scope Creep refers to a project's natural tendency to increase in scope over time. New ideas are constantly arising as the game progresses, players offer amazing feedback that create more work, and before you know it, you've blown up your scope. Scope Creep is the enemy of you, the web game producer, whose job it is to ship this game. Here are some tools to help you fight this brutal boss. MVP refers to minimum viable product. In the context of games, try to think about the bare minimum game you have to build to create your trailer or demo your game or just get feedback about whether it's working or not. Build only that and nothing else until the next milestone. Game design pillars provide direction to a project. Your pillars should help you answer questions that are critical to your game's direction. My core game design pillar in Pixelwasher is, it's just about washing pixels, that's it, just pixels. What should I add? Maybe a hunger mechanic? Well, does that help you wash pixels? No? Then, no hunger mechanic. Should the player be able to run? Would that help you wash pixels? Well, if I could run faster, I could wash more pixels. So, yes, you can run. If you're not sure which way to go, refer to your game design pillars to help you answer questions about your game design.

And remember this, you are a producer. Take off all your hats. At some point when making a web game by yourself, you've probably made the mistake I've made so many times, which is I kept one of my favorite hats on for too long. Sometimes I draw too many cool sprites I want to use, or other times I add a bunch of sound effects I found, or I've designed a clever level I want to include. But take a close look at some of these things to see if they really work with the game within your scope, or if you need to take your hat off, let the producer in you take over and cut it. And when you cut, cut deep. You've probably got features and content that you think are really cool, and they probably are. But when you're making a web game by yourself, there's nobody else around to tell you no, so you've got to do it yourself sometimes. It's hard. Find any stuff you've built that doesn't support your MVP or your game design pillars, and is otherwise extraneous, and cut it. Throw away your scalpel and your axe, get out your chainsaw. Cut deep to help you shape your game.

Next, iterate to the finish line. Finishing is one of the hardest parts of game development. At this stage, you've reached that perilous 90% done state where somehow there's still 90% of the game remaining to make. I like to think of finishing as the final boss, taking the form of a giant swarm made up of tons of bugs, and critters, and mean little monsters. There's always a million tiny tasks that you need to get done to completely finish a game. When you're making a web game all by yourself, these tasks can wear you out because there are so many of them and just one of you.

Here are a few ways I like to tackle this final swarm boss by myself. For one, always keep it playable. Look, okay, I know some of you have no idea who I am. Why should I listen to this guy, right? Well, if you don't listen to me, listen to the legendary developer of Doom and Quake. Quote, always maintain constantly shippable code, John Romero. Additionally, here's a list of things I don't do while fighting the final swarm boss. Don't break your build. Don't add anything that breaks other parts of your game. Don't add hungry features that feel incomplete and beg for more work. Don't add something that isn't up to the current level of polish of everything else in the game. And basically, this all boils down to, don't set traps for your future self.

Here's another tip I like to use. Save it for the sequel. You probably have a huge list of tasks that need to get done. I like to add another list, called something like Sequel Tasks, where I move to do items that are cool, but slowing the current project down. When you're making a web game by yourself, there's nobody around to tell you no, so from my experience, you end up with more ideas for extraneous features and content than you might on a team. Some of the ideas are probably out of scope, but they become precious to you, and you have difficulty parting with them. Celebrated author Stephen King recommends killing your darlings, so listen to him. Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler's heart, kill your darlings. So for these darlings of yours, move them to the Save it for the sequel list. Say goodbye, but just for now. This might also motivate you to finish your current game, so then you can eventually focus on those sequel tasks. Now, ship it. You've done it, good job.

Now publish your game on the web. I'm sure some of you have your own web servers, so just upload your game files and you're good to go. If you're looking around for some free options, I got you covered. Itch.io, for those not in the know, is the entry-level platform for indie games. There's nothing better. Itch gives you, the developer, full control. Platforms like Apple and Steam are known for taking 30% of sales, whereas Itch lets you decide the split. Highly recommended. On Itch, you'll be in good hands because this is where amazing games like Vampire Survivors and Pixelwasher offer free demos. The emerging pattern among successful indie games seems to be to offer a free version on Itch and a paid version on Steam. As a quick aside, here's a marketing tip. If you want to attempt to elevate your game that nobody has heard of, try placing it next to a Platinum bestseller. It's highly effective. In addition to Itch, there is also GitHub Pages, which will host one of your repositories for you for free. This is where I host the Game Dev Tiers that play at Valadria.com, which we'll talk about in the next section.

Since we're making a web game, let's take advantage of some of the features unique to the web. Now obviously, a web game can be inherently online and have multiplayer features, but it doesn't have to. Most of the web games I make are single-player, and some of them are download only. But all web games can leverage the web to help promote them or otherwise make them cooler. So let's look at some ways we can do that.

Open share pages. This first example is probably the most obvious one. It's really just opening a web page, but this is wonderfully trivial with a web game. As an example, let's look at The Game Dev Tears. Can I get a show of hands, has anyone seen The Game Dev Tears before? Nobody? Because I'm alone in my own room? Okay, got it. The Game Dev Tears were viewed by over a million people, so I made The Game Dev Tears Maker, which is kind of a web game. It lets you drag around various game dev tasks and rank them how you see fit. At any point, you can click the share icon, which will open up a web page to whatever Twitter is now, pre-filled with any text you want. Easy and greatly increases a game's potential morality.

Starting with The Game Dev Tears as an example, once you've cried your tears, you can download a resulting image. So here is an example, I'll just fill this out real quick. Then we can hit the download button, we find the file, we open it up, and there we have it. Our Tears in Glorious image format. This is done with the amazing canvas API. You can create an image element, then draw whatever you want to it using a 2D context. Then turn that image into data, and force your user to download it using your weird web hack of choice. These images can then go on to be posted on social media, or uploaded all over the place, again increasing your game's potential variety.

Lastly, let's have a big dumb URL party. In this example we're using my web game Indie Game Sim. This game was made in handwritten javascript and is available to play on the web as well as on Steam. So Indie Game Sim is a side-scrolling platformer, but it also lets you make your own levels. These play out in the game as a conversation between you and a monster, but you can also share these levels with friends. There's even a Subreddit where players have posted some nightmarish levels, but the real nightmare are these gigantic URLs. This made me curious to look up how long URLs can get, and there isn't much agreement between major browsers. Chrome and Internet Explorer cap out around 2k, Firefox at 65k, and Safari at 80k.

So what I'm reading from this is that you could make a much bigger, dumber game in Safari. You could probably put your whole game in those URLs. Allowing users to transfer data in this way is an inexpensive implementation that enables the sharing of user-generated content very cheaply. Normally you might need a database, an authentication and before you know it, your game is way out of scope. But the web gives us cool tools like URL hacking, so why not stuff a bunch of characters in there and let your players share data?

To summarize, you can make a web game all by yourself. Following these steps may help you out. Keep in mind that you are a producer. Focus on scratching your itch. Pick a game engine you like. Make the game you want to play. Find the fun. Manage your scope. Iterate to the finish line. Ship it and leverage the web.

I want to thank you for coming to my talk. For a deeper dive on making your own game, see my book, How to Make a Video Game All By Yourself. For tons of free game dev articles and videos, see my website, bladria.com, and my YouTube channel, Make the Game, and my podcast, Make the Game with Matt Hackett. If you have any questions, I will be available in the discussion room at JS Game Dev Summit, or you can find me on BlueSky and the charred remains of Twitter.