Hopscript: Hopscotch Text Language (Concept)

Continuing the discussion from This Siri Shortcut Can Modify your Projects | 𝓐𝔀𝓮𝓼𝓸𝓶𝓮_𝓔:

Hopscript is a typed programming language, kind of like Python or JavaScript, which lets you compile typed code into a Hopscotch project!

This is a concept that I’ve been thinking about for a little while, that has recently been brought up by @Awesome_E on the forum. I just wanted to go over some design focuses and present why this would be an amazing idea for the modding community!

Amazing automation frontend :gear:

Have you ever wondered how Awesome_E’s Siri Shortcuts work? Here’s a simple answer: code automation! If we had the ability to automatically copy and paste code with different parameters, you get access to powerful utilities, like the ability to generate music from files.

This means that you can copy and paste huuuge sections of code if you wanted to, and you could give parameters to each section to customize the output! For example, if you wanted to draw a trail in a certain way, but every color has to be different.

This already exists for JSON developers–the only people that can automate code like this are low-level JSON developers who know how to use blocks. A programming language would let everyone learn how to make hacks (providing a higher level abstraction to JSON) and would allow novice coders to try their hand at coding one.

Exclusive features – like functions and object-oriented code libraries :books:

Have you ever wanted to use code for platforming, or 3D rendering code? Since Hopscript would be fully extendable by the community, we could add new features like functions and libraries. They would be fully modular, meaning that you could import them as objects and remove them any time you’d like to!

Code libraries made with Hopscript could be stored on GitHub, so anyone who finds a bug in a library can fix it, and then make a request to push it to the original library project!

Is there a feature of a built-in from another language which you really feel should’ve been added to the app? No fear! - Hopscript is an openly-designed language, and libraries would allow for easy integration of these features! You’d also be able to suggest new features for the language.

These shouldn’t be confused with the recent tease of code libraries integrated into the Hopscotch app – this feature in Hopscotch has not been officially confirmed whatsoever. Code libraries made in Hopscript would be integrated to the language and separated from the app, and/or the app library features will be combined when that update is released.

Awesome introduction to typed coding :man_technologist:

New programmers can feel bored or lost coding in Python, with its text-only interface - and learning it with the Turtle library can be confusing. Processing is fun, but it can be hard to share your art with other people in the end. Learning HTML, CSS or JavaScript can be intimidating for new programmers that want to make something presentable—even more so with frameworks.

Hopscript would be an amazing and educational gateway language to programming, to bridge fundamental concepts between the block coded language and the real world of software development. It would be a great entrypoint for any kid to make something visual with a typed interface for the first time.

Seeing your typed code do something for the first time can be an amazing feeling. Hopscotch is an extremely responsive language – you can make a character move around and jump in just minutes! And for advanced coders, this means everything; testing your project could never be easier or more fun in any other language. Bringing this concept of responsiveness and quick compilation to Hopscript introduces a huge possibility that not many other typed programming languages could get close to. Programmers can make real visually rendered projects in just minutes with a robust typed language.

Hopscotch, brought to a new platform :desktop_computer:

I’ve always wanted to use Hopscotch on a computer!

Bridging Hopscotch out to other platforms has always been a challenge. Hopscotch Team has stated that they don’t have the means to make an Android app. However, lately with the amazing work of @Awesome_E, things have started to change! Hopscotch projects are now fully viewable and integrated with desktop and mobile web browsers.

It’s time to bring Hopscotch coding to all desktop platforms! Hopscript would be a community-driven project, meaning that the coders that are interested in seeing the language evolve would work to make it the best it can be.

Hopscotch on GitHub: Collaborations, maximized :handshake:

The JSON format is a low level format, used for interpreting Hopscotch projects in a visual environment. It’s really not a convenient or easily-readable format. Bringing readable, compileable Hopscotch projects to GitHub would innovate with the potential for collaboration on projects.

Integrating to GitHub means that a typed language would allow for full version control, allowing for easy-to-follow code changes. It would also allow for huge strides to be made with collaboration between Hopscotchers!

Compilation and SDKs :hammer_and_wrench:

If you’re going to write code, you’ve got to have it run, right? No fear at all - the compiler for this programming language would be created by the community,

