Building Web-Based Mini-Golf Game With Dynamic Wind System

Introduction

Hi, I'm a Senior Software Engineer who works in XR and web development. Like many other jobs in the tech industry, it's not exactly game development, but it's what I like to call "game adjacent". I do a lot of work with regular 3D engines like Unity and some Unreal, as well as many web game engines, which I will touch on in the next question. Like many folks who go into tech, I was originally very interested in game design and taught myself Blender and Unity back in high school.

However, after getting into the industry, you often end up finding your own specialties that you enjoy developing for, and I ended up really liking XR development since it combined a lot of my existing skillset at the time with a lot of fun and exciting projects. I don't have a whole lot of game projects specifically, but I've worked on everything from larger-scale 3D projects like apps for Pixar and NASCAR, to web projects like experiences for Jumanji and Avatar 2, to even one-off random stuff like a voice-controlled game for the Google Nest Hub. I think a lot of the skills I've picked up over time have come from the wide array of projects I've been thrown on.

Some projects I've worked on:

Disney Avatar 2 Creature Creator

Google Brainwash

Jumanji 2: The Next Level WebAR

Venomize My Pet

Web Game Development vs. Regular Game Development

Web games hold a very special place in my heart. As someone who played an egregious amount of flash games and .io as a kid, web games as a whole check off a bunch of boxes as far as accessibility and fun are concerned. I think for a really long time, web games have had some technical limitations, both as far as the development tools go, as well as the processing capabilities of browsers.

But as someone who has been slowly seeing the web game dev toolset get larger and larger over the last 10 years or so, I think it's a really promising discipline that's just going to get better over time. I've had the opportunity to design in a handful of web 3D engines (I'll just list some out for reference): pure Three.js, A-Frame, Babylon, PlayCanvas, Amazon Sumerian, and now, finally, 8th Wall's Studio, and every year they all get a little better.

It's actually very interesting to watch some of the newer ones get developed, because you will often see them get into states that older game engines were in THEIR pasts as well. Sometimes I will use a newer engine, and it will remind me of where Unity was back when I was in college or high school.

Here's a YouTube video I made talking about one of my favorite web games: The GROW series by EYEZMAZE, which contributed to my love of web games:

Here's a fun little web game I made in PlayCanvas. Actually, I'm like 90% sure the backend for it is still running. I think it's just a free-tier Heroku slug, so you can probably mess around with it if you want. It's a farming game, but it's multiplayer, and there's also some genetics.

One time, I had to make the Guardians of the Galaxy warp effect for a web project to use as a transition, so here it is:

The Windy Golf Project

This game jam was an excellent reason for me to finally give 8th Wall's Studio an honest shot because both myself as well as the company I work for have been interested in building out some projects using it. And the main thing I wanted to accomplish with this project was to see if it could do all the things I wanted it to do. I wanted to test out overall development, its shader and visual capabilities, as well as overall architecture design.

The easiest and obviously funnest way for me to knock this out was to create a wind system and grass shader and base everything else around that. Because of this, I got to test out the event system and how things like to be tied together, as well as the flexibility the engine has as far as shaders go. Now, as far as the grass itself goes, it's probably no secret that I am a fan of The Legend of Zelda: Breath of the Wild. Ever since that game decided to throw in dynamic grass, it has kind of changed the standard for what is expected in foliage in modern games. I think BotW uses a geometry shader for the grass, which is not what I ended up doing because that's not exactly something you get access to on the web side, but I think instance shaders run fast enough that it wasn't an issue.

There's also been a few games in the last few years, like Ghost of Tsushima, that use wind that interacts with their foliage as a game mechanic, in their case navigation, and I personally thought that was a very nice touch and wanted to have a similar sort of "global wind" mechanic in this game too.

Some clear inspiration and grass I made for the game:

Camera Intro to one of the levels:

Developing the Game

I started development with the grass shader because I figured that was going to be the most visually appealing part of the experience, so I wanted to get it right at the start. Getting it working was actually not too hard since a lot of it was just using some of my limited Three.js experience to force the engine to do what I wanted. After I got the niceties of the grass out of the way, like making it sway, flutter, and deform based on ball position, I then exposed a wind direction vector that I could set externally. Then it was on to the second most important feature, which was the global wind control.

