Last week, we announced robot programming was coming to RoboCo and why we thought it was so cool. However, we didn’t reveal what programming language we decided to go with.
As you may have gathered from the title, Python is our language of choice. However, it wasn’t an easy decision. Today, we’re exploring what exactly went into that decision, including why we decided to go with written code and why we went with Python over other popular languages like Java and C++.
Finding the Right Approach
As we began designing robot programming, we considered several options for how it could be done. We ultimately decided to start with support for written programming in the Python language. We hope to later extend this with an external Blockly helper tool that will provide a visual programming alternative.
But let’s take a step back and see how we came to that conclusion. There are valid reasons why a game might use any of the options we considered below. In RoboCo’s case, we aim to support both general gaming audiences and education-centric audiences like FIRST robotics teams, and we want to have a strong launch on Steam Early Access. Therefore, we evaluated our options by looking for the best overlap between those two audiences, by considering the user experience, and by aiming for the smartest use of development time.
Option 1: Node-Based Programming
How It Works: Place nodes (the rectangular cards in the picture) and connect them with lines that define their inputs and outputs. The flow from node to node describes the robot’s behavior.
Examples: Main Assembly, LEGO EV3-G
Why We Considered It:
- Node-based programming is designed to visualize how an input is processed through a series of logical instructions and eventually yields an output, which is pretty much what robot programming is all about.
- If you arrange your nodes and lines well, you can view a lot of logic in a compact form on screen at once.
Why We Didn’t Choose It:
- Describing complex logic using nodes and lines can quickly lead to spaghetti-like visualizations that are hard to follow.
- The most notable instance of node-based programming in robotics at the K-12 level was LEGO EV3-G, and LEGO has retired this language in favor of word block programming with its new Spike Prime line of products. This change may make the node-based approach less familiar to the next generation of students.
- Considering we don’t have any precedent for a node-based interface in RoboCo, this could also have been time consuming to build.
Option 2: Physical Logic Blocks
How It Works: Place physical blocks that serve as units of simple code: a timer that counts down, a button that sends a signal when pressed, a logic gate that only lights up when a condition is met. Connect the output of one block to the input of another block to form a series of instructions. Technically, this is still a form of node-based programming like above, but now the nodes occupy physical space in the game world.
Examples: Scrap Mechanic, Besiege
Why We Considered It:
- It is easy to set up simple behaviors, such as “After this timer counts down to zero, turn on a light.”
- Since players are coding with physical blocks in an environment, they may stay more immersed in the game world while coding.
- Coding in this way can inspire fun, puzzle-like thinking: How can I combine these simple game pieces to make something powerful? Much like when players use redstone in Minecraft to make 3D printers.
Why We Didn’t Choose It:
- Creating even a moderately complex behavior out of such simple units can require lots and lots of logic blocks strung together. This is the cumbersome flipside of that puzzle-like thinking.
- If RoboCo had logic blocks that were physical parts on the robot, then any robot with complex logic would become big and unwieldy. If the logic blocks were still physical but were attached in some other editing mode separate from normal robot editing (e.g. zooming in on the circuits of the robot’s brain a la Logic Bots), then RoboCo would need a new interface and systems to support that other editing environment.
- The skills that a player develops from coding in this manner may not transfer as easily outside of the game. This approach is pretty different from how computer programming would be practiced in most settings. Working primarily with logic gates is more likely to be done in an electrical engineering context.
Option 3: Scratch-like Word Blocks a.k.a. Block-Based Programming
How It Works: Snap together word blocks to form instructions that are very similar to written code.
Why We Want to Support This:
- This form of visual programming is the most likely to be familiar to the average computer science student or teacher. It also has a strong presence in the robotics community via LEGO, Makecode, VEX, and REV.
- Word blocks are very similar to written code, But they still have some visual programming benefits that make things less intimidating when you’re starting out: You can easily browse an inventory of blocks to see what’s available. So if you know what you want to do but you’re not sure how, you might see something in the inventory that gives you an idea. The shape of each block also indicates how it can snap to other blocks, helping you assemble structures like conditionals, loops, and functions.
- This easy to understand quality doesn’t just help students; it means any age or experience level in the general game audience could quickly start to get cool behaviors happening. Word blocks aren’t the most common approach for games but it does happen (e.g. Modbox).
- Many block-based programming tools allow users to easily output their word blocks to written code. So this form of visual programming pairs well with written code.
How We Want To Support This In the Future:
- Even though we’re focused on supporting written programming for now, our aim is to add an external Blockly helper tool for RoboCo in the future. This will let you assemble word blocks in your web browser and export written Python code that RoboCo will understand.
Option 4: Written Programming
How It Works: You read at least a little bit of the documentation (boo!) and then you start writing out cool things for your robot to do (yay!)
Examples: Space Engineers, Stormworks: Build and Rescue
Why We Decided To Start With This:
- Writing code is the most common way that people do computer programming. Any coding skills that players might already possess should transfer to RoboCo, and likewise any skills that users develop in RoboCo should transfer back to the real world.
- No matter what form of programming we had chosen, we would need a way for the game to interpret user-made code so that robots can carry out instructions. Integrating an interpreter for a written language has the advantage that RoboCo could immediately understand tons of important instructions built into the language (like loops, conditionals, math operations, functions…). This means we could focus on adding the custom API instructions that let you talk to your robot, like asking a sensor what it detected, or telling a motor to spin.
- Players editing their code in an external IDE like VS Code will get much better quality of life features than we could recreate in-game: syntax highlighting, auto-complete, multi-select, undo, copy-paste, find references, go to definition, auto-import, rename all, etc. That’s not to say the game won’t hold up its end of things when it comes to quality of life: The game notices any time you save your Python script file, so you can have both the game and the IDE up and quickly make and test changes. And we recently finished a handy in-game debug console with a history, filters for print statements vs. errors, a Pause on Error toggle, etc.
- By saving time implementing robot programming, we can instead spend that time making RoboCo an overall better game in preparation for its Early Access launch. An example of this was the brand new part coloring system that we shared in a previous blog. It made sense to us to spread our efforts across several areas instead of going too deep on just one.
- While we lose some accessibility by not having visual programming right away, we don’t give up any power. Indeed, having a written code interpreter makes the possibility space for users larger than it would have been with any other approach.
Why Did We Choose Python?
Ok, so that covers why we chose written code as the foundation of robot programming in RoboCo. Some of our coding enthusiasts may be curious how we settled on Python as our language of choice.
First of all, we knew that using an interpreted language inside RoboCo would be much more practical for technical reasons. This immediately took compiled languages like Java or C++ off the table. Interpreted languages also allow for a faster iteration speed for players writing and testing their code.
Second, we wanted a highly popular language so that more of our experienced coders might already be familiar with it, and more of our beginning coders might soon encounter it. Python is one of the most popular languages around.
Third, we wanted something relatively easy to use. Python aims to be readable, avoid complex syntax, and use straightforward English to the extent that it can. It is often recommended as a good language for beginners.
Fourth, we wanted something that made sense for robotics teams and educators. Probably because of the combination of our second and third points, Python is a coding language commonly taught in schools, is part of the Project Lead the Way curriculum, and is supported by educational resources like CoderZ or CodeCombat.
Finally, while any and all coding experience is valuable, and underlying concepts are more important than the language itself, it doesn’t hurt that Python in particular is highly in-demand for jobs, making it quite relevant for students outside of RoboCo. Knowing Python could lead to a career in various fields, including software engineering, data analysis, product management, machine learning, or mechanical engineering. Combined with our company mission of “creating playful experiences that improve people’s lives,” these reasons made Python the perfect choice for RoboCo.
Bringing Your Robot Commands Into RoboCo!
But how exactly does all this work? How do we get our code from Python into RoboCo? Well, that’s a great question and one that we’ll save for next week’s blog, where we’ll showcase step-by-step how best to write your code, upload it, and get your robots running all by themselves!
For the latest news on RoboCo, follow us on Twitter, YouTube, Facebook, Instagram, and Tik Tok! You can also connect with other community members and us by joining our official Discord and Reddit!
Don’t forget to add RoboCo to your Steam Wishlist!