max bittker

Transcript

Thank you for being here. I'm really excited to talk to you, and I'm going to get started by introducing myself. My name is Max, and I'm a developer, and I'm an artist, and my day job is that like lime a user-experience engineer. That basically means that I'm an engineer and build things and it's directly informed with the way that the user perceives it, and by the effect that it has on them and their perceptions. I also really love websites, particularly websites which are like useless or weird.

I think those are the most fun thing that you can build on a computer. I'm talking today about building inter active experiences with WebAssembly, and I have to level with you before we start that this talk is a little bit like a Trojan horse situation, so I lured you into the stands with a promise of exciting web technology like WebAssembly but I'm really going to talk to you about my favourite things which are falling sand games, so I hope that's not a problem! So, if you hasn't heard of falling sand games, they are kind of this whole genre of web games like free flash applet kind of things where you have a palette of pixelated elements - pixelated phenomenon. They interactor with each other and cool things happen. They share a lot in common with Conway's Game of Life, and, in particular, they have the same kind of really cool behaviour behaviour where you have simple rules, and when you let those play out, you get really amazing complex emergent behaviour.

It can be really surprising to even the person maybe who set up those rules and certainly the person watching them play out, because you could never expect exactly what you would get just based on reading that it does this, and these conditions are that. It's much more complex. Another thing I love about sand games is they have a low fidelity visual representation of what is happening on screen. You have a couple of coloured pixels maybe moving around a little bit but there is so little to go off, that it lets your imagination run wild and interpret what you're seeing with its own layer over what is going on, so you see something much more vivid in your mind's eye than what is going on in the screen, and there is a lot of room to play with that, and that's really fun.

So many people oftentimes ask when they see these games like how do you win this game? There is no win condition or score or anything like that. The way the games work is that you're making your own objectives as you play, and that's part of the game. Oftentimes, that means understanding what is going on in front of you, so maybe you're trying to figure out how a new element works, or how it interacts with another one.

You might make a hypothesis about what happens, make an experiment and test it out, or maybe you will be like telling yourself a story, and playing it out with the elements in front of you, and seeing what happens and imagining your mind, and so on, and so I think it's really wonderful mode of play, and it is one where you're not only the player, but literatures kind of a story-teller for yourself. So my favourite falling sand game has been for a long game called the Powder Game. And it kind of has this really interesting feature which is that when you make things in it, right in the game, in the menu, you can upload them, and they go to a server, and other people can browse them and see them. It's got this long-standing weird and thriving community of people building interesting things, and uploading them for each other. And it's really cool to see, given like just these small tools, the kind of things that people make for each other to play with.

So you've got like your bog standard is thousands and thousands of volcanos. You know, it's like an infinite fourth grade science fair of different volcanos, but they're cool, and I can see why people want to make volcanoes. People make different destructible structures so you can load it into your browser and then have fun setting it on fire, or pouring acid on it, and that is like a fun way to play with somebody who you've never met.

People get really creative. There are all kinds of games that people make out of the simple elements they have like mood rings, and you can see this one says it is clear it won't be accurate of your mood unless you first vote. There is a lot of vote-pandering in these communities. It's a staple of how they communicate, but this is a cool game that somebody made inside another game.

My personal favourite type of sand game upload is this entire genre called Don't Smoke where it displays to you anatomical phenomenon that will that will happen if you smoke a cigarette, like the lava will travel up and explode your brain. These games are awesome.

You can see why I was fascinated with them for my entire childhood. As I get older and first learned to programme, as soon as I could run two for loops together, I knew I wanted to build a falling sand game - the best one of, obviously! I knew a bit of JavaScript and knew how to use an API, and I looked at other sand games and how they were working and what the elements were doing had they were moving around, and when I was re-implement ing them, I found they are really simple, and, with just a couple of low numbers of hundreds of lines of JavaScript, I suddenly had water moving around the screen. I was really excited, and I was having so much fun, but I realised that as I kept adding new elements to the game, it was getting slower and slower, and I didn't have a very firm grasp on concepts such as like functions, or having your code in more than one file, and what I was manifesting was as I was adding more features into this big blob of code, everything was getting more and more buggy. You can see this blob on the right-hand side of the screen was an element that was a mistake I made decided to domesticate and keep in the game as the given element. I couldn't understand what was going on any more.

So I was okay, I'm going to have to do, refactor this code somehow and make it good. I didn't know exactly what that meant but I knew I needed to be in different tiles, so I had to set up webpack so I could have different JavaScript files. This is the last commit I made to the project in 2015.

