Game Engines as an Art Form — My 8+ Years of Developing and Maintaining My Own Engine

The original article was written in July 2021, and was translated by Evan Ward. Thank you very much!

It’s been more than eight years now since June 2013, when I made my first commit on Ebiten, a 2D game engine (or game library, if you prefer) that I’m still developing in my spare time to this day. Now in its ninth year of life, Ebiten is coded entirely in open-source programming language Go, and has been used for a variety of games published on mobile platforms and Nintendo Switch alike, including renowned titles such as Bear’s Restaurant.

Ebiten - A dead simple 2D game library for Go

Game engines are not the sort of thing one can build in a day. And to be sure, in an era where robust prebuilt tools like Unity and RPG Maker exist, it’s perhaps rather foolhardy to go making your own engine from scratch. So why did I do exactly that? To put it simply, I wanted to see if it were practically possible to make a 2D game with the most minimalistic API imaginable. It was a personal aesthetic pursuit for me, trying to find beauty in simplicity — though I only came to realize this fact somewhat recently. Either I realized over the course of working on it that this was my true objective all along, or perhaps my priorities shifted over time.

In terms of graphical functionality, Ebiten is pretty much only capable of drawing one rectangular image after another. Every sprite, texture, and background is rendered as the same type of rectangular object (literally just called “Images”). Sure, you can specify things like placement, magnification, rotation, shading, and composition method at time of rendering via options. There’s even a relatively low-level framework for rendering triangular images as well. But for the most part, at least from a graphical standpoint, Ebiten is nothing more than a renderer of rectangles. One could even say that it was created solely to serve as a proof-of-concept demonstration for whether or not one could create a proper game using only this primitive image-drawing API.

Ebiten is a work of art. As an engine that represents the realization of an artistic concept I originally envisioned in my head, I really don’t think that’s an unfair classification to make. Just as a painter spreads their heart across a canvas, or a composer crafts a symphony, game engine development is, for me, a form of artistic self-expression.

Though to be sure, Ebiten is still a game engine at the end of the day, and thus its practical usability is obviously just as important as its artistic value. After all, what good is an engine that no one can actually use? And thanks to feedback from developers who’ve actually used it for their games over the years, I’ve been slowly but steadily improving the user experience. I’ve worked very hard to maintain its pure and simple API, all while digging down into the trenches and doing all sorts of dirty work on the backend to improve performance in whatever ways I possibly can. I can say with confidence that I do not know of another game engine currently in use that is designed around a core philosophy of minimalism to this extent.

Thankfully, I’ve managed to maintain Ebiten for more than eight years now, without ever losing that initial motivation in the slightest. If I have my way, I could see myself continuing like this for another several decades, even. I believe this unending pursuit of aesthetic perfection is something of a primal urge embedded in all humans, and I’m sure there will only be more people who wish to use Ebiten in their games going forward. But it’s taken me half a lifetime just to make it to where I am today, so in this article, I’d like to retrace the steps of my journey thus far — from my first formative gaming experiences as a young boy, all the way to developing my own engine from scratch.

Super Famicom

If we’re going to talk about what made me want to create my own game engine, we’ll have to go all the way back in time to when I was in elementary school. Back then, the Super Famicom (or Super Nintendo Entertainment System) was king. Games like A Link to the Past, SimCity, Final Fantasy (4, 5, and 6), and Earthbound captured my imagination. But for as much enjoyment as I got out of them as a consumer, they also sparked a desire in me to create a game of my own. I still remember having a blast just drawing out my own custom Zelda dungeon layouts using only paper and pencil. And while I obviously recognize that it’s a bit audacious looking back, I remember playing these old Super Famicom games and thinking to myself, “Yeah, I could totally make one of these if I just tried hard enough.” Little did I know just how difficult game development actually was.

Once the PlayStation era began, though, and the advent of 3D games was truly upon us, I never really got that “Yeah, I could make this” feeling when looking at a game ever again. While I admit that it’s largely rooted in a bias toward childhood nostalgia, I think perhaps this was where my obsession with 2D games began.

Though there was also one particular game on Super Famicom that may have had something to do with this: RPG Maker Super Dante. As the name implies, it was less of a game and more of a tool for creating your own simple little RPGs — but I still had an absolute blast with it, even if I never made anything remotely decent on it. My most vivid memory of something I created using it was a game where the final boss literally shows up as soon as you leave the starting town, and then you fight him, and then the game ends. Admittedly, when you create a game in RPG Maker, you’re basically just stringing together events using preset commands, but I would argue that this is a form of programming in its own right. This was my first real experience seeing a program operating based on logic that I created, after all — so I still consider it pretty formative to my development as a programmer and a game developer.

