How Hopscotch works right now
This post is in response to some folks on the forum who wanted more details about how Hopscotch works. The following is somewhat technical but should be understandable by a determined 14-year-old who is interested in coding.
Note: we reserve the right to update this in later versions of the player for various reasons. As of today, November 25, 2019, it is accurate to the best of my knowleddge
We also use several libraries and frameworks to help us code more productively:
WebGL is a graphics API that lets us write code to run on your computer or iPad’s graphics card. Almost all games are written using WebGL or its cousin, OpenGL, because using the graphics card is the best way to get fast performance for something that has a lot of visual components (like a game!).
PixiJS is a WebGL renderer. Pixi takes care of the details of using WebGL properly and lets us focus on writing code. When a new version of WebGL comes out, Pixi will figure out the optimal way for Hopscotch to interact with it.
The project file
Your projects are saved as JSON files. Our code reads the JSON file to figure out what you’ve coded, so we know the characters to put on screen and what they should do. The easiest way to create one of these files is to use the visual code editor in Hopscotch.
However, there are other ways to edit your Hopscotch project! You could write an editor for the JSON files yourself as Awesome_E did here.
You could also write a JSON file out line-by-line into a text editor, either by copying the file of an existing project or writing it from scratch. The disadvantage of writing Hopscotch code by hand is that the JSON was not originally designed to be human-readable and editable. It can be quite confusing and tedious to write out all that you want to do. The advantage is that you can have more precise control over what exactly is in your file. You could even use features that aren’t built into the Hopscotch editor yet.
Editing a JSON file yourself is not for the faint of heart, but if you are looking to make your project perfect or want to learn something new, it can be a worthwhile endeavor.
Something on my to-do list is to write a detailed report on where everything in Hopscotch fits into the JSON file. That’s outside the scope of this post right now.
The run loop
requestAnimationFrame that calls each time the picture on your screen refreshes. For most computers and devices, this will be 60 times per second or about once every 16.67 milliseconds.
In Hopscotch, most action blocks will take one
frame to execute–i.e., About 16.67 milliseconds. There are exceptions, though, and we’ve singled out some blocks to execute immediately. When you run those blocks, the block after them will execute in the same frame.
The blocks that run immediately right now are:
Set Trail Color
Set Trail Width
Check Once If
Check If Else.
The Movement blocks
There are exceptions to the one block/one frame rule. The following red blocks are movement blocks:
Movement blocks will execute over several frames. How many depends on a variable called
speed which you can set with the
set speed block. The default speed is 400, which translates to your character moving forward 10 points or turning 10 degrees (out of 360) for each screen refresh.
If you increase the speed to some huge number, you could execute the entirety of your move forward or turn in one frame. Setting the speed to 99999 can make your project faster, up to a point. But if your blocks are broken up into small chunks, it won’t make a big difference. If you had the code
move forward 1, setting the speed to a high number wouldn’t matter because the best it could do would be to move forward one point in one frame.
Move Forward 1000 could teleport you 1000 points in a single frame if you set the speed high enough, but if you wanted to make a more exciting path, where
Move Forward is interspersed with
Turn we will need to use a frame for each of those actions, no matter the speed.
The Wait block
Wait Seconds block works by setting a time in the future before which no code can execute. If you were to wait 3 seconds, you’d block the run loop for that script until 3 seconds in the future. Because we can only check the time once per frame, the accuracy of wait is based on the time to execute a frame. We know each frame takes a minimum of 17 milliseconds, so that is the highest precision you could expect from the wait block. If you were to wait one millisecond, you would have to wait at least 17 milliseconds to get to the next frame and let your next block of code execute.
In Hopscotch, we added the
wait seconds block and removed the
wait milliseconds block. Using seconds makes things more clear for new users since people usually think and talk in seconds. It also gives a more realistic portrait of how precise wait will be.
What is lag?
Your code taking longer than 17 milliseconds to run is what usually causes lag today. If you have a project with many characters, generally, through cloning, they will all execute their actions on the same frame. If 1,000 characters are trying to do something in one frame, that might take more than 17 milliseconds and cause your project to lag behind the screen refresh.
I hope this overview was helpful to some of you. Any errors are my own! Please post any questions in the comments, and I will try to answer them. We also always welcome suggestions about how to make Hopscotch better.