This sounds really complicated, but it was literally just an object in the scene that fires a global event with wind direction. After that, it was pretty easy to add new features that hooked into this. Any new "wind-affected" object or mechanic simply needed to listen for that event and act accordingly. Things like the flags and windmills turn with the wind, and certain items are powered based on wind direction.

Then it was onto making assets. I personally didn't really end up using the 8th Wall's asset generation. I did, however, use some of the assets that they had created for the experience. Pretty much all the assets they created used a shared texture that contained a few gradients that they used to toon shade their models, so I pretty much piggybacked on that and used that same gradient sheet to texture my whole experience as well, so that the visual style wouldn't feel too different.

Finally, I wanted to put in a few "polish" notes. The main one was making the ball have a different rolling sound depending on whether you were in the grass or not. That actually took a lot of time to set up, and also to create the ball rolling sounds was a lot of tweaks in Audacity, and even then, I don't really love how they ended up. The other two main things I created were an intro camera that shows the level, as well as a short UI tutorial for the level. Neither of those was too hard, as the engine had easy ways to do them both.

Here's a brief description of how I set up the grass shader:

Using 8th Wall's Studio

8th Wall's Studio is still up and coming as an engine, and making really fast progress as it is. Currently, it has some of the same benefits as a lot of other web engines, like A-Frame, for example, where it gives you pretty much direct access to the underlying Three.js components on which it's built. Allowing you to more or less do anything you could do in Three.js if the project calls for it. However, my ABSOLUTE FAVORITE decision that they made with this engine is that it is architecturally built around everything being state machines. Every single component you write is more or less built around having state-based logic, which, in my opinion, helps you organize things in a way that keeps them making sense.

Obviously, you can just opt not to use it, but I think in like 90% of situations, you may as well just use it, or simply assume an object has one single state. I ended up having to get a lot of use out of it because some things aren't guaranteed to be loaded when the scene is active, so giving any script an initial "loading" state solved a lot of problems for me.

There are a few disadvantages to be sure, but they are mostly a result of this being a relatively new engine. When using the web version (this is not an issue with their newly released desktop version), you can run into some issues with server sync whilst manipulating objects in the scene in the editor, which can make development relatively difficult. It also has a few bugs that they're ironing out. Another issue that I believe they are also working on is that you currently cannot export a project to be hosted somewhere else, which means any experience you currently build using it has to live as an 8th Wall's Studio project and can't just be a canvas in your React project, which has a few downsides.

Finite state machine system out of the box: best thing ever.

I really got to watch the 8th Wall's platform evolve over the last 7 years or so. Here are some snippets of projects I've used it for, leading up to this one.

Original face tracking project:

Rainbow Crunchies (one of Inworld's first projects):

Hand Tracking:

Multiplayer AR where the host controls the ship, and friends control the cannon:

Conclusion

I think this game jam was around 2 weeks, and my strategy for finishing everything in a reasonable time was to just finish the core gameplay as fast as possible, and make everything else "polish" or "nice to have" notes.

I believe I had the core functionality of the grass and wind system done within the first week, which gave me a whole second week to just work on things that I personally thought would make things feel better. The most important thing is to push your changes whenever you have something working. In 8th Wall's Studio, it's in the form of "landing" the project. Yeah, you don't want to end up destroying a perfectly working game to add in an intro camera if you don't have to, it's very disheartening.

The best button:

I would recommend picking an idea you want to build and just building that. Usually, the best way to learn a thing is by just doing it. I would also highly recommend that any time you want to implement anything, you go to the 8th Wall's Studio projects or documentation and just look to see how it's been done before.

As someone who has used a number of different engines before, I think the MOST important part of learning any new engine is to learn how the developers intend you to use it. I can't tell you how many times I've ended up slamming my head against a wall because I was using the design paradigms of one engine in another, when the designers absolutely did not intend for it to be used that way. As far as participating in a game jam, go join the 8th Wall's Discord. They are very helpful as far as learning, and they are also very good at posting announcements for events like this one.

Andrew Kurano, Senior Software Engineer

Interview conducted by Theodore McKenzie