Hi!
I recently launched an HTML game on Steam called Wilderplace.
I'll explain how it works, then discuss the benefits and limitations of
my approach.
My Goal was to make a game from scratch. Wasting time re-inventing wheels?
Sounds fun!
Start from a blank page. The art lead the way.
No engine. High resolution isometric graphics. Runtime synthesized audio.
Full gamepad support. 100% HTML, CSS, and JS. 60 FPS!
Packaged the game with Electron, used Github actions to automate Steam
releases.
Game engine architecture.
Most unconventional thing: DOM for rendering instead of Canvas, WebGL, or
even SVG. Everything is DIVs!
Any web developers here? Raise your hand if you know what the DOM is 🙋.
Why DOM rendering?
- Unmatched for UI / Text.
- Great developer experience.
- Responsive design.
- Mature Accessibility features.
- Can get fancy with 3D-transforms, layer effects, SVG filters.
- 60fps animation, within limits.
The web can do everything now.
-
Typescript is a serious language, V8 is fast, can even use WASM. Look
at PlayCanvas or Construct!
- Fast iteration speed with hot reloading.
-
APIs cover all your needs (gamepad, audio, multithreading,
webrtc/websockets, disk access).
-
Straightforward to release cross-platform desktop, mobile, xbox(?).
Disadvantages:
- you need a browser! That's a lot of overhead.
- Performance can't yet compare to alternatives.
- Hard to release on Playstation or Switch.
- Lack of community, tutorials, asset ecosystem.
- Web-based game engines are getting good, but not Unity/Unreal.
What's next?
- Make more games.
- Save main thread for animation, use workers.
- Find more reactive approach to animation.
- Combine canvas and DOM.
- Scale up with spatial partitioning.
- Multiplayer!
- Working toward a reusable engine.
Thanks! Questions? Check out Wilderplace on Steam, and follow me on
Twitter @samanbb.