RPG Maker 2000

Full disclosure: I’ve bought every version of RPG Maker that’s been put on PC from RPG Maker 95 all the way to the latest edition, RPG Maker MZ. But out of all of these, it was the version that came out when I was in high school, RPG Maker 2000, that I have the fondest memories of. It was released in — you guessed it — the year 2000.

There are people I met at those old RM2K community meet-ups that I still keep in contact with to this day. In fact, it was around this time that I first met Daigo, who’d later go on to become one of my closest colleagues. You might know him as the creator of Bear’s Restaurant, one of Ebiten’s biggest success stories. Never in my life would I have ever thought that meeting him would lead to a nearly twenty-year working relationship.

RPG Maker 2000 was an extremely well-designed piece of software, and came as a revelation to someone like me, who wanted to be a programmer when he grew up. It’s hard to even put into words, but the first time I got my hands on the tool, I just remember feeling a kind of elegance, or aesthetic beauty in how incredibly consistent it was in its design. It was at this point that my desire to create my own game first shifted into a desire to create my own game creation tool. Especially since none of the games I made using RM2K were ever any good either — just simple, abstract maze games and the like. I always felt that I was probably more suited toward building a foundation upon which to create a game as an engineer than creating stories and whatnot anyhow. Whenever I try to imagine my own story or cast of characters, I always just end up feeling ashamed of everything I come up with… I really think you have to have a natural talent or be raised in the right environment to have a propensity for things like that.

But I always wanted to create a tool as powerful yet easy to use as RPG Maker 2000 — and I still do to this day. I even remember constantly ranting to Daigo about how badly I wanted to make my own version of RPG Maker. And perhaps it was this that ultimately made him suggest that we try making something together — and thus began a working relationship between us that still continues to this day. But I’ll touch on that in a bit.

Incidentally, the creator of RPG Maker 2000 was one Yoji Ojima, and he’s been in charge of the PC versions of the series from that entry onward. It’s said that up until the latest version, RPG Maker MZ, he developed each and every one as essentially a one-man team. And I think the fact that he developed such a consistent and powerful tool as RM2K almost entirely on his own is a greater testament to his skill as an engineer than just about anything. He is, and always has been, one of my greatest idols in the industry.

RPG Maker XP & RGSS

RPG Maker XP was the follow-up to RPG Maker 2003, which was itself the follow-up to RPG Maker 2000. This version came out in 2004, when I was already in college.

The biggest selling point of RPG Maker XP as compared to previous versions was the addition of RGSS — the Ruby Game Scripting System. Now, virtually all game logic was scripted in Ruby, giving developers far more freedom in exchange for a steeper learning curve. RGSS was sold as though it were its own new programming language that was simply an extension of Ruby, but in reality it was more like they just plopped Ruby in wholesale along with a library of functions and whatnot that were designed for use in games specifically.

This was my first ever encounter with Ruby, but I managed to teach myself how to use it without too much trouble. I still remember the thrill I felt when I first wrote a custom script that allowed the player to recover an enemy’s health if they tried to chuck a healing item at them for whatever reason. Things like that were simply not possible in previous versions of RPG Maker. The battle system in those versions was a pretty staunch imitation of the one in Dragon Quest, and it wouldn’t even let you move the cursor over onto an enemy when selecting a target to use a healing item on.

So, yeah. RGSS was basically just Ruby plus a premade “Game Library,” which essentially consisted of the following modules and classes (though I’ve left out a few of the more obscure ones):

• Audio
• Graphics
• Input
• RPG
• RPG::Cache
• Bitmap
• Color
• Font
• Plane
• Rect
• RPG::Sprite
• RPG::Weather
• Sprite
• Table
• Tilemap
• Tone
• Viewport
• Window

I remember thinking at the time “Wow. So you can make a whole game as long as you have this handful of modules and classes, huh?” This was another major revelation for me, following in the footsteps of RPG Maker 2000. Looking back on it now, it’s actually amazing how much I owe to RPG Maker in that regard. Daigo and I often joke to each other that RPG Maker is solely to blame for completely throwing our lives off course.

When it comes to drawing images, RGSS has two distinct classes: “Bitmap” and “Sprite.” Bitmap is like a canvas for painting images, while Sprite is like a container for manipulating these images. There is no off-screen rendering functionality in RGSS (for drawing images in a buffer zone completely separated from the visible space). And I remember looking at the API and thinking “I wonder if there’s a way to combine these two image rendering classes into one, and make off-screen rendering possible as well.” This was where I first got the idea in my head of rendering an entire game by simply drawing rectangular images one after another. And it was in pursuit of realizing this idea that I took my first steps toward developing my own game engine.

