Making a game in the browser

In the past I’ve dabbled in making browser-based games, or even desktop games. In 2016, I made a nice little rail shooter, complete with its own level editor and 3D assets. It was fun. It was unprofessional as hell. Having some free time recently, I thought it would be a good idea to revisit that with a new perspective.

rail shoot

If you want to skip to the game as it is, play it any time here. It well and truly is still in development, hence the URL structure, and the Heroku 60 second server startup time. Keep the URL hash as it is to play that particular map for now.

Aim with the mouse, fire with LMB. W and S speed you up and slow you down. Don’t get hit. If you can beat my high score of a few billion, congrats!

To reuse, or not to reuse

Professionally, tooling is a simple question. Use the tools at your disposal to produce the outcome you want as productively as possible. Be fast. Be simple. Do not shoot yourself in the foot.

In game development, this translates into using off the shelf engines to solve your needs. There are some great choices out there. Off the dome, Godot is a decent choice. Just look at all these features:

  • It’s got a scene system
  • It’s got its own visual editor (IDE)
  • A friendly content creation pipeline
  • Live editing so develop - build - test cycles are fast (Huge!)
  • It’s extensible
  • PBR
  • A tile map editor
  • A flexible animation system
  • Support for C#, C++, Python, Nim, D, and its own GDScript
  • Integrated documentation (big for a giant dependency)
  • A built-in debugger
  • The editor is 25 MB and works across platforms
  • It deploys to desktops, mobiles, and the web

So, if you want to get a game out there, this is great. Plus, it’s free!

On the other hand, if you’ve got an established workflow, this isn’t so great. This thing could be grossly inconsistent with what you’re used to. You’re going to have to spend a week learning how to learn and incorporate this extra tooling into your workflow. Odds are, if you want to produce a game that’s sufficiently complex, the cost-benefit analysis is clear.

If you’re like me, however, and get more fun learning how the underlying systems work, then buckle up.

Reinventing the wheel

So looking at this, and having a rough picture of the game I wanted to make already, I thought to myself: ‘what systems does this actually need?’

It turns out, a fair few:

  • 3D rendering
  • User input management
  • 2D rendering (i.e.: the user interface)
  • Audio handling
  • Asset management
  • State management

Then there are others which aren’t even implemented yet. Consider managing high scores for user-created maps. This means:

  1. Users can create maps. That’s a level editor to write.
  2. Serialisation logic for maps in the first place.
  3. Somewhere to store them.
  4. Some way to retrieve them.
  5. Metadata accrued each time they’re played.
  6. Some way to display that metadata.

This is starting to tie in broader questions to do with deployment. The silhouette of AWS S3 is looming on the horizon. Does this mean we need to write an API server? How do you manage a database securely, and efficiently?

For now, those questions are left unanswered. Probably going to tackle them next week. In the meantime, I’m going to start a series of blog posts discussing how this game is laid out in code, how the assets have been hacked together, and how the bare necessities of a game engine can be surprisingly easy to bring together to run in ~700kB of total downloaded content (and that’s before trying to optimise).

613 Words

2020-04-08 07:27 +0000