A Rationale

Unfortunately, I kind of got stuck trying to add sprite sheets to the Bitwise Editor. The problem being that the editor was designed to edit individual assets. This doesn’t work when considering sprite sheets, which is an asset that provides multiple assets. While I’m stuck, I’m taking the opportunity to add some automated tests to the editor. Hopefully that should improve the editor’s stability and make for more efficient development. So, while I’m in the middle of this refactor I thought I could discuss why I decided to build Bitwise and not use one of the half dozen game libraries that exist which do the exact thing.

I’ve been trying to develop games for a long time. One of my first serious attempts was in Java, but eventually I learned Flash and created a couple small games. With Adobe killing Flash, I tried learning Unity a few years ago. I was blown away at how well integrated the Unity editor was with the framework and how easy it was to add new game mechanics. The only problems are Unity is not open source, and it’s too resource-heavy for my current hardware.

With this most recent itch to develop video games, I decided to learn Phaser. It is a free, JavaScript game framework with an active community and lots of documentation. It’s pretty easy to get things done in Phaser, so I started two or three games and each time there came a point where it was harder to debug the game when having to go back-and-forth between my code editor and my browser. What I needed was some way to tweak tiny values in my game as it’s running so that I could properly fix the problem back in the code.

So I started looking for a Phaser editor. I vaguely remember that there was at least one out there, but the only one I could find was also closed-source. Complicating matters, Phaser 4 has been in development for a while now. And Phaser 4 is a complete rewrite of the library with a new architecture built on the entity component system design pattern (like Unity). In the end, I tried going with the Tiled map editor.

After putting some maps together I realized that the Tiled editor wasn’t quite what I was looking for: There were some rough edges that definitely needed polishing. I figured that with all the new, modern tools we have for building GUI applications that writing a new map editor might be a good way for me to stay interested in game development.

I’ve always gravitated towards building tools rather than building end-user applications. My GitHub profile is a monuments to that with at least three content management systems, some low level development libraries, and frankly dozens and dozens of conference presentations. The audience for my work has largely been other developers, so I thought that building a map editor would be relatively straightforward, wouldn’t be inventing too many new wheels, and would be a project that I could quickly bootstrap and then get back to developing my game. I decided to call my new map editor “Bitwise”.

No more than a couple weeks into development, I hit my first major design snag: How would objects be placed on a map? Tiled solves this with layers: You can have map layers and object layers. So, I thought I would do similar, and as I thought more and more about how I would organize objects and map layers, I started to realize that I was doing things very close to how Unity does things. It was at that point that I decided that since I’ve always been more comfortable developing in frameworks that I created and solving the interesting problems of those frameworks. Additionally, this way I could keep myself interested in making whatever thing my framework was meant to make, like a blog or a website.

So, I started researching the state of WebGL libraries and other game development necessities and I realized that there was a lot of base here to build out. ThreeJS is itself practically a game development library (though, they are careful to mention that they do not handle game specific things like physics). But, there are also physics libraries for JavaScript and eventually I went with Ammo.JS. Finally, to continue borrowing from Unity, I decided I would use an entity-component-system framework and decided that I would use the same one as Phaser 4 (my unstated goal being that when Phaser 4 is released I may be able to port my editor over to it pretty easily).

That was late Fall of 2022. Since then, development has been fairly rapid. But, importantly, I have so far been able to keep interested despite some significant complications like the multiple copies of Ammo.JS that exist on NPM and an impressive number of issues struggling with the TypeScript/JavaScript build tool chain mostly involving Ammo.JS and it’s static variables.

My goals for the bitwise project are to build a flexible base on which developers can build both their game and their game development tools. I imagine a game developer building a plug-in to manage playing card deck art assets, for example, or building a tool for narrative design that lives inside the Bitwise editor. But, for all that to happen I still have to get some basic features like sound, sprite sheets, tile maps, and animations.

At the moment, Bitwise is still very, very early in its development. However, I have made a fully functional (if silent) Solitaire game, and I started building out a top down shooter to demonstrate the physics library. For the next big features (tile maps) I’ve decided to build a Sokoban game, and I plan a few other example games to ship with Bitwise as demonstration of its features.

So, for the next few weeks I intend to continue my slight rework of some of Bitwise editor’s internals, but then I hope to get back to pushing forward with new features!