I love it when Chrome releases a new feature, I especially like it when it is experimental. In this post I'm going to show you how I created Tic Tac Toe (Noughts and crosses) with HTML, using one of t
there are not 9 × 9 × 9 × 9 × … possible ways to play. After the first move, 8 squares remain, and so on, so there’s at most 9 × 8 × 7 × … = 9! = 362880 ways that the game can be played, ignoring the fact that most of those can be eliminated as reflections and rotations, or as win positions before you fill the whole board.
we don’t care how we got there. Each square can either be blank, a cross, or a nought, so 3^9 combos = 19683, and most of those are illegal, as only the boards where there’s (one or zero) more crosses than noughts are good. And you don’t need to store ‘the computer’s move’, just jump directly to letting the player go again. Let’s guess we need at most a quarter of that.
we could have created a single web page with 5k anchor elements on it back in the HTML 1.0 days, ignoring the fact that it would have taken a while to download on our 28.8K modems. That wouldn’t have been 170 Mb of unnecessary tagging, even with the ‘lay it out with tables’ style we had at the time.
Google do seem to have a predilection for reinventing the past, poorly. I hear that their bonuses are based on inventing ‘new’ things, though, so it’s in their interest to pass it off?
Indeed. One could have done the whole thing with a simple, static HTML page.
On top an empty board with 9 clickable fields. Each of them links to a new, pre-rendered board on the same page, with the move of the player and the perfect reply of the computer already in place, and 7 clickable fields. Which link to other, pre-rendered boards with 5 clickable fields remaining, then with three. The last one only has one field open, so this could be pre-filled as a player move.
All in all this would result in 9x7x5x3=945 pre-rendered boards max on that page. And, of course, two links to “You won” and “You Lost”. I’m no HTML junkie, so I have no idea how many bytes one would need to produce such a board, but I’m sure this all could easily done way below 170MB.
Some of those boards are impossible, and there are multiple ways to get to most of them, so you only need maybe half of that. There are 5,478 possible valid boards in total if you allow the computer to play any legal move.
As I described, I’d need way fewer, as the optimal computer counter-move would already be included in the next board.
So if you placed your X in the top left field in the starter image, the link would directly go to a field with the X in the top left, the O in the center position, and links in all the remaining seven positions. And of course the pre-calculation will eliminate some of the boards already, e.g. if the player or computer already won after the third move, where placing a fourth will not make sense.
The guy in the blog says mb (millibits) and you say Mb (megabits). I was confused so I checked, and the page is 170MB (megabytes). I agree though, that’s inefficient even for an intentionally inefficient idea.
Well now. A few things, here:
there are not 9 × 9 × 9 × 9 × … possible ways to play. After the first move, 8 squares remain, and so on, so there’s at most 9 × 8 × 7 × … = 9! = 362880 ways that the game can be played, ignoring the fact that most of those can be eliminated as reflections and rotations, or as win positions before you fill the whole board.
we don’t care how we got there. Each square can either be blank, a cross, or a nought, so 3^9 combos = 19683, and most of those are illegal, as only the boards where there’s (one or zero) more crosses than noughts are good. And you don’t need to store ‘the computer’s move’, just jump directly to letting the player go again. Let’s guess we need at most a quarter of that.
we could have created a single web page with 5k anchor elements on it back in the HTML 1.0 days, ignoring the fact that it would have taken a while to download on our 28.8K modems. That wouldn’t have been 170 Mb of unnecessary tagging, even with the ‘lay it out with tables’ style we had at the time.
Google do seem to have a predilection for reinventing the past, poorly. I hear that their bonuses are based on inventing ‘new’ things, though, so it’s in their interest to pass it off?
Indeed. One could have done the whole thing with a simple, static HTML page.
On top an empty board with 9 clickable fields. Each of them links to a new, pre-rendered board on the same page, with the move of the player and the perfect reply of the computer already in place, and 7 clickable fields. Which link to other, pre-rendered boards with 5 clickable fields remaining, then with three. The last one only has one field open, so this could be pre-filled as a player move.
All in all this would result in 9x7x5x3=945 pre-rendered boards max on that page. And, of course, two links to “You won” and “You Lost”. I’m no HTML junkie, so I have no idea how many bytes one would need to produce such a board, but I’m sure this all could easily done way below 170MB.
Some of those boards are impossible, and there are multiple ways to get to most of them, so you only need maybe half of that. There are 5,478 possible valid boards in total if you allow the computer to play any legal move.
As I described, I’d need way fewer, as the optimal computer counter-move would already be included in the next board.
So if you placed your X in the top left field in the starter image, the link would directly go to a field with the X in the top left, the O in the center position, and links in all the remaining seven positions. And of course the pre-calculation will eliminate some of the boards already, e.g. if the player or computer already won after the third move, where placing a fourth will not make sense.
And that, kids, is why maths is absolutely necessary if you want to amount to anything more than a shitty webdev.
Which is also why I’m a shitty webdev
The guy in the blog says mb (millibits) and you say Mb (megabits). I was confused so I checked, and the page is 170MB (megabytes). I agree though, that’s inefficient even for an intentionally inefficient idea.