The Long Road to Creating a Game Engine

In order to realize the idea I outlined above, I started making test game engines all based around a similar concept in a variety of programming languages like Ruby, C#, D, and C++. Though to be clear, none of these attempts were remotely close to what one might call successful. The problem: I simply lacked the necessary talent as an engineer. Though it also didn’t help that I had no clue how people generally went about building game engines from scratch. Though it was thanks to that singular desire to create one that I was able to push myself to learn a wide variety of programming languages. I think I must have scrapped at least ten different engines before I finally hit the mark with Ebiten. One would think that the more game engines I created, the closer to a complete and fully functional product I would get, but in reality none of these failed attempts lasted long before being abandoned.

Probably the only engine that I did work on for very long was one by the name of StarRuby, which was written in a combination of Ruby and C. At the time, Daigo had made a game in RPG Maker 2000 called Clock of Atonement, and he used this engine to make a Ruby port(?) of the game. I actually had forgotten all about this version, funnily enough, but Daigo certainly remembers. Still, though, I only worked on this engine for maybe two or three years before stopping all development on it.
But that being said, the wide breadth of expertise I gained from this experience did ultimately pay off in the form of Ebiten, so I don’t consider it wasted time at all.

Go

In late 2009, Google announced their own programming language, dubbed simply “Go.” And while this new language did intrigue me, I wouldn’t say it was love at first sight. Go lacked many basic functions of other languages, such as error handling and generics, and to be quite honest I thought it was a bit too eccentric for me at the time. Though the iconic “Go gopher” really is an adorable mascot.

When I actually tried coding in it for the first time, my initial impression was that “Well, it might be a little more tedious to write in, but its behavior is extremely explicit and easy to read.” Very little syntactic sugar to speak of. In Go, if something looks like an assignment, it is one. In other languages, you’ll often get things that look like assignments but have other hidden side-effects, like overloaded operators in C++ or properties in C#. There’s none of that in Go whatsoever. That being said, it really is convoluted to do any sort of error handling in it, and this is the topic of frequent and fervent debate. I can absolutely understand people who hate Go purely because of how tedious it is. I think it’s really just a matter of personal taste.

It’s often said that Go is a very simple programming language. Unlike most modern languages, Go is extremely slow and cautious about adding in new functionality. There’s a famous quote in open-source programming, though I’m not sure who said it first, but it goes like this: “No is temporary. Yes is forever.” Meaning, the negative costs associated with saying no to user demands for new functionality are only temporary, and you can always change your mind. But once you say yes, you’re committed to shell out resources to maintain that new functionality for all eternity (or, well, for as long as keeping up compatibility is a concern). That’s how I read it, anyway — and it seems to be Go’s take on it as well. There have been considerably few functionality changes to Go since the release of Version 1.0, let alone syntax changes.

In some ways, Go is very similar to Ebiten — its minimalistic set of base functions being one of them. Though I didn’t choose Go to create it with for philosophical reasons, mind you — it just kind of turned out that way. Life can be funny like that sometimes.

The Birth of Ebiten

Before long, I was thoroughly smitten with Go — both for the language itself, and for its toolchain, et cetera. And so I made up my mind to try making a game engine in Go, just to give it a whirl. The result? The very first iteration of Ebiten. This was back in 2013, but never in my wildest dreams would I have imagined that I’d still be maintaining it so many years later.

The name Ebiten is short for “ebi (shrimp) tempura,” while also being a subtle reference to what users on the 2chan (now 5chan) message board used to jokingly call the (at the time) publisher of the RPG Maker series, Enterbrain (which we would shorten to “Ebi”). To be honest, I would have been happy with just about any name, so long as it was unique and memorable, and naming something after Japanese cuisine sure does make it stand out from the crowd. Would highly recommend.

Once I got it working on macOS, I was pretty satisfied with what I’d accomplished, and so I let it sit untouched for about six months after that (I believe I was playing around with TypeScript in the interim). But after that, I remember opening development back up to fix some extremely minor bug or something, and just going “Whoa, why was that so much fun?”, and I’ve been continuing to develop and refine it ever since. Almost to the point that it feels like the only thing that matters in my life anymore.

Gomobile