So who’ll do it?

This language doesn’t exist yet – it’s been discussed only as a concept. But with the help of designers and engineers on the forum, I’m sure we can put something together!


Post Etiquette - Keep it Critical (KiC) :speaking_head:

Please don’t compliment the idea or steal first post(s) without adding anything critical that adds to the discussion on this topic.

Examples of what NOT to say:

“First post! Nice topic”

Instead, feel free to vote on this poll:

How cool of an idea do you think this is? (Anonymous)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

0 voters

Thanks guys!


Here’s an example of what Hopscript could look like, from @JonnyGamer:


@Rawrbear this is a super detailed topic!

Do you have a plan as to how the compilation will work and how a user will actually be able to write the code? What’s the file structure for each system going to be like? How will the library implementation work?


Sorry for the long response! Lots of questions asked in a short post. I want to be as detailed as I can be to avoid confusion in this post, but I’ll make a TL;DR right now because it’s long haha.

So you suggested a possibility for code compilation on the other topic:

There could definitely be an npm command line tool! I think this would be very usable, because some of the Hopscotch community has been delving into web development lately. I also think that because Hopscotch projects run independently on the web, the languages match up in that regard as well. (One may also consider npm support with code editors from the App Store, or from a SaaS website people may use for coding.)

I think a faster language like Rust would still be less convenient to use than JS anyways, in a collaborative context, because I think the majority of programmers on this forum know enough Node to get by–and if not, then it’s really easy to learn. It also allows (-1 members?) testers to look into the compiler code and try to bug it out, haha.

Personally, I think VS Code is a widely-used editor, and there aren’t a lot of amazing environments for writing code on the go (besides Codespaces, I guess) – and the mobile app exists for that reason already, of course – so let’s say we target the scripting language towards desktop users for now. There could definitely be VS Code tooling for the language, and maybe even lint support along the lines, if someone decides to try their hand at that in the future at some point. I guess coding syntax highlighting for the language would be worth looking into as well before then.

I’d imagine that the easiest approach to creating an IDE-like toolchain within VS Code is to provide an extension that lets you compile a project with the NPM compiler, and then open the output in a web browser in your browser, preferably offline. I think you have experience with that sort of thing!

And then, here’s the cool part:

Later on, after the actual language and compiler is written, there could be a Hopscript to block interpreter to be used on the web somehow, if we intend to make the language be visually identical to that of Hopscotch’s. That could be another interesting way to introduce the block coding aspect to other platforms, as well as the language itself! – and there could be a Code.org-like toggle between text coding mode and block mode. But this would be a plan after the language itself is completed.

So there are a couple ideas:

  • Objects that act as classes, held in scenes, which can all be held in files
  • Files that act as objects, and folders that act as scenes?

Well, let’s think about this ergonomically. We want to use files to separate major chunks of code.
I think it could be worth using files as individual objects, because the code inside of objects can be quite massive at times. This answer can also be different depending on the custom functionality we intend to add to the language, like libraries and functions. Definitely something to discuss among more experienced programmers though, haha.

So, I think libraries could be written as Hopcode. The code could be compiled into a project, and maybe there could be some sort of interface assigned (ie. protected in Java) as well as private/public functions? I’m not sure exactly how custom we want it, but maybe we could take a Java-like approach to it - scan the objects within a compiled Hopcode-compatible binary and see what functions have been exposed for use, I guess. And then from there, the name of the library, etc. could be stored within a meta file, which is packed into a separate object within the compiled library binary. Does that make sense?


I would say that this is already a topic, but this is far more detailed than any of the ones similar to this prior, so I’ll leave it up to the leaders to decide.

I think it would be a major improvement for Hopscotch if they implement this. You learn the fundamentals of how to code right now on Hopscotch and to be frank it is hard to move on to written coding. If Hopscript is added to Hopscotch, it would make the transition between block to typed much easier.


Compilation: use NPM as a means to bring the toolchain to new web developers on the forum. Also, because the player is web-based, a Node-based compiler would work out. Most devs on here probably find Node to be somewhat easier to learn, read and hack on, too. And maybe mobile code editors support NPM?

