The Making of Modulo

Welcome to Modulo. In this debut post I want to cover the origin of this project from its inception to where it is today, now that it’s just a few steps away from becoming a real product. We’re finishing up a prototype and starting a journey!

A few years ago I started a project called Bughouse as an excuse to learn Git and build a game engine at the same time. By day I worked as a full-time engineer building graphics engines, an extremely tedious and mundane part of a much more exciting game stack. So, I tried to live my dream during the night like Batman.

Curiously at the same time I had my little boy growing up learning Scratch, a popular 2D coding platform for kids. His creation was cute and all but I found myself secretly screaming “there’s another whole dimension out there little fella!”.

Surely enough he got more and more frustrated as his Scratch “game” became more and more complex. There was just no easy way to debug the Scratch blocks. It was also hard to tell if the blocks you just copied from someone else could work right in your situation. It was just hard to be sure, and so the same mistake got carry over from one project to the next, spreading like kid’s germs in the flu season.

So, one day I had an epiphany — what if I teach the dude C++ in Visual Studio? It’s (almost) plain English after all. He can read comments, can’t he? And being able to finally debug the code would be jaw-dropping! Unfortunately about five minutes into my excitement, it was painfully clear that that was too much to ask from a fourth grader. He repeatedly questioned the reason for those semicolons and I couldn’t really answer it.

By that time I’ve already integrated Lua into Bughouse and was still deciding what to do on the rendering side. Lua is far cleaner as a first language for beginners than most other scripting languages out there. That’s why it’s massively popular among game developers notorious in their intolerance of questionable language quirks. Lua is also really fast and comes with a strong debugger library. Most importantly, semicolons are optional in Lua.

It was something to be able to write Lua code to reproduce the Fibonacci sequence. It was something else to code up an interactive three-dimensional Rubix cube on the screen. That was our first coding project using Bughouse.

As time passed new features were added. Before long we found ourselves controlling an ogre chasing a baby dragon through the valley using an Xbox controller. The engine at this point was entirely controllable by Lua. What if I package the characters and make them loadable as assets in the game? The more I put Lua at the control center, the more I realized I was effectively creating a language platform for games.

Having a scriptable engine was cool and all but there was this one little problem — kids don’t code on a blank screen. Their imagination came crashing down pretty quickly. I recalled my own experience when I first started to code in my early years in college. We played this little game called “CROBOTS (see-robots)”, a DOS-based battlefield shooting game that lets you control your tank in C. That was the first time I coded in C and it was truly awesome.

I wanted to recreate the excitement when you win a game using your code instead of your hands. The player participates in the game that allows them to change it.

I wanted to meet the kids where they are. The learning curve of the system I created should be gradual enough that a kid can learn the lessons on their own pace with some help along the way. The code editor must be smart enough to help them with what they wanted to do in real time. The debugger must clearly show the result of the action of the code being executed while allowing the state of the program to be fully inspected. Most importantly, there must be no code-behind magic — my key design goal is that every single line of code that makes up the game must be fully and plainly visible to the user to see and inspect. To share a game among creators, all you should ever need to do is to copy and paste the code text, open source style!

Our first coding project in Modulo is “Code E.D.”, an RPG game with our hero robot character Ed. The goal for Ed is to teach basic programming ideas and language skill. The user solves the structure puzzles using nothing but simple move commands and a lot of imagination. Ed the robot, our main character, was inspired by a unicyclist wearing a backpack while traveling.

Code E.D. encourages procedural thinking and problem solving skill. It should be a great first lesson to anyone new to coding. But even for a more experienced coder, I would challenge them to try to beat the last few stages in less than 15 minutes.

In a way I think of Modulo as an experimentation. What if we build a professional-grade tool, make it incredibly simple to use and to share the creation, then put it in the hands of the kids? What are they going to build with it? It’s certainly a journey and not a destination. Can’t wait to see what happens next.

Peace.