In 2015, a tool called Gomobile made its way onto the scene, and Go officially became smartphone compatible. I immediately made use of this to make Ebiten similarly mobile-compatible, purely because I wanted to increase the number of platforms it could work with — no greater motivation than that. You could say that I was simply laying the groundwork for the day it might hypothetically come in handy. And eventually it did, with Clock of Atonement, so I’d say the effort paid off in the end.

It was no mean feat to get Ebiten working on mobile. Without delving too deep into the nitty-gritty, I had to account for a lot of new variables, like handling context lost, necessary performance improvements, and ensuring compatibility with all the many little quirks and differences of each and every distinct version of Android and iOS. There was also the problem of ensuring that a game, once released, could work on a wide variety of different smartphone models and firmwares, something I hadn’t even considered up to this point.

My first lab rat for testing out Ebiten’s mobile capabilities was a game called Innovation 2007 by developer Omega, who was kind enough to let me port their game to the engine. I can’t thank them enough for doing that, because the experience gained from this would prove indispensable to future efforts, and opened the door to many more mobile games further down the line.

Clock of Atonement

As I mentioned above, I first met Daigo during the heyday of RPG Maker 2000 — so we’ve been close friends ever since high school, basically. He was the one I’d always rant to about my desire to make “my own RPG Maker.” He had plenty of his own ambitions, too, so eventually he suggested “Well, why don’t we just make something together, then?” There really are no greater friends than those made in the RPG Maker community, let me tell you.

At first, the plan was to both make a smartphone game and a game editor. I showed Daigo a version of Innovation that I’d just barely managed to get running at 30 FPS on Android, and told him I’d do whatever maintenance I possibly could to get the engine running better, if only he’d use Ebiten for this hypothetical game. He was immediately on board with the idea (I think). Though if it hadn’t been for that first Android version of Innovation, something tells me these discussions never would have even made it this far.

I remember him later saying at one point that the more logical decision would be to just use Unity or something like everyone else. And he had a point, to be fair…

Although I originally said I wanted to make my own RPG Maker, in the interest of time it was decided that I would simply be in charge of providing Ebiten as well as some basic, fundamental RPG systems that could work on it. I think this was the right choice, in the end. Ebiten alone was already enough of a time sink as it is, so it simply wasn’t realistic for me to try my hand at making a full-blown editor program as well. I managed to get these RPG systems up and running pretty quickly, and in a state that Daigo himself would have no trouble doing his own upkeep on if need be. This was partially due to Go being an exceptionally easy language to pick up and learn, but also due to Daigo’s own impressive prowess as both a game designer and an engineer.

For our first project, it was decided that we would port over Daigo’s RM2K title Clock of Atonement. Our main rationale for this choice was that doing a straight port of an already completed game meant there would be fewer variables to worry about, and that it would be a good way to test the waters and get some much-needed polish in on the engine tools.

We ultimately released this port of Clock of Atonement for Android and iOS in 2017, and it was even featured in the popular Japanese gaming periodical Famitsu — making it the first ever game written in Go to be featured by the magazine. Though to be fair, most of Daigo’s greatest achievements are also historic firsts for games written in the language, simply by corollary.

I still consider this release to be one of the most fortunate things to ever happen to Ebiten. Because you see, game engines have a bit of a chicken-or-the-egg problem, in that it’s virtually impossible to effectively polish an engine when no one’s using it, but no one wants to use an engine that’s unpolished either. And it was Clock of Atonement that broke through that barrier for me. I’d made and discarded many engines up to this point, but this was the first time I’d ever made an engine that had games that were actually getting a pretty decent number of downloads made for it. So thank you, Clock of Atonement. And thank you, Daigo.

That being said, when people start making games for your engine, you start to get more and more concerned about engine performance. For a while, I even considered ditching Ebiten’s minimalistic API entirely in the interest of better performance, but managed to pull through with just some clever new internal features instead. Things like an automated texture atlas and automated batches helped a lot. Essentially, these functions allowed me to improve performance by reducing the strain Ebiten itself put on the GPU via more compact commands, while leaving the API as is. On a more standard game engine, where ensuring everything always behaves as expected is paramount, this might have been a harder decision to make. But I managed to stick to my guns and maintain Ebiten’s core philosophy. I didn’t want to have to discard the engine’s artistry, no matter what.

Bear’s Restaurant

Daigo went on to make several other mobile games after Clock of Atonement, but they all were built upon the same foundation. He was kind enough to remain faithful to Ebiten, even when its inherent bugginess caused him an awful lot of grief. I really can’t thank him enough for that.