Coding: VS Code is a great choice if we target this towards desktop users. We could add syntax highlighting, and maybe linting, along the lines. We could make an extension for the language that allows coders to compile quickly in-editor, which would open in an offline browser. If we intend to allow conversion of the language to a visual block-based layout and back, then this could be a great way to expose Hopscotch to more platforms.

File structure: since objects can get pretty massive, one file per object would be a good way to go. I didn’t include this part on the original post: for imported libraries, one folder per library, containing a collection of objects. But maybe this could be discussed more? I’m comparing this to Java.

Libraries: Hopcode libraries would be entire repositories, which are compiled into binaries to be interpreted by the Hopcode compiler as objects with exposed functions.


I’ve made this very comprehensive, so that there’s a requirements list and roadmap for this to be actually implemented sometime! Yes, this idea has been floating around in the community for years now, and no long-term action has been taken to make this actually possible to exist.

This topic not just an “idea” topic - it’s a topic for critical discussions for a real product, and is therefore more serious than other topics. And I would be happy to help provision and help make this a thing. It’s much easier to officially coordinate on a topic like this.


in what language do you think this will be made? I’ve been trying to read all of this but yeah


The language itself is its own thing. However, it needs a compiler for the code to be turned into working JSON, and I think Node.js would be a convenient programming language to code that in.

See above, where I further discuss compilation.

To correct myself - NPM is a package manager for Node.js packages, which lets you distibute it to other NPM users. Node.js is the actual language, based on JavaScript. I gave some reasons why it could be written in Node in above posts.


I’ve been wanting to make this for a while, but haven’t ever really been able to figure out how I wanted it to be. I’ll definitely help with this.

It would be cool if we could somehow include presets from E’s web builder in this.

I wonder if we could at some point add a feature which adds comments to the hopscotch project explaining what hopscript code made what Hopscotch code, and why we did it in that way.

^^^This is one of the main things I was struggling to figure out.

It might be better to have objects be basically custom rules, and have scenes be just a list of objects and a name. Lately I’ve also been trying to give each scene an object which sets up important variables for that scene, and broadcasts a message that I use in place of when game starts, or a message that starts something specific (like “show game” or something.) This makes it easier to add scenes and helps keep important constants in one place. This might not be necessary for projects made with this (especially not at first) but it could be helpful.

I think that each object and scene should be their own file. Each “object” in these files would become a custom rule, which would be added to actual objects later. This might make things like subclassing easier.

Each scene could have a list of objects, which would be used to create objects with the correct custom rule in them. It could also have a string for the message sent on the first game start. Maybe have some way to set up important constants for the scene before it broadcasts that message.

We should also encourage using custom rules as much as possible. Maybe make a way to add custom rules to an object from a separate file, sort of like extensions from Swift? This would make for better code organization in both hopscript and hopscotch projects.

Not really important for right now, but how would we force a variable to be a string? Would we add some string to the end/beginning and use the characters between block? I feel like that is the best way to do it, but if anyone can think of a better way that would be nice.

Once thing that I think we should definitely at least think about would be some sort of enum type thing. We could have it set a variable for each case in the variable setup part of the first scene. This could be very helpful and is always something I’ve wanted to be easier to make.

How would the actual code inside of the objects be written? How would you set the rules? How close do we want it to be to the actual compiled Hopscotch project? Could we maybe only allow when I get a message and when game is playing rules? We could find the main uses for other kinds of rules and make a separate type of rule just for that.

How would we write the blocks? How would we parse that to block ids? That was one of the most difficult parts of trying to figure out how to parse this.

How would we make custom blocks? What about custom blocks that any object can use? Would we be able to make custom reusable math functions? Would there be a way to include a block with a specific id in your code?

It also might be helpful to have a way to explicitly order the rules the way you want. So maybe we could give every rule a name.

One important thing that would be very useful is if we assign each object (including clones) a unique id. Something like this

