Here, There Be Dragon... Rubies...

Big software projects, at big software companies, are deeply collaborative affairs. The majority of the work isn't writing code; it's getting a shared vision into everybody's heads.

That's not what this post is about, though. Since I decided to take a little break from my day job and decompress, I found an activity that relaxes me, and reminds me of my earliest days writing software.

First I'd like to describe what my earliest paid software gig was like. Then I'll talk about a personal project I worked on back in 2012, and then another that I'm working on now.

Memory Lane: QANIMATE

Back in my High School days, I worked on a project called CUPS, "Consortium of Upper-level Physics Software". You can still find traces of it online. The piece I wrote is QANIMATE, although they did misspell my last name in the author attribution!

I worked with Ron Stoner at BGSU over the course of a summer. Essentially it was an internship, an educational opportunity for me. Though there were other students going through the same educational program as myself, they were working on other projects (mostly not software) and I wasn't interacting with them. This was not a classroom setup. It was the professor sitting in his office, and myself sitting in another nearby.

I remember our collaboration with fondness. Two aspects stand out in my memory:

• The professor gave me my own space to work, and remained available to answer any questions I had. He was patient and explained what I needed to know about the project's requirements, and the physics I needed to understand to be successful.
• Apart from that, he just stayed out of my way and let me work.

At the start, naturally, I needed a fair amount of instruction. It helped a great deal that he had an example program for me to play with, that would produce a static picture of the field lines around a moving charged particle. That was a snapshot. My goal was to produce an interactive, animated version of the same thing.

In addition to learning the physics, I had to learn my way around the software environment. Here I was on firmer ground. The project was to be written in Pascal, a language I had learned a year or so earlier in High School. (This is the first structured programming language I learned. Before that, I had tinkered with Commodore computers and taught myself BASIC and assembly language.) The development system, called Turbo Pascal 6 if I remember right, would likely still be recognizable by contemporary developers as an early form of IDE, though the interface was primarily text. The release date of Windows 3.1 was still a year away. CUPS provided libraries to handle the animation.

I recently came across this quote by Allison Mnookin:

My idea of hell back then was sitting in an office alone and thinking deep thoughts.

Not me. This is what I recall a typical day being like, that summer:

• I rode my bicycle from our house to the college campus. I did not yet have a driver's license, but the streets of the little college town weren't so busy as to create a problem. I locked my bike in the rack and went inside.
• I said hello to the professor if he was there, which he usually was (absent a short vacation or two).
• I sat down at the computer and resumed work on the program.
• If I had a question for the professor, I'd walk over to his office and ask. He was always happy to help me out. There were many days when I had no questions.
• I took a break for lunch and worked a few more hours in the afternoon.
• I rode my bike home at the end of the day.

It was delightful. I would make progress, then periodically show the professor what I had, and get his feedback and suggestions. Sometimes he pointed out things I was doing that could be done differently, and I'd course correct. In other cases, I made independent decisions, and he let me chart my own course.

In that time, Object-Oriented Programming was kind of a new idea. Turbo Pascal supported OOP, although it was entirely optional. It looked promising to me, and the professor had no opinion on it, so I embraced it and made that part of the program's design. It struck me as a positive change and I kept it.

I found my own metaphors for thinking about the field lines and wave fronts, and translating those into objects that could be rendered. Whereas the original program had required fixed inputs, the new one was to be interactive, so the interface had to be rather different. I came up with a few different ways of controlling the charged particle, altering its velocity and its angle of movement. I figured out how to add menus to the program. It got better by degrees over the course of the summer. By the end, it was in decent enough shape to present to an audience (a common practice at the end of internships). The software was sold to CUPS, as I recall, for a thousand dollars, and the professor and I each got half of that. It therefore qualifies as my first paid software programming job.

It's nice that the code survives, though I'm sure it's mostly a curiosity at this point. What persists is the memory of the experience of writing it.

Game2D: An Unfinished Gosu Toy

I've always enjoyed video games. I grew up enamored of arcades, and relished the rare chance to play games like Q*Bert and mr. Do!, feeding the machines quarters. (It proved impossible to convince my parents to give me enough quarters.) At home, I could play reasonable facsimiles of these games on my Commodore 64.

Back in 2012, I discovered a game engine based around Ruby, a programming language which I enjoyed using at work. The engine was called Gosu. (This is Korean for "highly skilled person".) I decided to try implementing a game idea on top of this engine. You can still find the code for this on GitHub (pardon the dust). The basic idea was to have a world constructed of square blocks, that would obey gravity and could slide around pretty much anywhere: their positions were not confined to a grid. The player, called a "gecko", would slide around the edges of the blocks. Blocks had different strengths that would determine whether they were considered supported (and would float where they were) or not (and would fall).

Since Gosu was built on top of standard Ruby, it permitted all the usual language features, including networking. From the beginning, "Game2D" (I never came up with a better name) inherently used a client/server architecture, via a networking library called rENet to make and accept connections. With the server running, players could join and leave at any time. It was designed to be robust in the face of packet loss, or clients falling a bit behind the server. There was rudimentary authentication with a password dialog. My intention was to back the system with a database, and store players' preferences server-side, but I never got that far along.

