Using HTML, CSS, & JavaScript as a game engine

Following the time-honored tradition of using Ludum Dare as an opportunity to try out a completely unfamiliar game engine, my team decided* to write our game using purely HTML, CSS, and JavaScript. Here's some thoughts about how that went for us.

*technically I decided and they were forced to deal with the consequences

Big differences

There are some similarities between a web page and a real game engine:

  • The DOM is in many ways very similar to the tree of nodes found in an engine like Godot.
  • The Web Audio API is extremely capable and can handle mixing audio tracks, looping, and effects.
  • You can use sprite sheets with CSS.
  • ... and so on.

But in practice, the differences far outweighed the similarities. Many tasks that are trivial in a real game engine were a huge bother in a web page, either requiring large amounts of code or deep knowledge of the quirks of web layout. For example, something as basic as positioning entities at specific coordinates in our game window required some fairly esoteric CSS understanding: the "game window" div has position: relative, and each entity has position: absolute and then is given coordinates using the left and top CSS properties.

Screenshot Screenshot of the browser devtools showing *one part of how we positioned entities using CSS*

The bad

Here is an incomplete list of things that we had to do by hand (that a real game engine would have done for us):

  • Ensuring all assets are loaded: Our code handles this, but poorly, by making you think the game is completely broken until everything is finally loaded.
  • Resetting/reloading levels: We had to write a lot of code to move elements back to their starting positions, hide/unhide them, etc.
  • Editing levels: There's no easy way to place a thing in a position and save that. We hard-coded the starting coordinates for every object in our code and tweaked the numbers by hand as needed.
  • Sound: We got it working well, but it required more code and more troubleshooting than expected.

The good

On the other hand, there were some things that the web made easier for us:

  • Browser devtools are powerful: The console was super useful for debugging code, the inspector was great for understanding why positioning quirks were happening, etc.
  • Easy debug UI: It was trivial to throw some <input> elements on the page and use them to control stuff while we were developing.
  • Animations: We just plopped animated GIFs directly onto the page. Luckily we didn't care about starting/stopping any animations, because that would have been difficult.
  • Creative freedom: Our game is not confined to the "game window", and I feel like we barely scratched the surface of what could be done in this environment.

Screenshot Screenshot of our debug UI

Would we use it again?

It's likely! I certainly think there is a lot of untapped potential for fourth-wall-breaking gameplay which would be fun to explore.

Would you use it?

Let us know in the comments!

If you'd like, try our game (it's quite short).

If you liked the music, both tracks are available now on my website (CC BY-SA), and they'll also be appearing on streaming services in the next few weeks.