Hopscript: Hopscotch Text Language (Concept)

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”

Oh wow I totally did not spend half an hour trying to make this a few weeks ago and give up because it takes too much time and effort and also because I’m working on too many projects

I find block coding an important feature of HS though

Excuse me did I just look at an indentation system!?
Do you realize this was made by evil alien artificial intelligences as part of their “python” scheme to make new programmers unable to code in other languages and therefore be trapped in python and make nothing but machine learning programs therefore helping the evil AI’s to multiply?

also making a language needs a lot of steps which I absolutely yeeted while making EGCode

If hopscript somehow gets finished I might make an editor/web interface for it

Well yes the language will probably be in nodejs which is not browser friendly. Deno was made by the same person as node but he added features that he wished he could have added to node but he was too late for, deno code can mostly be used in browsers

Technically I could make an EGCode library to compile the json file, its syntax was inspired by hopscotch

But honestly it has a trillion bugs and exploits to evaluating js and hasn’t reached version 1 yet


Sample program i guess

 scene(Scene 1){
  object square(my square,,200_200){
   when(game starts){
    setcoloR[hsb( 200_90_100 )]
    All of this is valid EGCode, you can run it but it won’t do anything because there’s no such library as “hs”
    Also yes this is case insensitive, mostly

As someone who has written, or has collaborated on writing, a few compilers as part of my job, I think this is a super cool idea. I don’t want to get in the way. Can I offer some very high-level tips?

  • Expect that this will be slow going, and that you’ll have to iterate on designs multiple times before anything useful emerges. One of the reasons that writing a compiler is hard is that you have to bridge the precise execution semantics of the target language (in this case, HS JSON) with the very mushy human expectations of how the surface language (Hopscript) “should” look like and behave. (Compilers are tools for transforming surface languages into target languages). Figuring where to build that bridge, and how to build that bridge, is basically impossible to get right the first time.
  • Before getting into any implementation specifics, figure out where you want to locate your surface language in the world of possible languages, and be able to justify those choices. The bits of Hopscript I’ve seen above make it look like a standard Object Oriented (OO) language. Can you say why? Is that really the best model for capturing the essence of what Hopscotch projects do? Here for example is some writing about the thought and evolution of the models that are part of Hopscotch now.
  • Hopscotch has a roadmap and is (we hope) a living growing thing. What is the idea for how Hopscript will compile to Hopscotch JSON as Hopscotch itself evolves? I think Hopscript should follow Hopscotch’s growth. Hopscotch is why we’re on this forum.
  • On the other hand, perhaps Hopscript can be a setting where types (in the programming language sense of number vs string vs array vs vector vs color etc.) for Hopscotch can be explored and experimented with. The topic title “Hopscotch Typed Language” grabbed me because I’m interested in how HS will navigate adding types. (maybe change “Hopscotch Typed Language” to “Hopscotch Textual Language” ? For comparison, google search: typed programming language) Still: introducing new programmers to the notion of types is valuable. JavaScript’s very loose typing is a lousy model for an intro to coding (and people tired of it are graduating to TypeScript). Being able to thinking clearly about the types of things is part of thinking about what a program is supposed to do.
  • Elizabeth focused on the MVP (minimum viable product) when introducing local variables. Thank you Elizabeth! What’s the MVP for Hopscript 1.0? As you may know, defining an MVP includes deciding what you won’t take on, which is hard.
  • Speaking of minimal: people who were introduced to programming via Hopscotch may not appreciate how incredibly well-chosen the elements of Hopscotch are. Having worked in lots of other established programming languages, it is really amazing to me how so many awesome HS projects have been built from what is really a delightfully minimalist programming model. You can wrap your head around all of it pretty quickly, which makes it a very powerful way to introduce programming. Less is more.
  • Familiar to you doesn’t mean easy for new coders. Others here may be familiar with JavaScript, node.js, npm and other elements of modern web programming, but do those things necessarily belong in an intro programming language? eehhh. Hopscotch’s use of JS and JSON for execution behind the scenes is incredibly smart, but so is the fact that Hopscotch coders don’t know they’re actually using JavaScript! Nothing about the way that modern web programming has evolved was designed with education or intro-to-coding in mind, and Hopscript can helpfully hide some of that mess.
  • There is a rich history of people creating programming languages with an eye towards education, and that history can usefully inform your design choices. Some that come to mind: Logo (the origin of the turtle graphics model that lives on in Hopscotch’s Move Forward and Change Angle blocks), Smalltalk (Samantha John has said that Alan Kay is one of her mentors), and of course Scratch. Wikipedia has a whole overwhelming page about this. To make this more actionable: as you create Hopscript, you’ll have to make various design decisions about what you want the code to do, and how you want the code to say it. At those decision points, you can force yourself to answer the question “what is the underlying problem I’m solving here?” and then try to learn how have others solved this problem already, especially in the context of making an educational programming language. Standing on the shoulders of giants and all that.

Good luck!


This is all really beyond my skill level, but nonetheless, what I can get out of it seems cool and I think this would be incredible to have!

If I can help in any way (besides moral support) give me a tag!

Setting this to Normal otherwise


I feel like a better way would be to have

  • Charcater objects
    • shapes
    • characters
  • Text
  • Custom images

Which would be closer to the actual Hopscotch code.

Oh yes, good idea. We could have a class for every object type, which would help with newer coders.

Yes this is a good idea; we could let you pass in parameters to the bears to make them be different.

This is definitely something I would like to try


Sure – once we’re done with the core language, we can probably go and reimplement E’s presets in as Hopscript functions.

In regards to functions with variable parameters, read below. However, I was thinking metadata could be all-encompassing for an entire library, or for an entire set of functions/presets, so then that would include lib name, author, Git repo, Hopscotch link (if applicable), etc. - kind of like a package.json file.

And then there would be the Hopscotch binary object metadata that would be generated. I think this was what you were referring to.
For clarity, we can name the config file hpsc.config.json for now, and the binary config would be called just that - the binary config, for libraries and maybe Hopscript-compiled projects which one could extend.

Mm - maybe we could use a special function call to generate WET code:

// Not a final version of Hopscript

// This doesn't follow the clone example you made,
// but this is a representation of "WET" generation
ability roar("Roar") {
   self.roarCount += 1

// Custom functionality: ability with parameter
// which automatically generates WET code based on param given
ability jump(name: "Jump around", heightToJump: int) {
   repeat 50 {
      y += (heightToJump / 50)
   repeat 50 {
      y -= (heightToJump / 50)

object Kyle(type: "Bear", name: "Kyle") {
   // The "dupe" keyword would "duplicate" the code
   // in roar() into its own separate WET section
   // because it's manually specified
   dupe roar()

   // There's also the custom parameter function,
   // which will automatically generate n lines of WET code
   // due to the parameters set.
   // In this case, 5 separate sections of WET code
   // because the function is resupplied with 5 different params?

   self.jumperVar = 0
   repeat 5 {
      jump(heightToJump: jumperVar)
      jumperVar += 1

This is true! Yes, a programmer could do this independently.

These would go against Hopscotch’s mutable and non-rigid message and variable system. However, having the ability to declare immutable messages would make them more typed, so I think this would be a good optional feature. Maybe we could do mutable/immutable variable types as an optional feature too.

If we ever need a place to define globals, I think a separate file would be a good place to start. However, I personally believe that the compiler shouldn’t stop you from calling globals from another completely separate file. With local variables coming soon, we can prepare for this possibility too.

For sure - I’d like to help design this though! I’ve got some experience with coding in many different languages as a kid, so I can use that experience to my advantage.

I’ll have to write something up later.

I like the idea of having the compiler generate IDs for us, in a way that looks official, anyways. Maybe we could have that as a config option though. I just don’t want to mess with the current standard.


Thank you!

Thank you!!! I accidentally gave ownership to the org I was going to ask you to give me back ownership, but looks like you just did it. Thank you! Yeah I was just testing around today


For sure. So it wouldn’t be in JS - we were thinking of using .hpscn files for Hopscript Scenes, and .hpobj for Hopscript Objects. And then maybe we could have a generic .hpsc file for anything else you’d want to add?

I think writing everything in JS would be a pain, and/or not enough of an abstraction for new users. It also wouldn’t help to split Hopscript as its own product and compiler.

In terms of the Node-based compiler, we could write it in Node and parse the new language into JSON. This would be the hard part, but hopefully worth it in the end.

Let’s get together and write an example codebase, though. I’ll make a formal post about it for everyone involved.

Could you give me an example of what you two mean with the format? I feel like that would be its own separate thing that we could, and should, support alongside the base language.

Yes! Just added to the features list.

This sounds cool, but really this could be achieved with a separate object within the scene.

Ah true.

Long posts in, long posts out. :rofl:


Make sure that your Github profiles do not contain personal information (such as full names or profile pictures that display your face), or I will need to remove the posts regarding Github discussion on this topic.
@Rawrbear @JonnyGamer @Awesome_E @Petrichor @Electogenius


Thank you for letting us know! @JonnyGamer, you might want to make an alt or something.


In the meantime @Rawrbear please make sure that the people whose profiles have personal information are excluded from your github organization.


I’m gonna go ahead and remove my post for now, and then when everything’s situated I’ll post it again. Thanks.


Thank you, and good luck with the project - excited to see how it turns out!


Yes, of course! Thank you! :)


Hey @JonnyGamer, just so you know I just set your Swift concept repo to private. It looks like your organization visibility is private (it won’t display your name as part of the repo because of your settings), so that should be all clear for forum PI rules. Just let me know if you want to make a Hopscotch alt or something so I can invite it, or remove your last name from your GitHub account.

Really sorry about this, but rules are rules.

You should be able to see the private repo though if you want to transfer it back. If you end up making a Hopscotch alt, you can clone the repository, destroy the git references and then republish it under your alt, so your personal account isn’t in the history.


@Rawrbear For the profile issue I had to remove JonnyGamer from the repo. the repo in there also needs to be transferred back, right?

not a long post lol


Okay, thank you. Yeah, I’d like to wait for Jonny to get back in the meantime so he can handle that. You could go ahead and clone the repo if you’d like to overwrite the Git history yourself and reupload (or I could do it if desired), but since they’re Jonny’s commits it’d be more fair if he did this himself a second time then.