In the very early versions, I incorporated a 2-D physics library called Chipmunk. However I soon found I was jamming a round peg into a square hole. I wanted very specific behavior from the objects in my game, and Chipmunk kept trying to send my game objects careening off in various directions. So I threw out the physics library and wrote my own system to track objects and detect and handle collisions, with locations and velocities based entirely on integers, to make their behavior predictable. Accelerations as low as a pixel per frame-squared often proved too high, so I tracked objects in "decipixels" (ten X/Y points per visible pixel).

I describe this project as a toy, rather than a game, because what its game concept lacked was a clear goal. When I spent time working on it, I would get an idea and add it to the game system, and then play around with it to see how that changed the gameplay. But I didn't have a clear target in mind. For example, I thought it would be cool to add black holes to the game, and did so. They warp gravity around them: when a block falls within a certain distance of the black hole's center, the hole's gravity calculations take over (instead of the usual rule of "accelerate downward"). Any blocks getting too close to the hole are damaged and eventually destroyed. Objects passing nearby have a tendency to go into unstable orbits. This worked, and in action was quite amusing to watch. But I couldn't have told you what effect it would have on the game's balance, because there was no defined goal to measure against.

An even more absurd feature was the addition of an in-game language, which I called "gibber". I had spent some time researching whether it was possible to render player-supplied Ruby code safe to execute server-side, and concluded it was not possible. Gibber was the alternative: Develop a simple language that could be used by players and understood by the server, with narrowly defined powers so that it could never do anything unsafe. The language had a fairly simple syntax that would be familiar to most developers. It compiled down to a sort of bytecode, instructions to push and pop the stack and do conditional branching and so forth. Then I implemented a virtual machine (in Ruby) to execute the bytecode instructions. To give this language something to do in the game, I added a droid object that could be programmed in-game and would carry out its program. It had an "accelerate" primitive that would cause the droid to move around. It executed VM instructions at a certain rate per game tick, so as to make it impossible for an infinite loop to suck up all the server's resources.

Every time I added a feature, I had fun doing it and was pleased with my success. But it didn't advance the project because it wasn't going anywhere specific.

Keyth and the DragonRuby

This year, as I took a two-month break from working at Amazon, I found myself wanting to do something creative and self-directed. I decided to try playing with DragonRuby. This is another game development engine using the Ruby language, specifically a stripped-down implementation called mRuby.

The game engine's developer Amir Rajan (LinkedIn, YouTube) was kind enough to gift me a standard license thanks to my charity work. He gives licenses to people who meet any of several criteria, including those with low income, students, software development teachers, or anyone who has worked in public service. This level of social consciousness is becoming rare these days, and it means something to me that it still exists.

There are a couple of notable differences between DragonRuby and Gosu:

• Gosu is a library that runs on top of regular-flavor "MRI Ruby". DragonRuby is an engine that embeds the stripped-down mRuby. In particular, you can't use RubyGems with DragonRuby.
• Gosu presents no clear path to sharing your work with others, apart from instructing them how to install Ruby and then your code. DragonRuby offers the ability to export your project to Itch.io, Steam, and (with the proper license) Apple AppStore and Google Play.

This time around, I had a game concept in mind that was better-defined and much simpler. Many videogames feature doors and keys. In some, like Binding of Isaac, keys are interchangeable and spendable, like a currency: the only thing that matters is whether you possess more keys than there are doors you need to open. In others, like Doom, keys and doors are color-coded. Once you have the blue key, you can get through all the blue doors on the level. The arrangement of keys and doors often forces the player to crisscross the level in a certain order. I decided to explore the second concept.

I determined that this would be a puzzle game where the player has to reach a goal to advance to the next level. The core idea is to see how far the "keys and doors" concept can be pushed. For example, a door on its side can act as a ceiling or a floor. When opened, the player, or other objects, can fall through it. In some circumstances, keys might become things best avoided.

Somehow I got the idea that the game's protagonist, who is really more of a sad sack than a hero, is tired at the end of a long and difficult day and just wants to sit down. The goal is to reach his favorite couch so he can plop himself into it. That gave me a name for the game: On Your Keyster. Get it?

At a certain age, "dad puns" are expected of one.