By far the most groundbreaking of these titles, however, was 2018’s Bear’s Restaurant. It was by all accounts an extremely powerful game, but it was also a huge critical and financial success, garnering over one million downloads worldwide and winning the Avex Award at the 2019 Google Play Indie Games Festival in Tokyo, where it placed among the Top 3 games of the previous year.

Daigo’s tweet when Bear’s Restaurant won the awards

Though for me, the really impressive thing was that all of the other games aside from Bear’s Restaurant that ranked in the Indie Games Festival’s Top 20 were created using pre-made engines like Unity and Unreal Engine. I consider it a great honor that a game made with my own self-built engine was able to achieve such incredible accolades.

And with the great success of Bear’s Restaurant, I was finally able to prove to myself that the answer to my original question — whether it were practically possible to build an entire 2D game with the most minimalistic API imaginable — was indeed a yes. Congratulations, Ebiten. You pulled it off.

Following this, Daigo went on to make his own game company — Odencat Inc. If you’d like to read more about his journey to success with Bear’s Restaurant, I highly recommend checking out his own article recounting the experience.

Other Ebiten Users

Odencat aren’t the only ones who use Ebiten for their games, however. OpenDiablo 2 is a full-on Diablo 2 remake project built in Ebiten. They’ve been using Ebiten in a lot of very ambitious ways that I never envisioned, and have given me a wide variety of feedback that I’ve been able to use for engine performance tuning purposes — something I’m always grateful for. There’s also a puzzle game called Give Up the Dupe by Jae, which is currently available on Steam, and an Android clicker-style game called Idle Armada created by Corfe83. You’ll also occasionally see Ebiten used by game jam participants as their engine of choice. I can’t tell you how happy it makes me anytime I see anyone using a game engine I created for anything.

Nintendo Switch

One concern I always had about making a game engine in Go was that it might make it pretty much impossible to ever port any Ebiten games to home consoles. Pretty much every game console manufacturer uses its own proprietary C/C++ compiler, after all, so obviously they couldn’t just read Go verbatim. It’s simply a risk associated with the language that I knowingly took.

But in early 2020, Daigo met up for lunch with one Daichi Saito (President of Why So Serious, Inc.), and they got to talking about this very issue. Mr. Saito’s suggestion was as follows: why not simply make Ebiten compatible with Unity? It was probably just an off-the-cuff suggestion, I imagine, but it got me thinking — sure, Ebiten was written in Go, but what if I could somehow convert it into C# or something? The Nintendo Switch did have built-in Unity support, after all — so if I could get my engine running in Unity, that would automatically increase the number of compatible Ebiten platforms by several orders of magnitude. Plus, greater established user base to take advantage of and whatnot. But in any case, things panned out a bit differently than that, and I ultimately gave up on the Unity idea and chose to convert the engine to C++ rather than C#, but I still give credit to Mr. Saito for the initial conversion idea. So thank you, Mr. Saito — even if you did show up pretty late to lunch that day.

EDIT (2022–01–03): Now I have succeeded in native-compiling for Nintendo Switch.

After running a few tests, I confirmed in late 2020 that porting to Nintendo switch should indeed be possible. Performance had been my biggest concern, but I was able to get Bear’s Restaurant running more than well enough on it, at least. There’s a lot I could say about the technical aspects that entered into this, but I think I’ll save that for another day.

In 2021, the Nintendo Switch version of Bear’s Restaurant was released worldwide.

Thanks to the same game that had already been Ebiten’s biggest success story, I was finally able to make my engine compatible with home consoles. I think that’s pretty damn impressive for something I built all on my own in my spare time. Even if I definitely couldn’t have done it without a whole lot of help.

In Conclusion

If you had asked me why I’d been so dedicated to developing the same game engine for so long, I probably wouldn’t have had a very good answer for you until somewhat recently. Perhaps I would have cracked a joke about game engine development being a basic human need for me, right up there with food, water, and oxygen, but obviously we all know that’s not a real answer. I think it’s simply an aesthetic pursuit, like I mentioned above — I wanted to prove that it was practically possible to make a 2D game with the most minimalistic API imaginable. It was this motivation, along with a whole lot of luck, that drove me to keep developing my own engine into the success story it is today. To everyone who’s played a part in helping me reach this point, I can’t thank you enough.

Though while I’d say Ebiten is now in a very much usable and accessible state, that doesn’t change the fact that it’s still very much a small, niche indie game engine, in terms of how many developers are actually using it. But I intend to do whatever I can to continue increasing that number from here on out. I can’t wait to see just how far this little engine might go — all while maintaining that perfect balance between consumability and artistic integrity.

License

Go Gopher by Renee French is licensed under the Creative Commons Attribution 3.0 License.