Used webpack for my pending factor which never happened. I think this is a common story. So some time went by, and I got a cat. I moved to California.

But other things were going on in my life but I was still thinking about sand games, and I was noticing a lot of cool projects that were happening that were letting people build and code in the browser, and kind of make programme one element of a larger system. I thought that was really cool. So I had this idea that I got excited about last year which is what if there was a falling sand game where people could code their own elements and upload them, and then all those elements by different people could interact, and there could be reactions that nobody ever anticipated, and something could happen? So I kind of knew that I needed a different architecture diagram for my game rather than having anything in one file and one blog, if people needed to write code, there would be separation to an engine and maybe the different elements, and I was maybe inspired by things like React and I thought okay, there can be an API that they talk over, and be the framework, and then the components.

But I also knew that if I wanted people to actually code and upload their elements, there would need to be a pleasant and easy experience, and I don't need to handle as many of the edge cases as I could for them. I started to prototype this and trying to move the gross logic out of the elements and make them as easy and fun to make and make the engine, if it had to be gross, that was fine. I was really happy with this prototype and I was having so much fun building elements in it, I was having a great time thought I want to keep doing it and if I know anything about if you want someone to use your thing, it's got to be on the web as far as I'm concerned, and so I wanted to start over and build it so that I could actually share it with people. So that kind of turned into Sand Spiel. The rest of my talk is boring, if you want to do that for the next ten minutes, I'm not going to judge you! So, but I will give you a quick demo so you can see what it looks like.

I will press play. You've got your different elements. I will plant some flowers.

And then I think that people then set everything on fire, but it's okay. Doesn't release any carbon! So, that's kind of what the game looks like, and you can see there is this canvas where the simulation is happening, and there is the buttons and the UI. So, the one of the things that I found when I was building Sand Spiel that turned out to be critical and helped me to build it was that I decided to try to use WebAssembly. So there is actually WebAssembly in this talk, I'm sorry.

I've said that word a couple of times now, maybe you've heard it this week, but just to, like, rehash, WebAssembly is not really a language it's an instruction format that you compile instructions to and has properties that people are excited about. First of all, it's fast, so I'm not going to go into detail here because this is kind of any kind of performance conversation, but particular ly it is, if you have a lot - it's predictable what the performance will be.

With JavaScript, you can make it fast, but you are relying on the way that it gets optimised, and you need to write it in a very careful way, whereas with WebAssembly, there are much less moving pieces, and, if you write it in a certain way, you know it will be fast on everybody's browser. Another important aspect of WebAssembly is that it is sandboxed. So it is safe in WebAssembly to run code written by someone who you don't necessarily trust on your machine, or even on your user's machine sometimes, and it's not going to steal their passwords necessarily because it's sandboxed. It can't reach into the rest of the system like some native code can. I thought this was going to be an important thing for my of the game because I thought I was going to be running people's code they wrote, and running it on other people's computers, but it turns out I never got to that part.

That was ambitious. In the future, this will come in handy, but just the other factors of WebAssembly were useful to me. Lastly, I want to let people know that it really is ready to use. I was surprised for this myself, but, you know, like four major browsers and some other ones as well have already implemented it.

It works also like a mobile really well, and I was, I'm surprised by how fast it's moving and the spec is pragmatic and informed by what browsers I we already have as far as structure, and there is a lot of - it so is it is becoming something that you can ship. And I had no problems with compatibility, surprisingly, with WebAssembly. One more thing about it being ready to use is that the tooling is, at least in my experience, was really good. I wrote some Rust code for Sand Spiel that was compiled to WebAssembly.

The entire tool chain that I used to do that, including tools like Wasm and Pack, which let you respect ively compile Rust code into a JavaScript file that loads it, and a tool for kind of calling in between from WebAssembly and JavaScript, these tools are still like in beta but nice to use. There is a lot of shared culture and shared communication norms within the JavaScript community and the Rust assembly community. If you have expectations about how a library should work and how a documentation should be and what sort of error messages it should give you that you're used to from writing JavaScript, go you go to write Rust in WebAssembly, you won't be shocked or horrifies because it's a lot of the same people.

They have the same expectations you do of what a good user interface is for a tool. This was really great, and I appreciate being able to use this. Another really critical thing about that I want to tell you about the way that you can use WebAssembly is that you don't have to write your whole application in it and it happens to run in the browser and it's just a big hunk of Rust or something. My app is 50 per cent JavaScript and about 50 per cent Rust WebAssembly. This was awesome because I got to put the things that needed to run many, many times a second, and be really fast.