Besides having the programming language in common, Gosu and DragonRuby both tackle some important basic tasks for the game developer. They make it terribly easy to draw sprites (images that can move around the screen), play sounds, and read the keyboard and mouse. DragonRuby lets you draw images at specific sizes and angles, and a host of other rendering tricks. (It's possible to make truly gorgeous games with it.) It takes a page out of Java's book and aims to be cross-platform by restricting the developer to functionality available on mobile phones, so the drawing canvas has a modest fixed size of 1280x720 pixels. It aims to redraw the screen at a consistent 60 frames per second, a common refresh rate for many games.

DragonRuby also has an extremely active community on Discord. If you get stuck or have questions, you can reach Amir or dozens of other enthusiastic game developers.

Sidebar: Interest in classic videogames is alive and well. Let me underscore that. If you assume, in this time of hyper-realistic three-dimensional big-budget blockbuster videogames written by armies of developers, that surely nobody cares anymore about two-dimensional games in the style of 1980s arcade classics, you are so wrong. Vinyl records are back in vogue, and games like Pac-Man are not "old" or "obsolete". They are "retro" and "vintage", and people half my age are obsessively analyzing them down to the bits. Search on YouTube for "Super Mario Brothers speedrun". Super Mario Bros. was released in 1985, long before the birthdates of the twenty-year-olds trying to shave a tenth of a second off of their time. People still write games for the Commodore 64. I couldn't make this stuff up.

Lest this post become an all-out DragonRuby advertisement (and yes, if writing your own games sounds like fun then I absolutely recommend making the time to try it out), it's a fact that no developer ever finds any of their tools 100% perfect, and I tripped over some of DragonRuby's rough edges. Most of these turned out to be places where mRuby differed in behavior from MRI Ruby, such as discovering that support for passing a String into class_eval was not supported. A few surprises could be traced to language-wide changes made by DragonRuby itself. For example, Arrays have been monkey-patched with a convention to make them easy to use to describe sprites. The convention goes something like [x, y, w, h, path, angle, ...] Calling (0..99).to_a.path returns 4 (which makes little sense in the context of this particular Array). Similarly, Hashes have been patched to accept arbitrary method calls, like an OpenStruct in the standard MRI Ruby library. Beware typos like {}.sze which returns nil (instead of {}.size which returns 0).

Monkey-patching, for those unfamiliar with the term, is a technique in dynamic languages like Ruby wherein you modify an existing class like Array or Hash, introducing new behavior. Normally this must be done with extreme care, since these core classes are shared by all the code in the program. However, it's usually the case that you have to contend with what other libraries ("gems" in Ruby) will be doing with those classes. Since DragonRuby does not support gems, there's no risk of accidentally breaking anything: the only code running is what you wrote. I therefore saw no reason not to do some monkey-patching of my own.

Another possible stumbling block is the built-in serialization of game state (with GTK.serialize_state), which writes an ASCII file to disk looking like {:entity_id=>3, :tick_count=>125, ... Deserialization is done by evaluating the string. A resulting size limitation means the engine will warn you if the file exceeds 20K (20,480 bytes), and as a workaround the documentation suggests splitting up state into multiple files. I didn't love that, so instead I cooked up my own field-based serialization format using Array#pack. This wasn't too difficult since I'd done something similar for work. I was worried it might prove to be too slow, but in fact it's extremely fast, such that I can implement "reset the level" (when the player gets stuck and needs to start over) by simply reloading the map file.

I could have written code to construct each level, of course, but that makes it more complicated to edit a level's structure. With a game like this, you want the ability to iterate rapidly.

This necessitated a parallel development track to construct a level editor mode. When I'm play-testing a level and see something I want to change, I press a function key and the level is reloaded in editing mode, giving me the ability to drag objects around with the mouse, copy and paste them, view and edit their properties, and so on. I add editing features whenever I uncover the need for them. When I found myself constructing walls and doors next to each other, and wanting their edges to line up precisely, I determined it would be easier if I could slice an object (a wall) into two parts, and then turn one part into a door. When I started losing track of which key operated which door, I added code to draw helpful lines between related objects.

To date, the walls and doors are plain uniform rectangles of various colors. (This game needs extra work if it is ever to be playable by the colorblind.) I immediately wanted better images for the more important sprites in the game: the player, the couch, and the keys. But I'm not much of an artist. I could certainly Google for images, but unless I was very careful I'd risk violating someone's copyright. These days, there's a workaround: I can ask ChatGPT to generate images for me. (I know, I know... these are generated by models that were in turn trained on copyrighted material. Life entails compromise.) ChatGPT's image generation does not often get it right the first time, but with repeated prompting and a bit of image editing, I've ended up with some graphics that are rather nice.

To be engaging, videogames also need sound effects. I found a fantastic source for royalty-free sounds on Pixabay. They only ask that the authors receive mention, and I'll certainly include the details in the credits of my game if (no, when) I get that far.

Above is a demo showing some of my progress, though it's already a bit out of date. (If the embedded video doesn't work, try this link.)

I'm not out of ideas. I have ideas for levels, ideas for fun game elements to add, ideas for music and for enhancing the atmosphere. Before long my break will be over and I'll be back to working full-time, but I hope to keep working on this project a few hours every week. I know now that even a few hours is enough to add the next feature.

Closing thoughts?

Closing thoughts, closing thoughts... let's see...

• Hobbies are good. Spend some time doing what you love, to please nobody but yourself.
• There's a community out there for every interest.
• If you enjoy writing software, recall the words of Isaac Newton: "I seem to have been only like a boy playing on the sea-shore, and diverting myself in now and then finding a smoother pebble or a prettier shell than ordinary, whilst the great ocean of truth lay all undiscovered before me."