Webrooming
I love the indie web. It’s so colorful, creative, unique and fun to explore. During a late night exploring session, I stumbled across the perfect mix of things:
- A personal website with some little low poly games you could play
- A different personal website with a drawing of their room, with different things labeled. This made me put two and two together and come up with the idea to make a 3D interactive room.
Why? Because it’s fun, it’s different from anything in any of the boring corporate sites, and it gets visitors to know me on a different level.
How did I make it? #
Using Godot. Godot has a web export feature that turns your game into a pck file, two js files and a wasm file. All you have to do is provide it an HTML canvas for everything to render in.
Why Godot? #
I’ve never used Godot. In fact, I’ve never really used a game engine. I picked Godot for three reasons:
- It seemed like by far the easiest (and fastest) way to make a room and put it on the web
- It’s open source
- My friend flow is already familiar with it
Godot is unlike any software development tool I’ve ever used before. The editor makes everything very intuitive, and while it seemed a bit rigid at first, it’s way more flexible than what I imagined. The documentation is really good, and gdscript didn’t feel super duper alien to use. I couldn’t have done this without flow though. They built the core functionality of the project, kind of like a foundation to build on top of and tweak to my needs. So massive thank you to them for making this possible. They also mostly modeled the chair, as well as some other small assets :)
Hacking the web export #
The Godot web export has three different options for how the project is supposed to run: fullscreen, fixed size canvas, resizeable canvas.
I wanted to embed the 3D viewer in a regular page on my website, so fullscreen is obviously out of the question. And fixed size means devices with small or really big screens will either have a canvas bigger than their screen can display in it’s entirety, or a canvas that’s way too small to see.
So dynamic size it is. But if you thought it would just grab the size of the div it’s in, you’re as mistaken as I was. The web export does two things: It makes the canvas’ position absolute, and it makes the canvas have the same size as the DOM.
The first one is a problem because the position being absolute means everything else on the page gets covered by the canvas.
And the second one is an issue because once the position of the canvas is relative, the right and bottom sides of the canvas overflow off the page.
So I had to figure something out. Using Firefox’s inspect element,
I saw position=absolute being added to the style tag of the canvas by one of the JS files Godot spews out.
It’s a massive file, and it’s completely unreadable, so I had to resort to searching with nvim.
Searching for absolute led me to this, where I changed it to relative, and it worked:
Changing the canvas size wasn’t as straight forward. The script actively changes the canvas size to be that of the DOM size.
I had to try several things, search for different keywords, and try to read all that JS to find a solution.
And it’s what’s highlighted on the image. I had to backtrack through several variables and functions until I found that.
csw and csh are the variables that are later used after several steps to set the size of the canvas.
My goal was to make the canvas fit within the screen, so I divided everything by 1.5, achieving the result I wanted.
You can go ahead and try it for yourself at https://slushee.dev/my_room if you want! It takes a while to load, and it’s a bit choppy at first. But honestly, I think it’s perfectly fine. The goal isn’t performance, it’s to have something that’s fun to play with, and I think it achieves that.
And yes. webrooming is a reference to webfishing, even though I’ve never played the game.