works very well. It lets you reference a specific object for things like broadcasting a message to that specific object, or finding which object the current object is a clone of. We could use this to broadcast messages to a specific object. So if you want to tell a specific object to do something, you could do something like broadcast to (variable containing the object id, though probably make it an object type for hopscript code) (name of the rule you want to run)
This would use the same name from my ordering rules idea above. With the object variable, we could either make it just be a number (in Hopscotch), which would probably be the best, or we could make it somehow be restricted to only a specific object or its subclasses. Clones of an object would have the same type as the original object. I’m not sure that the second one is necessary, though it may be helpful (?) at some point. I’ve never run into any issues using just a number, though.

Really cool idea, I will definitely help with this!


Looking back, it seems like I missed a section when proofreading:

@Awesome_E, if you would, could you replace the paragraph (towards the bottom) with the following?

Compilation, SDKs and help resources :hammer_and_wrench:

If you’re going to write code, you’ve got to have it run, right? No fear at all - the tooling and compiler for this programming language would be created by the community, and they’ll let you quickly run right off of the web. You can even load exported projects into the app with the help of Shortcuts to see how they would run there. There will also be plenty of easy-to-understand documentation to help ease new Hopscript users into the language!



Yeah, that would be interesting. Maybe we could keep certain compilation reasons contained in the documentation, or have the ability to set a compiler flag to auto-generate comments.

Preferably, this could be used more with library compilation and function generation (DRY to WET code conversion, possibly?), since those seem more complicated to implement and understand at first.

For now, we could try implementing the base language and make it as easy to cross over as possible, and then as we add on more features, we can start designing it from there and find the best way to implement everything then, by that time.

Yep, so I was thinking libraries could be compiled as a separate type of Hopscotch project, containing every object and function, along with another “metadata” object that has the library name, author, etc. (whatever other meta we’d want to add). Then those objects can be added into the project using the library, or maybe rules could be copied over between the library objects and functions called from that library in the main project.

Hmm, yeah, maybe .hpscn and .hpobj files, respectively. Scene files can have metadata and object listings, and object files can have rules, etcetera.

Maybe. I’m not sure if these should be auto-generated due to clutter, but I think abilities should definitely act as functions. I had the idea where functions with parameters could be auto-generated as WET code.

Yes, an “init” function! That would be nice, but I think this could be implemented manually, as you’ve said. Maybe if there’s a good way to implement this (maybe a main init function where all functions declared within are split and executed on frame 1?) but I don’t want it to be too complicated to understand for new users.

Ultimately though, this could be really convenient.

Variables are pretty flexible in Hopscotch when it comes to type, so I’m not sure if this is necessary. If we do ever add string casting, I suppose we could add an empty string, yes.

For sure! Yeah, I think this would be cool. We could totally look into this as a custom feature after we get the base language implemented (when we get all of the current features of Hopscotch language implemented into Hopscript).

I think we should follow the Hopscotch language very closely, and compile text directly into blocks, Code.org styled. For example, Hopscript should be easy to fit into Hopscotch as blocks and convert very closely, intuitively speaking. This is to make it easy for existing Hopscotchers that want to use the language (ie. to write Shortcuts or for any type of GitHub-based collab), as well as to increase code readability.

We need to remember that this is a product to be used by the community, so it’s best to gear the syntax towards every user, so it’s easy and understandable to use.

A 7 year old should be able to use and understand the syntax as a gateway language, just as much as a 17 year old. I can’t stress this point enough, really, because of the young demographic that forms the accessible context of the app.

It’s best if the language was easy for a seven year old to use on their trail arts, while allowing more experienced users to leverage the language to its fullest capacity, with the advanced features we provide.

Like I mentioned in the OP, it’s not as fun learning other languages for the first time as a young kid looking to transition, because there’s no visual basis/good gateway crossover between the languages. This is why I think the typed syntax should closely match the block code alternative.

With this in mind, we should aim to provide every event available, and make the core concepts and code syntax extremely similar to Hopscotch blocks’ syntax.

@Awesome_E this is a really important point that I’d like to inform you of as well!

Here is an example of what I mean:


// This is example syntax ("pseudocode") and not a final product whatsoever

/// These abilities and rules can be imported with a "builtIns" library,
/// but I redeclare them here as an example

