 You're very lucky. Especially you. I'm going to break tonight into two parts. First I'm going to reprise the Cold War talk I've been giving over the past six months or so. I've presented Cold War at J.S. Confus in Florida, Web Directions Code in Melbourne, Australia and TXJS in Austin, Texas. After the talk I'm going to introduce you to the Cold War platform. So Cold War is an environment for writing your own simulations. It comes with a bunch of built-in simulations and I'm going to walk you through some of those as a way to show you how the platform works. And hopefully if we have enough time and everybody is not too faded, we'll have a look at a little bit of code and maybe we can bootstrap you as you write in some of your own services. So when it comes down to it, Cold War is about a construct called the game group. The game group. This animation is called minimum viable warfare. At the bottom we have a base. It can fire a single shot into its defence for raining down from the sky and missiles. The assault intent is to destroy the base. This is the foundation of some kind of game or simulation. It has the basics, but it's kind of boring. So let's tweak the parameters. Here the sky can fire two missiles at a time to try and destroy the base. This swings the odds heavily in the sky's favour. It's going to win quickly every time. So let's tweak again. This is more like it. Here the bases can fire as many shots as they want to try and defend themselves from the missiles raining down from the sky to the impregnable defects until they run out of bullets. And it's just a matter of time. So let's tweak again. Everybody can fire as many things as they want to try and defeat their enemy. It's amazing. It looks like fireworks, but the astute JavaScripter will observe the browser. It's starting to jank. What's a jank? It's nearly 2016 and everybody in this room should know what a jank is by now. Let's see some diagnostics. There are two things going on. We have an update phase and a paint phase. In the update phase, we do all the most required to work out where our things should be on the screen. In the paint phase, we draw them to the screen. To achieve smooth animation, we need to do this 60 times a second. This gives us a time budget of approximately 16 milliseconds to do all of our work. If we exceed our time budget, the diagnostics go red and the browser starts to jank. But not all hope is lost. We're getting nearly 2,000 things on the screen 60 times a second before the browser even starts to break a sweat. This kind of performance is okay. In more detail, this is what we do. Forever and ever, we go update, paint, update, paint, update, paint. This is called the game group. The game group. But do not do it like this because you will burn out your CPU. So instead, we use window.requestAnimationFrame. Here, we ask the browser to call us when it's ready to draw a frame on the screen. We update, we paint, and we launch another callback request with the browser. The process repeats. In an ideal world, the browser will call us 60 times a second and we will get smooth animation. In this set of variables, we use to represent the universe we have created. We update these variables according to some rules. We use the values of these variables to tell us where to draw stuff on the screen. We clear our painting surface, we draw stuff to it. Easy. Job done. But real life is never easy. There is no guarantee the browser will call us 60 times a second. It has other things to do and we are not that important. So we have to work out the time difference between now and the last time the browser called us. And use that to create a scaling factor for all of our physics. If we do this right, and not all the edge cases are covered here, we will get smooth animation. When it's time to draw, we use HTML5 canvas. But great and unloved canvas there. Canvas is amazing. It's supported everywhere except for IE8. And IE6. And IE5.5. And I do not think IE4 had canvas on it. We have an HTML tab. It's a canvas tab. We get a reference to that tab from the DOM. We get a drawing context from that reference. We call methods on that context to make stuff appear in our canvas, in our browser, on your screen. Easy. But to truly understand IE5 canvas, we must understand how a computer display works. Back when Ronald Reagan was the President of the United States, computer displays were made out of a glass tube. When he entered that glass tube the carbon rectangular on the interior surface of that large grid angle was painted the coating of the phosphor. At the rear end of the tube there was an electron go. It would fire a stream of electrons down the tube towards the phosphor coated surface. When the electrons strike the phosphor they would cause it to glow to your periphery. Wrapped around the stream of electrons was a set of magnets. These magnets can cause a beam to be deflected horizontally and or vertically to any location on the front of the glass tube. Now, if you have a region of memory, and you sequentially read the values of the bits in that memory and use the values of those bits to modulate the electron beam on and off as you scan it across and down the front of the glass tube, you can cause a representation of the values held in those bits to be painted to the front of your screen. This is how a bitmap display works. We call this a raster scan display. A raster scan display. Raster scan displays are the foundation of all computer displays in use today. But there is another way to do it. Back in the dawn of computing history computers were far less powerful. You would implement your display in hardware. You would send a list of drawing instructions to your display circuitry. These instructions would cause the electron beam to be deflected around the front of the screen, much like you would draw lines on a piece of paper with a pencil. This technique is called vector display. Vector display. Vector display is one amazing property. Simply by multiplying the density of the magnets that deflect the beam as they are scanned around the front of the glass tube you can cause the image to be scaled up and down with incredible ease. Just by modifying the value of one or two bytes of memory. To do the same thing on a raster scan display requires a lot of complex map. You have to calculate the position of every pixel you want to draw way out of the league of a computer from the dawn of computing history. Tragically, the technique of the vector display has been lost to the sands of time. But HTML5 canvas gives us the best of both worlds. We can rotate the scale and translate our images with incredible ease. There are bitmaps around the screen with wild banded. And if you look closely you can see vestigial move to line to commands that are the direct descendants of the original instructions used to scan an electron beam around the front of a glass tube. Just how much wild banded are you asking? Here we try and draw as many shapes on the screen as we can. We cut off the screen with shapes before it is drawn. Each shape is translated and rotated. We're getting 2700 odd shapes on the screen in 5.6 milliseconds. 60 times a second. If you're trying to do 60 frames second animation you still have around 10 milliseconds left every frame to do all of your math. JavaScript can do a lot of math in 10 milliseconds. Your first tip to truly mastering HTML5 canvas is understanding these transformed commands. Canvas operates on a grid. The origin of the grid 00 is at the top left of your canvas. If you draw a shape around 00 it will appear in the top left of your canvas. These transformed commands let us modify the grid before we draw stuff to it. For example the translate command, it moves the origin of the grid relative to the current origin. So if we transform to half the width and half the height of our canvas on an untransformed canvas, our origin will now be in the center of the canvas. If we draw a shape around 00 it will appear in the center of the canvas. We did not have to do any complex math to do this. Rotate and scale operate in the same way. We can put an image at any size, at any position, at any rotation on our canvas without having to do any complex math. Get your head around this and you're well on your way to make full use of canvas. So what have we got? The game update request animation frame. 60 times a second. An HTML file canvas. A reasonably performant way of drawing stuff on the screen. Let's make a simulation. This is a pretty famous simulation called flocking. Flocking. Each of these things flying around the screen is an independent actor. It minds its own business. It observes the world around itself and decides what to do based on what it observes. The little white things follow a few simple rules. They want to fly in the same general direction as their immediate neighbors. They do not want to crash into their neighbors. If they get too close they will turn away. And they do not want to get eaten. If a big red predator gets too close they will turn tail and run. The big red predators are far simpler. They turn towards the average of the position of all of the little white things. So from a handful of simple rules we get some behaviour that is spookily organic. It looks like fish in the ocean avoiding sharks. What we did not do is program the behaviour we wanted to see. We made a set of rules and the behaviour we got came from the interactions between those rules. We may or may not be able to predict the behaviour we get. We call this emergent behaviour. Emergent behaviour. We are going to use emergent behaviour to try and simulate nuclear power grid. Let's see how we can predict the outcome of this simulation. Any predictions? Yeah, everybody dies. Alright, what the heck did we get to see? Well, if you want to have a war you have to have a nation stand. The heart of a nation is its capital. If you lose your capital it is game over. The capital commands and controls. And in our case it acts as an air defence system. We have a set of successive defensive parameters. As they are breached we escalate our response towards the enemy. The whole of a nation is people. People are born, they go to work, they pay taxes, they die. They provide the labour for our military industrial machine. People work in factories. In factories they produce munitions, the weapons of war. Munitions are stockpiled at bases. People go to work in factories. The munitions they produce get stockpiled at bases. When it is time to deploy said munitions against the enemy, the capital tells the base to attack. The base determines the method of attack. We have bombers. We have fighters. We have anti-blistic missiles. We have intercontinental ballistic missiles. The weapons of war. Now if you have a hegemonic nation state sitting just over the border looking scary stockpiling munitions, you will probably want to destroy it. You will see your bombers. Bombers are big and slow and powerful. They play long distances and drop their apocalyptic payload upon the enemy. If you see a swarm of supersonic bombers coming over the horizon towards your factories as it is, you will scramble your fighters. Fighters are fast and small and agile but not very powerful. In sufficient numbers they can swarm and overcome incoming enemy bombers. Pretty soon though you will get sick of this air war business. You will have your scientists to develop you some intercontinental ballistic missiles. as an offshoot of your space program. These bad boys flooded the edge of space and rained down apocalyptic oblivion upon the enemy. If the enemy starts launching missiles your way, you will scramble your anti-blistic missiles. Cheap and only moderate effective, these puppies fly up and explode near incoming enemy ICBMs. If effective, they take out the warhead and rain down radioactive debris upon your jungles and shipping lanes. Being a First World Nation, we have a decent space program. You will have your scientists to develop you some killer satellites. At a cost of mere billions to the taxpayer, these sit in low earth orbit and go near buying enemy ICBMs with their high powered lasers. If they're close enough. So that's the rules. Let's have a look at it in effect. So you guys over there you're cheering for that side. You guys over there you're cheering for that side. Two nation states square off stockpile of emissions until one barmy Tuesday morning one of them will launch a sneak attack. That's these evil bastards over here. Blue bombers fly towards yellow tanks. Yellow scramble their fighters in defence. Will they be successful or will blue punch through the middle and start destroying things. Yellow launches a counter attack. Blue is under attack. But it's strike to blue. Off go the missiles. Who will it be? Definitely they'll be some chillies. You want to watch another one? See some noise. Who will be launching a sneak attack today. That's a decent spot when they go there too. This might not be the world. When I programmed this I had no idea how the bombers would fly. You can see some always punches in the middle, some go around the edges because the bombers try and avoid each other. That means the ones that go around the edges come out of the back of the defences. That'll teach you. So we've seen how it works. Let's have a quick look at what goes on on the inside. We have a set of variables we use to represent the universe we have created. In our case we will not be so greedy. We will just create a world. A world has a surface area. An X and a Y and an airspace. A Z. We create a world with these proportions. It makes them available to anyone who has reference to the world. If you can see the world you can see how big it is. We initialise our world. When the world initialises it creates containers for all the actors in our simulations. We have capitals, bases, bombers, explosions. Many more things. But the heart of our simulation is the nation state. The heart of a nation state is its capital. We create our capitals and each capital spawns all the assets it needs to make a nation state. We make it capital. We push it onto the world's list of capitals. Now if you can see the world you can see all the capitals in that world. We give the capital a reference to the world. We give it a team colour. We give it a position on the map. The capital creates all the assets at once. But we look at say bases. It has a limit of how many bases it can have. We count off to this number. We add these bases. We push them onto the world's collection of actors. The world base has a reference to the world and knows who its capital is. And we use some kind of algorithm to work out a strategic location relative to its capital. Once we've made all the assets in our simulation, we start to gain them. We update, we paint. Repeat. 60 times a second. Everything from here on is 60 times a second. We update. We pass on our scaling factor for our physics. We iterate through all our actors. Each actor gets a chance to update. For example, a base. It asks its capital, are we at war? Should I be launching an attack against the enemy? If I've got some bombers in stock, I'm going to make a new bomber. I give it a reference to the world. It's capital. I pick a target for it. I give it a location on the map. The bomber starts at the same location as the base. Finally, I depict my list of bombers, my stock of bombers, so I do not launch an infinite number of them. The update code for the aircraft is awesome. Making a bomber. We make a bomber. It captures these references. In those who it's target is. In those who it's alive. We manage this position with this vector object. We store the position in a separate object. We go through all our bombers. They update. If they be destroyed, we splice them off the list of bombers. They get garbage collected. The update code for the aircraft is probably the most complex part of the suit. But it goes something like this. I have a look at my target. If somebody else has destroyed my target, I pick a new one. I fly towards my target. If I'm close enough, I'm going to destroy it. If there's a friendly aircraft nearby, I make sure I don't crash into it. If there's an enemy, I avoid them. But if they're close enough, I want to destroy them. We manage the position at every anchor in our simulation using this vector class object. It holds an x, y and a z. But it also has a number of methods attached to it. Many of these methods take another vector as an argument. This lets us perform operations of two different vectors. For example, a bomber flying towards a target, like my position. I have the target's position. I subtract my position from the target. I normalize it to unit length. I multiply by my velocity and add it to my position. It's just a really simple algorithm for flying towards a target. Shooting is the same. If the target's in range, I want to be able to attack it. Really, it's just a three-dimensional version of Pythagoras theorem. But instead of expressing this in code, we use methods on these vectors. This lets us come back to our code three, six or 12 months later and see the intent of our code rather than actually having to decode our mechanics to make it happen. So it really is. If it's close enough, shoot. It makes it much simpler to manage the simulation. When it's time to draw, HTML5 canvas. We have a canvas tag. We get a reference to it from the DOM. We have it on our page. We use some JavaScript or CSS to scale it to fit our browser window. We work out how big it is. We calculate the scaling factor between the size of the canvas and the size of our world. We're going to use that. Every time we paint a frame, we clear our painting service, we save the transform state, and we scale our canvas by the scaling factor. This means when we draw on the canvas, we can use world coordinates instead of canvas coordinates. Basically, we don't have to do any math. We can literally use the values in the position object to draw our actors on the screen. We iterate through all the actors. We give each actor a chance to paint himself. And we pass it a drawing context to use. Finally, we restore the canvas back to how it was. So for example, we end painting a bomber. We save the transform state of the canvas. We translate to its position using world coordinates. We rotate to face the way we're flying. And we draw a shape. Put the canvas back to how it was, and the next effect, it gets a clean canvas to draw with. So when we finally get to draw the bomber, we draw our N00. It's already been rotated. It's in the right place. We can just draw our objects using really simple terms. And as little as the scaling factor is for the design phase of our project, we can just change one number and make our item bigger or smaller. This is roughly how Colourball works. To fund them into a concept, update the paint. It's really simple. Before we look at the platform, we've got one more simulation to look at. If anybody does not like this one, they can blame Thomas, because he said it was all right. Come on, I want to hear some cured paint. Best of three, okay? I don't think this is realistic. Oh, that's pretty realistic. Maybe my catography skill is not quite enough. Why is the country kind of having a bit of a problem? With its water. It needs to be a little nervous. I'm under inflammation. Is this it? Bring it out. Are they randomly generated? I know the update is that place, but this morning, there's a degree of red in there. Is it based on the real economic figures? I have to be careful with which country I pretend this in, because I'm getting a bit of trouble. Okay, I'll do it. So if you've got a laptop, pull this up. We're going to have a look at the platform now. This is a bit less formal. If you've got questions, throw your hand up, and we'll see what we can do. This is a platform built in these concepts. When I write the talk, it's a slide deck written in the browser, but what I've done is extracted all the simulation stuff from it and tried to package it up a little bit. What we're looking here is a bunch of different scenes. This is an index page for all the simulations this thing ships with. I've got a few more than you'll see on the website because they're my crappy ones I'm trying to develop now. I'm going to show you those later because hopefully it's an interesting direction. We'll start with Colin Wall because you've already seen that already. The first thing you'll notice is we have controls. So I can hit the tab key to hide and show these controls. I can use the mouse wheel to zoom in and out and I can drag around so you can get into some fairly good detail there. I can go 0 to put the size back or plus and minus to scale it in and out. If I enter, it restarts the simulation. And if you hit the back slash key, you see some diagnostics. So we've got how many milliseconds to update and paint, how many frames per second, actually the mouse position and the zoom size, and some counters here. We've got one that goes from, it's adding the delta up to 60. So roughly we see which frame we're on using this counter. We see what our delta is. We're getting 60 frames a second so that should be hovering around one. And this one is either broken or goes from 0 to 1. I can't work it out quite yet. There's a bug there I think. But if we have a look at these controls, the top one is for the scene itself. So the scene is really you think of it like maybe the controller or something for the whole simulation. And then each of the actors really has parameters. So every capital uses these parameters. I can do stuff like, I can turn up a number of capitals. We've got a few more capitals there. If I turn on first strike, I think they go to war pretty much straight away. But we're going to have a look at this because this is the most fun thing to do with it. First we turn up the satellites as much as we can. And we put the def con starting at 1. And then we're going to go to war straight away. Then we give them lots of ICBMs and lots of APMs. And we let them launch a whole bunch of ICBMs at the same time. I think you end up with something like this. That's much more fun. We're at 40 frames. So this is kind of hitting the limits of what the thing can do. But there's a whole bunch of different scenarios to start with here. Now if we have a look at this, I'll just take it out of full screen for a second. It actually puts all the parameters in the URL so you can copy and paste that and tweet it or mail it around or whatever. If I paste that in a new tab it'll basically go back to where I was. That's how you share the simulations. So that's whole. You can go and play with this one. If I had to skate, it would go back to the top. So most of this keyboard driven. Deep space is the next one. I presented this at JSConf, Asia 2014. I think the way to explain deep space is to go back to this principles. You start with a planet. We're trying to simulate a planetary economy with four numbers. You have population, agriculture, industry and pollution. And this is in need of a bit of love I think. But basically the population works in industry. They make spaceships. Spaceships take some of the population and fly off into outer space. So these little dots you see are spaceships shooting off and you see the population drop back down and the productivity drops but then they grow back up again. So we have planets that spawn spaceships. Awesome. All you do then is put them into a star system. We can have planets orbiting around a star. The spaceships take off they go and colonize other worlds. Now this number of other planets of the population, you see they fly to another planet, decimate the locals and take over the planet and start making their own spaceships. So the natural thing to do is turn up a number of planets. There you go. Now gravity's on the figure, right? So the spaceships actually have trouble flying around because there's too much gravity missing with their flight paths. You can turn up the species. You can have a whole bunch of species competing for conquest of a star system. Awesome. How many frames are we giving? No, it's holding up. That's alright. It's not even blinking. We can zoom in and see it in nauseating detail. We're proud of the dark side of the planets. So you can do that. That's pretty cool. But then you take a whole bunch of them and put them into a universe. Now we've got star systems bouncing around the finite space. They actually bounce off each other. These guys take over the local star system and then try and colonize distant stars. Green's made a go of this one. So we'll turn this up a bit. Let's turn up the numbers and see how far we can go. And you find it ends up a bit congested, right? So they can't actually bounce around properly. So we can make the thing a bit smaller. Let's just wait this play out for a bit. Has anyone got any questions at this point? No questions. I just want to applause for you. No questions? That's why. I mean this is obviously a hobby. Not paid work, probably. I wanted to make this deep space thing when I was like 16. I was trying to program this. In nature I wanted to scratch. The whole thing's vanilla JS. There's no libraries. And for me that was really good fun doing that. And I realized that I actually learned a heck of a lot doing that. So this will play all day. This will probably take an hour to finish. So we'll skip out on this one. What else have we got? We've got interception. You've seen this and the usual thing to do is just to turn the numbers up. This is like cheap tricks. So we went well on this one. If you're going to write it, there are a few different ways you can approach writing a sin. I think interception is a really good starting point if you want to use actors. It starts with 3 or 4. Copy this and just modify it until it does what you want. This one is blindingly simple. So that'd be a great starting point for writing your own. The other one to look at is life. Does anyone spot the fundamental flaw in how Cold War works? What's the fundamental problem and the way I'm doing the update? Come on, think fast. When you do life, everybody knows the game of life. Who does not know the game of life? Each of these cells is working out what happens next based on the neighbors around them. So you have two arrays of a cell and I work out what happens to a base in its neighbors and I write the result into the second array. The next tick, I flip them around and use the destination array as the source. In Cold War I don't do that. I have one array with the actors in it. So I update the first actor and then I update the second actor. Now he has to look at the world around himself and go what should I do based on the stage of the world. It's looking at the first actor that's already updated. It doesn't matter. It still works fine. The proof is in the pudding. It's good enough. It does the job. Life will not work if you do it that way. That's one key point. The second key point is life is a different way of writing a simulation. We don't have any actors. We just have a simple data structure and we update that every time. So the next step on from life is rabbits. There's a different thing but it uses the same principle. You have rabbits and foxes. The little blue ones are rabbits. They run around eating stuff and reproducing like rabbits do. Foxes eat rabbits. So if a rabbit eats a rabbit, they reproduce. If a fox eats a rabbit, it eats it. If a fox goes too long without eating a rabbit, it dies of starvation. Which lets the rabbits grow back and then the foxes can come back. This is actually a pretty accurate model of real predator-prey relationships. You can do another version with grass as well. Foxes, rabbits and grass. This is really the foundation of the planetary economy. Life, rabbits, planets, spacewalk. It's a natural progression. There are a couple that use this next track. So this is the demo mode for Colville. You saw this in the talk. This is kind of a reboot of that. If you watch this for a second, it skips through to another kind of scene. The way we do this is I've got an array of an array that describes what should be drawn on the screen. Each element in the array is an object and it has a bunch of stuff telling the simulation what to draw. You have a counter. You count up to say 100 and when that hits 100 you bump the index of the array to the next value. When you get to the end of the array, you go back to the first element. This is almost a third way to write the simulation, but it's a way of doing scene-based animations. Let me have a look at this. See how this text is wobbling? How do you reckon you do that? It's a really, really cheap trick. He's got Math.Random is your best friend. All I'm doing is translate Math.Random or Math.Random minus 0.5. It's so cheap and easy, but it looks awesome. So much of the animation here is just really simple Math.Random tricks. So this is a modular animation. You have an array with an index. You advance the index according to some time counter and you draw something new. This one's basically built the same way. It has an array describing what the bitmap looks like and I just advance the counter a lot and draw some stuff. It's really easy to do. I added it in the memory source. It's memory through to the display. Every time I present this somebody bitches at me and I'm like blah blah blah. So I finally got around to it. Seriously, there's two things every time I present this I get two tweets or two comments. One is why didn't you do Dear Professor Folk and have you heard of this? The other one is you've got to stop flashing the screen because somebody is going to have an epileptic fit. It hasn't happened yet. I'm waiting. When somebody has an epileptic fit you can stop flashing the screen. Volunteer. This should probably be a library. If someone wants to volunteer this would be a great thing to extract. It's a cheap and nasty little library. Hopefully we see it on lots of websites soon. But in the meantime you can paste your own content in there. What do we got? You've seen that. This is probably one you should play with yourself. There's different forces that apply to the birds. Do they stick together? Do they fly apart? How do they keep away from the predators? So this is kind of fun to play with. But we won't dwell on it. How long has the work gone into putting all this? Months. There's a lot of work here. A lot of what was extracted from the talks. With the talks the approach I took was make it work. Doesn't matter. The code I don't care. I'm just going to make it work and if it looks good it is. Which is a valid principle. But what I've done is tried to work out how to structure it as a way a pattern wouldn't be anything. I won't call it a framework. I don't want to call it a framework. It's a pattern. It provides some structure for you to build stuff with it. This is just playing with the explosions. We've got a bunch of different explosions. This would be a really good one to start with. If you want to start figuring out how to do it. Random rainbow mode. Nice and simple. This one's kind of boring. This is actually a talk I want to do because frequency is an interesting thing. There's a lot of colors and sound waves. But if you look at things like what we have here. If you look at capacitors and filters. There's so many things coming out of basic frequency concepts. So one day this will evolve into something more detailed. At the moment it's just an entry. Do you want to elaborate on why you chose to write it in the No More JS? As opposed to using a framework? Because I wanted to know. I wanted to... This page is the only page I managed to develop. How do I do that stuff? How do I take away the crutches? None of it's hard. It's so easy to use the crutch. Even things like vent handlers. And the mouse handlers and stuff. It's improved my JavaScript knowing it. And you go off to solve this library that wraps two lines of code. And I'm finding it more and more. Especially with Node. There's some things you want to use as a library. But so many of the libraries you find around. You don't do very much. It's like, you know, facing slow. Why don't you have a look at the code and rip it out and do your own versions? It is only a few lines of code to do that stuff. Right, so we're going to branch out for a second now. We're nearly done with this bit. But I wanted to show you some of the things I want to do in the future. So we'll start with this. This is incredible. This is NASA simulating carbon darks. Carbon monoxide in the atmosphere over a number of years. And you can see the Amazon breathing. This is a daily cycle. This is unreal. Super computer processing here. You can see the jet stream is moving across one going this way and one going that way. And you can see the forest fires, I think, in the near here at some point. This is incredible. But look at how much crap they're putting into the atmosphere. I got afraid to... He was really ripping me. I rehearsed the talk with the motor sky. And he's saying, man, Simon, why are you always doing warfare? What can you do that's not warfare? But it did give me thinking. I think this is an ideal simulation that doesn't use warfare. But I got an angle on it. Just as depressing though. But this atmospheric stuff is kind of cool. I mean, basically it's fluid physics. So we dig around and there's a wind map. I'll see how the network is here. This is beautiful, right? This is real-time wind data in the States. Yeah, I just think it's beautiful. But then, how do you do it? We found this library here. I want the demo. So we just have a simple one. We just find a natural convention. You lock the start button, right? This is actually getting to the realms of the door. There's some vectors. There's some kind of density going on. This is reasonably cool. And they got the source code for it also. What am I going to try and do? Well, let's have a look at... a bit of coding here, right? I'm going to try and simulate a world. So we have a grid that's the world. Each of these squares, some of them are ocean, some of them are land, some of them are mountains. We've got a day-night cycle rolling across the earth. There's little thoughts that need to represent the atmosphere. It's so primitive, so don't laugh at it again. We've got the jet stream moving the atmosphere left and right. But the goal of this simulation is your job is to manage the economy. You can use the power mix you're going to use. You can use renewables, you can use coal, you can use oil, you can use nuclear. Now these pink circles are nuclear power plants. Eventually they go to the pop. And nuclear waste will percolate through the atmosphere, or the oceans or whatever. But your goal is to successfully create the maximum output from your economy while managing the power balance. This is meltdown, this one. And then I tried to dig a bit further into that. Well, I've got to start somewhere. How do we simulate a basic convection current? I'm an amateur at this. Basically you just have a cell and the heat migrates up and the bit goes to the side and the tiny bit goes down. Some of it grows across the top. What you find with this is that uses a lot of CPU power. I'll start doing this. Our frames per second go way down. It's not even going to do it. So I'll just snap it off a bit. I think I'll break it. The diagnostics actually put numbers earlier. But if I pump a whole lot of heat in the air, you'll see it rise up. When it gets too cold we get random heat injection. So yeah, this is just playing around, right? So I won't let this all turn into a real simulation. But this is kind of where I'm going with it. There's one more. So that's the Atmosphere X. I'm kind of a real retro game fan. So if we ever look at this game called Major Haddock, there are two retro games that really mean something to me. This is a real vector game, right? I think this is off-name, so it's not quite. It's a bit pixelated. But this is a real vector game I used to play when I was a teenager. And it actually has a really beautiful story. See this eons ago, the evil Vaxian Empire over in the galaxy. This game is a work of art. The guy who did this poured their souls into it. But we have to look at the game play a little bit. So this has a spinner on it, right? It's like a mouse that works in one dimension. You can go left and right, but the speed is proportional. You can walk or you can run. The idea is to run through the maze, tap the reactor, and then get out of the maze before the reactor blows up. This guy's an opus player. But it's got lots of crazy stuff in it. See that's got a palm down here? He's already blown it, but on palm there's a number underneath the palm. And if you spin it to the right numbers, while you're playing palm, you can walk ahead in the game. This game is just full of Easter eggs and hacks and tricks. It's really cool. So the other one is, if I can find the burrows, bear with me one second here. I don't think this is right. Hang on. I lost my plot. There we go. Rats of the maze. When I was like 13 or 14, I'd go to my dad's work and they had this computer there. Now this is the big daddy one. This is in the computer room, right? The machine room. My dad's one just had one. There's little vertical slabs of it. It was a 386 based networking computer. The burrows something. Burrows 2000. It was amazing. But it had a game on it called Rats. This is the only screenshot I can find of Rats of the maze. So it's kind of like a dessert. You run around this maze and there's rat generators that spawn with the rats. You have to run through the maze and shoot the rats. Shoot the rat generators and go to the next level I guess. But I played this game for hours. So what I want to do is mash up rats of the maze and made you have a maze. You have rat generators that spawn rats. You have to get to the reactor, turn it off and get out of the maze. This is, again, this is a non-flight hack together. This has heaps of really interesting stuff in it. You've got maze generation algorithms. That's an interesting problem in itself. You've got the seeking behaviour of the rats. How the rats negotiate a maze and maybe maintain some separation to home and on the character. How does the character run through the maze, get to the reactor, turn it off while avoiding the rats and then get out of the maze again. So you've got mazes, you've got AI, you've got animation. When you look at this you'll be probably animating to kind of at this size running through the maze. So this is kind of where I'd like to get to with the simulations after I stop the seeking for spending months and months and months coding it up for this. So any questions at this point? Everybody's still with me? We'll have a look at a little bit of cards. I won't give you too long. It's all online. Copy it, fork it, do whatever you want with it. Contribute back. I use JS Hint, but there's like 300 or 400 issues with it at the moment. So if you want to jump on it, let it be really awesome. I start and do it again. You've got to use semicolons. So most of this you can ignore. It's got a hacky based web server. It's running node. It spins up the server. It serves some assets. Most of you can ignore. Server, what you care about is server, public, jays. Now the first thing that loads up is this app runner. That takes care of the URL parameter passing you saw. It starts off the scene you want to run, and it takes care of all that housekeeping kind of stuff. Basically it causes an update of pain once everything's running. Your simulation itself is a scene. So all these scenes follow pretty much the same kind of pattern. They have this boilerplate at the top. They clone from an object. They initialize to present these defaults. So these defaults are what you turn into the configuration when you see down the side. Oh, sorry. Sorry. So I'll start again. You've got this boilerplate function here. You clone an object. You initialize this one for really basic. You might have... So if this is cold or initializes where you set up all your assets and everything, my booms is just setting up the container. These defaults are what you turn into the menu down the side so you can configure the simulation. Really what you care about is update and pain. Just want to look at adders. They're none of this one, but we have two constructs in here. There's options, which are the defaults you saw. They are the settings that are effectively static. You've got adders, which are the dynamic parameters. So if you've got a timer or some health or hit points or whatever, that's going to be an adders. They can change over time. And often what you do is use your parameters here to generate kind of ranges for random values in your parameters. But really, at the end of the day, we can update and paint. Right. So I go through each explosion, do some stuff to it, whatever I do, and then I paint it. Each of them has a chance to paint themselves. And then the painting method, you get passed into some pre-scaled campus as Canva. We have three of them here. There's actually a couple of tricks here. So GX is the main one. That's just a fully transparent canvas you can draw to. Ethics is what I call a fadeback plan. So you paint something to that, but every frame I paint over a 3% blank. And that has the effect of over about a second or so, a phase of canvas back. So if you draw something to that, you can actually see it here, probably fine. So if you see these horizontal lines that are blinking across, they are on that fade layer. I'm only drawing that line for one frame. Now normally you wouldn't actually see that, but because there's some fade layer that stays there a bit longer and kind of linkers around. These stars, I'm not sure if they're doing that. Most of the explosions that draw on the fade layer then. And then SX is the scanner. That's the one up at the top. So when you set up your scene, you can say I want the one full scene or I want the split screen with a scanner and a zoomable lad in the bottom. So we have a little bit of that. And then look at an actor. Actors follow almost the same kind of setup. So we have a look at a we see. So a bomb is the thing from Interception that flying down from the top of the screen. Really it's the same. You set it up. You capture some references. You initialize. We manage our position here. We have some defaults we expose to the framework, to the platform. Blah, blah, blah, blah, blah. There we generate some relactors. How fast am I? Random number. You can ignore all of this to can do it if you're really interested. Update and paint. Paint is down here somewhere with paint. The elevation is the scanner up at the top. That's the elevation view. It comes from the top down view. Rats. And an elevation view. Any questions? Yeah. I've been trying sitting while I'm at a co-op. It's like real life data. I mean like the place between up and down. It's a good idea. I haven't, but this is a big, good one to try. Can you do like asymmetric warfare next? I want to see like ISIS versus France or something. I've got the name already. It's called Predator. It's about drones. Hardier running basically. Actually most of the bits to do this stuff is already there. The other one I wanted to do was trench warfare. Because they really lent us a horrible concept, but it lends itself to simulation. You've got probably half a dozen different actors. It's all pretty nasty. But yeah, absolutely. Are there any plans to add any AI to this? Any artificial intelligence? Rats is probably the first step to that thing. Because it involves pathfinding through the maze. Yeah. And I mean, contributions welcome. For me this is a hobby and a toy. I really hope some people can get into doing some of these and send me some pull requests and I'll add your scene to the front page. I want some quality simulations here. What I'm writing is just toys. I do this in the evenings and weekends and to do this probably requires a lot of work. That's why it's the vector graphics. Actually I love the vector graphics. I don't want to have bit met. Mario characters running around doing it. Vector graphics are more fun. But there's a whole world of exploration that can be done here. So what's your DJO? I write a cloud system for the Internet of Things. So we do...it's complicated. I don't see it. Yeah. It's very interesting. Any more questions? Yeah, Josh? The question is do you think that you have some of the simulations? For the convection that would be the right thing to do wouldn't it? One thing I did try doing is web workers for some of it. I wanted to see if I could spread some of the work around. What I found is they don't share memory. You're wasting all of your time passing messages around which makes it kind of useless for this. Because you need to share memory pool and then work on the significance of it. But yeah, for convection that would be completely the right way to do it I think. Right, if there's no more questions we'll probably call it a wrap. Alright. Well, thank you very much. Thank you. Yeah, I guess that's the end of Talk.js. Thanks for coming and eating all the pizza. I couldn't have done that on my own.