I got to write that in Rust and make it fast. Then all the things that don't need to be fast because it's just like, you know, building user interface, or triggering a network request, all those things I got to write? JavaScript and benefit from the fact that JavaScript is really good at doing these - and also that I got to use the whole ecosystem of React in different tools made this really awesome. If I had tried to write the whole thing in Rust, it would have taken longer because it's like there's no good tools right now for building interfaces yet, not like the way there are in JavaScript, and so being able to split my concerns here was really awesome.

I think you can kind of imagine like the JavaScript code here is most ly just, you know, React code like you may have seen before, and the way it interacts with Rust, is that essentially, there is a gist-like class that has some functions, and - and from the respect of the, it, you're calling the JavaScript functions. I have a paint method which will draw a circle on to the screen in a certain element in a certain radius, or I have one to reset the canvas, or to calculate a simulation. From the JavaScript perspective, you're really just calling some methods and it happens to be implemented in WebAssembly which is fast. That is some of the tools like I mention before.

So, as for the WebAssembly code, it looks like this tick method which ones one frame per simulation. I will show you how it works.

This is by the way what powers this part of the game, where the pixels are moving around and interacting. So essentially, I have a data structure which is like a big two dimensional array of all the data for my different cells of the grid, and it goes through, loops through each one in order, and, when it gets to each one, it runs an update function based on whatever the type is of the grid itself, and so you get to the third one, and it's a sand grid. It's a piece of sand, so it matches to the sand update function, and the sand update function is really simple. It's like an if-else statement, and the way that that works is it it looks at its local co-ordinate system and says what is the cell below me? What is the type of that? If it is empathy, then I can fall down, and I will just go down there, and I will erase myself and rate myself one pixel lower. If that first check failed and there is a piece of stone underneath you, then it goes to the second statement, and it checks one of the diagonals and tries to fall there.

And it does the same thing. So that is all there is to this algorithm that lets you do the sand, and kind of the trick here is that it is happening on every pixel of the grid, and it is happening at 60 frames a second, and it starts to look like how you would imagine sand would work. So there is, like, 18 other elements, and some are a little more complicated but they have the same pattern of they're a single function, they call some APIs to read anywhere neighbours and to write to their neighbours, and then you get different behaviour.

So, I mentioned this earlier, but it really was like the key to being to make this project quickly, the fact that I could put things in WebAssembly that needed to be fast and I could implement everything else in JavaScript, and use the ecosystem, and not have to worry about all the type-checking and all of the other conditions that Rust enforces on your code that can sometimes slow you down, and, so another thing that I mentioned is the network code which is I also build like an upload and download functionality that I really liked, and so this has been the most gratifying part of the project, so, a lot of - it's pretty much middle-schoolers, but a lot of middle-schoolers play this game and draw amazing things. They ignore the fact that there is a simulation attacked and use it like MS Paint and not blocked in their computer lab which is maybe why they use it, but they draw awesome stuff, and it's fun to see what they do. I think like maybe one of the - so the most popular, there's an upvoting system and the most liked and loved post is this puppy. I can't explain it, but I also loved this puppy.

There is fan art and people remixing her and drawing her in different situation. On the right, that's Super Duna Luna, the tall one. In the Powder Game, there was a rule against load ing somebody else's submission.

We encourage forking in Sand Spiel which leads to this fun stuff. Unfortunately, I mentioned that the best part of the project has been seeing the things that people upload, but it's also been the worst part of the project as well. Not everybody is nice, and there is like, I moderate the posts every morning and waking up to it is not always fun. Sometimes, I feel like this person where I feel like these people are ruining the game, and I wish it had never been created so none of it would happen.

And so I do do some manual moderation, but it's really not sustainable, and I'm not sure what to do, and so I've kind of, like, looked to where I look for to solve problems when I have programming problems, and they've not been useful, like, there's no algorithm that would be nice for making people be nice to each other on the internet. Not even like string-matching algorithms work, I tried. And like, nor do other places where who have usually solved my tough programming problems, like CSS tricks, they have no button that will make people be nice to each other, unfortunately.

This is a problem I still have. I haven't solved it, and I know there are people who have problems like this, and I'm definitely curious to hear what they did or if they're just like there's all this invisible work that happened behind the scenes that made it look like things are nice. I definitely would be interested to talk if you think you know a solution. Please do not tell me to use a neural network! Thank you! So, please do, I think we have a break after that, so please play with Sand Spiel if you want to kill some time and chill out.

I have a longer form blog post that goes into more of the inspiration for the game and some of the design decisions, and also into some of the technical details because I glossed over some things. Thank you so much! [Cheering and applause].