1 00:00:05,630 --> 00:00:12,530 Conway's game of life, also just known as Life, is a cellular automation game created in 1970 by John 2 00:00:12,530 --> 00:00:14,600 Conway, a British mathematician. 3 00:00:14,960 --> 00:00:20,720 This game has a few rules that we need to be aware of prior to beginning creating the game. 4 00:00:21,830 --> 00:00:29,450 The first rule is any live cell with fewer than two live neighbors dies as if by under population. 5 00:00:30,760 --> 00:00:35,410 Any live cell with two or three live neighbors lives on to the next generation. 6 00:00:36,250 --> 00:00:42,430 Any live cell with more than three live neighbors dies as if by overpopulation. 7 00:00:42,730 --> 00:00:50,230 And then lastly, any dead cell with exactly three live neighbors becomes a live cell as if by reproduction. 8 00:00:50,350 --> 00:00:58,300 So we can condense these into the following three rules Any live cell with two or three live neighbors 9 00:00:58,300 --> 00:00:59,350 survives. 10 00:00:59,350 --> 00:01:03,670 Any dead cell with three live neighbors becomes a live cell. 11 00:01:03,910 --> 00:01:08,250 And then all other live cells die in the next generation. 12 00:01:08,260 --> 00:01:13,150 Similarly, all other dead cells stay dead. 13 00:01:14,190 --> 00:01:19,140 So those are the basic rules for the game of life. 14 00:01:19,350 --> 00:01:22,380 And so now let's talk about how. 15 00:01:23,730 --> 00:01:31,200 Webassembly and rust and you know, everything just kind of interacts and some of some of the things 16 00:01:31,200 --> 00:01:36,060 that we need to take into consideration when using rust to create webassembly. 17 00:01:38,160 --> 00:01:45,600 So for our game, we are going to create a fixed size, periodic universe where cells on the edges have 18 00:01:45,600 --> 00:01:51,300 neighbors that wrap around to the other side of the universe because neighbors wrap around the edges 19 00:01:51,300 --> 00:01:52,110 of the universe. 20 00:01:52,140 --> 00:01:54,630 Gliders can keep running forever. 21 00:01:56,110 --> 00:02:02,290 And one of the first things what I want to clear up is what Chasm Bind Gin is. 22 00:02:02,290 --> 00:02:05,950 So you can see it here and you can also see it here. 23 00:02:05,950 --> 00:02:13,780 And our template, it is a common understanding of how to work with compound structures across this 24 00:02:13,780 --> 00:02:14,530 boundary. 25 00:02:14,800 --> 00:02:22,510 So it involves boxing rust structures and wrapping the pointer and a JavaScript class for usability 26 00:02:22,510 --> 00:02:27,190 or indexing into a table of JavaScript objects from rust. 27 00:02:27,580 --> 00:02:35,230 So ASM Bind Gin is a very convenient is very convenient, but it does not remove the need to consider 28 00:02:35,230 --> 00:02:40,630 our data representation and what values and structures are passed across this boundary. 29 00:02:41,170 --> 00:02:47,050 Instead, think of it as a tool for implementing the interface design that we choose. 30 00:02:47,860 --> 00:02:51,810 So there are two things that we should always be thinking about to optimize. 31 00:02:51,820 --> 00:02:59,950 So we want to minimize copying into and out of the webassembly linear memory because unnecessary copies 32 00:02:59,950 --> 00:03:02,110 impose unnecessary overhead. 33 00:03:02,380 --> 00:03:10,420 And then secondly, we want to minimize serializing and d serializing similar to copies. 34 00:03:10,420 --> 00:03:17,410 Serializing and serializing also imposes overhead and often imposes copying as well. 35 00:03:17,650 --> 00:03:24,280 If we can pass opaque handles to a data structure instead of serializing it on one side, copying it 36 00:03:24,280 --> 00:03:31,120 into some known location in the webassembly linear memory and serializing it on the other side, we 37 00:03:31,120 --> 00:03:33,280 can often reduce a lot of overhead. 38 00:03:34,310 --> 00:03:41,750 So why isn't buying gin helps us to find and work with opaque handles to JavaScript objects or boxed 39 00:03:41,750 --> 00:03:43,340 rust structures. 40 00:03:43,490 --> 00:03:53,120 So in essence, by using ASM Bind Gin, in this instance we are exposing the greet function to our. 41 00:03:54,650 --> 00:03:55,700 JavaScript. 42 00:03:56,990 --> 00:04:04,940 And then, as a general rule of thumb, a good at JavaScript web assembly interface design is often 43 00:04:04,940 --> 00:04:12,500 one where large, long lived data structures are implemented as rust types that live in the webassembly 44 00:04:12,500 --> 00:04:21,560 linear memory and are exposed to JavaScript as opaque handles, a.k.a. using the ASM bind gen. 45 00:04:23,120 --> 00:04:29,660 JavaScript calls exported webassembly functions that take these opaque handles, transform their data, 46 00:04:29,660 --> 00:04:36,260 perform the heavy computations, query the data, and ultimately return a small copy able result. 47 00:04:36,590 --> 00:04:43,310 By only returning the small result of the computation, we avoid copying and or serializing everything 48 00:04:43,310 --> 00:04:50,570 back and forth between the JavaScript garbage collected heap and the webassembly linear memory. 49 00:04:51,410 --> 00:04:54,440 So that is just something to take into consideration. 50 00:04:54,440 --> 00:04:58,490 It's a very important aspect that I really want you to understand. 51 00:04:59,030 --> 00:05:03,170 So if you're still a little iffy on it, please rewatch this lecture again. 52 00:05:04,190 --> 00:05:08,060 And then if you have any questions, please ask them in the Q&A section. 53 00:05:08,060 --> 00:05:17,450 Because knowing when to use this ASM engine is really going to help you organize your code. 54 00:05:17,450 --> 00:05:18,380 Help you think? 55 00:05:19,160 --> 00:05:22,280 You know, far ahead in your project. 56 00:05:22,610 --> 00:05:31,940 And it will help speed up your overall the overall performance of your project. 57 00:05:31,940 --> 00:05:38,000 So now that we have that in the back of our mind, while we're creating our project, let's begin creating 58 00:05:38,000 --> 00:05:38,900 our game.