you are over-thinking the PHP part of this. All it is doing is simulating the equivalent of all the files that could have done the same job.
If I'm over-thinking the PHP part then what about the following:
How can you have a pure HTML snake that reads the state from the search query?
How can you have the next direction encoded a query parameter using pure HTML?
How can you introduce some non-determinism (in this case, the randomised location of the apple) using pure HTML?
There is a difference between writing the game logic in PHP and actually extracting the game logic as a Finite State Machine in pure HTML.
With the latter, there are challenges that you could skip simply because you wrote the logic in PHP instead of writing a script that extracts the logic as a flat FSM in pure HTML (using whatever language).
Here are the ones I can think of:
Mapping the game state into a unique identifier that can be used as the name of each HTML file, each link can reference another game state
Using a LCG to create multiple deterministic versions of the game, each one using a different seed to randomise the position of the apple
Writing the logic that visits each possible game state and extracts it as a HTML page that links to the pages of its children states
If you can do it then you'd have in written a snake in pure HTML (in theory).
>>neither of "your" articles that you did not create and can not be attributed to you add anything to the net knowledge of industry.<< @jarrodhroberson
There is nothing wrong with naming files with the query part (you need a file system that supports all url characters as part of a file name). There is also a nothing wrong with pre-determined placements of the apple.
For the file name part, your suggestion would require a custom web server so that's just working around the issue. We want to write a snake in pure HTML that works anywhere. So ideally we'd have a state to ID mapping that can be also used as a filename to fix both the filename and the maximum URL length issue.
For the determination issue, there's nothing wrong with with pre-determined placements from a gameplay point of view. However, this is not what the program in the article is doing, even though this is not possible in pure HTML.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Correct on how the URL was going to be handled (if physics hadn't got in the way), I was going to go very simple and just do s010101020103a0206dirl with "s010101020103" being snake positions as "x1,y1,x2,y2,x3,y3" and "a0206" being the apple position x,y and "dirl" being left for a naming convention (although anything will do that is a valid URL obviously). All the other info could have been stored in the HTML such as score.
As for the randomisation of the apples, it is obviously impossible, but one idea I had was to make a "start screen" as a 300 x 80 table that used the following technique to "pseudo-random" the start position.
<tablerules=none><tr><!-- by changing the bgcolor to white or black we can effectively spell "click to start" in large writing--><tdbgcolor=black><ahref="1.html"> </a></td><tdbgcolor=black><ahref="2.html"> </a></td><tdbgcolor=white><ahref="3.html"> </a></td><tdbgcolor=black><ahref="4.html"> </a></td></tr></table>
By changing the bgcolor of each <td> to spell words ("click here to start") and having a different snake starting position and apple start position for each anchor it would have offered 2400 possible (and about 1500 realistic "people might actually click here") random starting positions and apple positions. To a human it would appear random (even if you could technically click the exact same spot and perform the exact same moves to get a repeated game).
You could even have a 0 refresh time meta refresh on the start screen with other starting snake and apple positions for each page's table, to multiply the possible starts by 100 or so and increase the pseudo-randomness further.
in the scheme of this project, 2400 times to 240000 times more permutations is nothing 🤷🏼♂️🤣💗
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If I'm over-thinking the PHP part then what about the following:
There is a difference between writing the game logic in PHP and actually extracting the game logic as a Finite State Machine in pure HTML.
With the latter, there are challenges that you could skip simply because you wrote the logic in PHP instead of writing a script that extracts the logic as a flat FSM in pure HTML (using whatever language).
Here are the ones I can think of:
If you can do it then you'd have in written a snake in pure HTML (in theory).
There is nothing wrong with naming files with the query part (you need a file system that supports all url characters as part of a file name). There is also a nothing wrong with pre-determined placements of the apple.
For the file name part, your suggestion would require a custom web server so that's just working around the issue. We want to write a snake in pure HTML that works anywhere. So ideally we'd have a state to ID mapping that can be also used as a filename to fix both the filename and the maximum URL length issue.
For the determination issue, there's nothing wrong with with pre-determined placements from a gameplay point of view. However, this is not what the program in the article is doing, even though this is not possible in pure HTML.
Correct on how the URL was going to be handled (if physics hadn't got in the way), I was going to go very simple and just do s010101020103a0206dirl with "s010101020103" being snake positions as "x1,y1,x2,y2,x3,y3" and "a0206" being the apple position x,y and "dirl" being left for a naming convention (although anything will do that is a valid URL obviously). All the other info could have been stored in the HTML such as score.
As for the randomisation of the apples, it is obviously impossible, but one idea I had was to make a "start screen" as a 300 x 80 table that used the following technique to "pseudo-random" the start position.
By changing the
bgcolorof each<td>to spell words ("click here to start") and having a different snake starting position and apple start position for each anchor it would have offered 2400 possible (and about 1500 realistic "people might actually click here") random starting positions and apple positions. To a human it would appear random (even if you could technically click the exact same spot and perform the exact same moves to get a repeated game).You could even have a 0 refresh time meta refresh on the start screen with other starting snake and apple positions for each page's table, to multiply the possible starts by 100 or so and increase the pseudo-randomness further.
in the scheme of this project, 2400 times to 240000 times more permutations is nothing 🤷🏼♂️🤣💗