// Abilities can be empty, but cannot contain "when" statements
ability goToFinger("Go to finger") {
   setPosition(x: lastTouchX, y: lastTouchY)

// rules must include at least one "when" statement
rule dragMe("Drag Me") {
   when (Self.isPressed) {

object Kyle(type: "Bear") {

In-App (Blocks)

There may be a way to simplify this, but this is kind of what I mean. And again, this rule and ability is just a demonstration of how it could be declared for the first time, but in the future it could be available through a package/library of built-in functions, because Drag Me is a built-in.

Hopefully, this example covers some of the questions you have that I thought a little bit about too. I think we can improve upon the syntax, though, and make everything more approachable.

Maybe we can follow Node.js’s approach and allow files to be imported? Or maybe functions could be built by the compiler, and then other references of that function could be kept track of throughout the project by the compiler, because abilities are always global - and then the compiler could error if there’s a misspelled or nonexistent function. I guess this could be an interesting approach.

In terms of IDs (both internally and manually assigned), this is a subject I don’t know too much about, and might be better left for @Awesome_E to answer (if he is willing to do so). Personally, I think manually or in-draft IDs can be assigned through a compiler flag or a config option, but I have no idea how the internal ID system works, to be fair.

Thank you - I’m glad to hear it!


For now, I think a good approach to take when making this is to decide how we want to design the language, philosophy and syntax, implement the core language, then design and engineer the compiler (the hardest part of all, which would probably be its own big project) - and then finally, pray and hope we did everything right. From there, we could decide what custom features to add, or think about this beforehand and add it after the core language is finished. This is more or less just to avoid development confusion.

I like the idea of marketing this towards app users as a this-can-do-anything type of script, towards all ages. Also, it’d be great if we can have this as a higher level for web projects like converters and whatnot, so it’s easier to generate code from given parameters.


This is what I was thinking, though I realize I don’t seem to have specified that. It would certainly be better to not do this by default.

This could actually be useful to have on just a single use of a custom block. Sometimes I find myself having to take a custom block with only variables and copy and paste the blocks out to remove a delay. Like for example, I recently made a level editor and each clone needs to add its data to a string. The code I have for this is a custom block, but since that has 2 frames between getting the updated string and being able to set it to the variable that matters, only the last (or first?) object would actually update it correctly. Removing the blocks from the custom rule removed the delay.

I was thinking of something similar as a modification to E’s presets, since I find myself using the same preset in multiple places and having the variables move. We could use a preset with an extra metadata (json) object. That would be easy enough to make into a Hopscotch project and would also help with this.

That works, yeah.

Only make a custom rule/block if it is explicitly stated, like for an object or for code that will be used in multiple objects, or multiple rules. When writing hopscript you’d have to specify that you want to use it somewhere else.

That may be necessary, though maybe only if asked for. We could do something like

where it takes index and list as input. It also provides list as output and that is used in the next block, but I seem to have forgotton to include taht in the screenshot.

I’m not sure taht would even be necessary. I think it would be better to have it basically be just a rule that runs on the first game start. It shouldn’t be very long. You’d basically use it to set up variables and other things that would only take a few frames. If you want to do something more complex, you’d broadcast a message for another object to do it.

Thinking about it more, it might actually be better to have it split up into a few sections. We could have one section for setting important constants, which would only let you use set blocks. Any block that tries to change these variables would stop the project from compiling. After that, we’d set the enum values (though that would be done by the compiler.) Then we would broadcast the start message. After that, you could make an init function, which would be coded similarly to a rule. Its blocks would just be put after all the ones before. You’d make it be short, broadcasting a message to other objects if you want to do something more complex.

Also, I think we should make you have to define any messages. This could be by setting the names of rules, and for messages to everyone maybe have a separate file for them? I’m not sure, that one would be difficult to design. Then each message name is a variable, which would also be set with the enum values.

I think it would be useful to have a way to create variables that will only ever be strings, even if they would be turned into numbers by Hopscotch.

Getting the syntax right is definitely one of the hardest parts.

I believe it just has to be unique. E’s web builder requires it to be formatted a certain way, but the app and player don’t seem to care. I’ve gotten away with just having the ids increment from 0.

Definitely a good idea, yes.


My goodness I need to read these articles soon :sweat_smile:

A structure/tree I am thinking about would go as follows

index or config or app or stage.js  = sets the stage/config properties
 |- scenes
 | |- scene1.js
 | |- scene2.js
 |- [other things like objects, custom rules, etc.]

Some examples of the export/import stuff (package management)

  • To use a custom rule in an object you can .listen(new CustomRule(require('draw_like_a_pen')))
  • To add a rule .listen(new GameStartsRule(), () => { /* code */ })

I’m still just trying to form an idea of the structure – and I like to learn by example so if you guys have any examples of a basic project you could code, a tree or some code samples would really help me expand on this


Like @Petrichor said, presets might be good to take a look at. Anything that’s in my HS Tools is 150% fair game for this project.

Possible to just keep the .hspre extension? The JSON structure works with existing Hopscotch keys and is super easy to work with simultaneously

definitely its own thing, separate on the tree and should be importable/exportable

In some form or another we should be able to write code in one place and make it a “module” like how presets can be tossed around different projects. More than just custom rules and abilities of course, since we’re not limited to the JSON structure.

I can see this haunting us later, yet I’ll still say let’s not worry about it for now :D

So useful. Or even just dictionaries.

I wouldn’t mind a syntax that looks almost exactly like what you have. I try to design things with that in mind, but most of the time I have no time to properly document and improve it :P

aaand only 10 more long posts to catch up on later


I think that right now we are focusing on making it basically be a text version of Hopscotch, but with room to eventually expand into some more advanced things. So for example you could make a project like this:

with something like this:

Config // Could set things like stage size and some initial constants, as well as which scene is the first one.
|- scenes
| |- Scene 1.scene
|- Objects
| |- drawer.object

Scenes could be something like

scene "Scene 1" {
 gameStartsMessageName: "First game starts" //Game starts rules would be replaced with listening for this message, unless otherwise specified. Or maybe not, it might be better to code it yourself and just encourage it(?)
 objects: [
  drawer //A list of objects. Could choose objects from any file.

While objects could be

object drawer(type:text) {
 block goToFinger() { //Custom block only usable in this object. In this example it'd make more sense for this to actually be usable everywhere. You could do this by just moving it outside of the object definition.
  setPosition(position: Game.lastTouch) //Have a position type that is just x and y and have versions of blocks that use that instead of multiple parameters?
 when tapped(Device) {
  if (self.cloneIndex == 0) {
 when pressed(Device) {
  if (self.cloneIndex == 0) {
   drawTrail(color: HSB(0,0,0), width: 10) { //would parameter labels need to be specific values, or would they be able to be anything and determine the key of the Hopscotch parameter?


Preferably it would actually add another object before it to do any setup, though I guess in this example we can say that the compiler was smart enough to know that that wouldn’t actually do anything.

I like the idea of a file for setting up the stage, we could use it to also set various constants to be used throughout the game.

It would definitely help people who already have a bunch of presets made for various things to be able to use them with s small amount of modification.

Other than math blocks, how many more things do we need for a single project? For multiple projects having objects and even scenes would definitely help too.

Maybe we should also try to make the libraries from this as usable as possible if you just import them as a preset with E’s builder and use them in the Hopscotch app. Using slightly modified presets would definitely make this easier.

I have no idea what you’re talking about and if it is in reply to anything I have said I seem to have conveniently forgotten about it. Hopefully someone comes along and finds a solution for us.

Yes. After we get this working one of the first libraries I’m planning to try to make would be dictionaries of some kind.

Yes that is definitely pretty good, though I’d suggest changing ability to block, since they are called custom blocks now so that would be better for newer users coming from the app.

Come on, it’s only 18 posts total so far!


I may do something like based on Python, do you think this maybe a good idea? Like combining tainted and stuff, or even something else



This is really excellent brainstorming! You’ve all put a lot of thought into this!

I’ve attempted to program replicas of Hopscotch in the past, but never too seriously.

But creating a script language that will generate the source Hopscotch JSON code? (And can be run via the web explorer) AWESOME!

Hopscript needs to be easy to work with

My hope is that in the end, hopscript will be as easy, or even easier than the block language itself.

Which means we’ll need to define the pros/cons.


  • Editable using a basic text editor.
    • It will be more readable (big picture-wise).
    • Highlight which line(s) of code to copy/paste.
    • (Potential code coloring?)
  • Project can stored on GitHub.
    • You can commit your work.
    • You can undo any commits, view changes made.
    • Browse and Fork other projects easier.
    • Publish releases as a framework.
  • Add comments and documentation to your code
  • Easier to work with Operators (+ Addition, etc.)
  • Easier to work with Scoped Variables
    • If you want an object’s variable you can say self.trailWidth instead of Hopscotch’s complicated syntax.
  • Easier to work with clones
    • But if you want the original object’s variable, you can say Self.trailWidth (Or maybe we figure out some array syntax to refer to specific clones)
  • (I’m getting ahead of myself)
  • Launch learners into being able to understand a real programming language! This would be a real stepping stone for a beginner to learn their first text-based programming language (albeit it is a script). But it will make them more comfortable.


  • I’d imagine that there’s a rigamarole setup for when you want to make a new project. This would need to be as simple as possible. Perhaps there’s a boiler plate project everyone can fork from, with plenty of documentation.
  • May be more difficult to learn for beginners, since it’s technically a lower level language. But I don’t see this as too much of a con. I’d imagine it would be fairly easy to learn, after seeing a side-by-side view of The Script vs. The Blocks.
  • Launch learners into being able to understand a real programming language! (As it may take away from the app, unless this is the next step for students beyond the blocks!!!) A Pro for the user, but maybe a con for the HS corporation, depending on how they view it. Unless they are a nonprofit?

So now the fun begins!

I know it’s too early to determine how the script will actually look, but that doesn’t stop me from making concepts.

I’m going to take a Pythonesque approach and not include {} curly brackets in my examples. (Even though my home language is Swift). I think not using the curly brackets will make the script cleaner, but that will mean the script will hinge on proper indentation. So we further think about this later.

Every concept in Hopscotch will exist in the script

Which means we’ll need a list of every concept. (I’ll probably miss some as my HS Version is very elderly). But we’ll start with the most basic features- and move to the most advanced

Object Categories

  • Image Objects
    • Bear, Gorilla, Octopus, etc.
    • Custom Images
  • Shape Objects
    • Quadrilaterals, Circles, Tetromonoes, etc.
    • Custom drawn shapes (SVG?)
  • Text Objects
class Bear
    image = “Bear.png”
    animations = [“Bear.png”, “Bear2.png”, “Bear3.png”]

class Circle
    shape = “circle.svg” // or maybe these are images too?

class TitleText
    text = “It’s Here!”

Subclassing Boilerplate Classes
Let’s say you want to make a lot of Bears…
You can make an object, inheriting from Bear, so it will already have the variable image set.

class SuperBear: Bear
    pass // no need to initialize `image var`

Importing Custom Assets/Images
You would be able to put your images in a special asset catalog directory. And when you want to set the object to that image, you would say image = “foo.png”

Prebuilt Object Variables

There’s quite a few variables that each object has.

Most of them are if type Float (get set) but some are not. Some have different types String and others do not have (set).

All built-in object variable are immutable, but most can be mutated by using a corresponding function. (I wish to modify this in Hopscript as I’ll discuss next)

Float Variables

  • Rotation
  • X Position
  • Y Position
  • Invisibility as a %
  • Size as a %
  • Speed
  • Width
  • Height
  • Z Index
  • Origin X
  • Origin Y

Integer Variables

  • Clone Index
  • Total Clones

We need to make variables mutable, which is easy to implement:

// Long
self.setPositionTo(x: 100, y: self.yPosition)
// Same line of code
self.xPosition = 100

I’d write out all the variables and match their corresponding functions, but I’d like to move on to the next topic.

Control Flow Blocks

These are a little different than ordinary blocks. They are public functions that have a closure.


I’ll have to return to this

I eventually want to make a fully fleshed roadmap. There are so many features in Hopscotch! I’m getting sleepy so I’ll return tomorrow…

One final note

Great idea.

A scene could be a separate data model, where you declare the objects it contains. So the following scene contains 2 Bears:

scene Scene

class Bear
    image = “Bear.png”