Skeleton Crew: How We Chose Bones

With so many game engines available, how did K-tech studio come to the point of making Bones game engine, and why has it become the engine of choice for the Skeleton Crew project? Today we have a podcast discussion between myself (Harsulin), lead artist at K-tech studio, and Latency, the programming lead for the Skeleton Crew games including the recent beta release of Striker Ball. Over the course of an hour we do a thorough overview of the long journey that lead us to Bones and why we chose it to develop our games in.

We hope you enjoy the podcast, but here we also include a summary of what we discussed if you want to read the shorter story.

When we started out in game dev we were actually very resistant to the idea of making our own engine. We didn't want to take that on, so like most people we started by looking into the most popular commercial engines available, such as Unreal and Unity. So why didn't they work out? One of the most prevalent reasons was that we were not ready to pay for software early on when we were still unsure of our own game dev ability. The complexity of these engines was also daunting, and K-tech studio had an interest in making moddable games, something that commercial game engines were not typically well suited for. Our love of modding came from our enjoyment modding the original Star Wars Battlefront II. Our requirements became an engine that was free, relatively simple, and had modding support. This lead us to the open source community for a solution.

As the hunt for an open source engine ensued, there was always two streams of thought involved. The larger K-tech studio goals were headed up by Zicklag, the primary developer of Bones. He was invested in finding the engine that we could grow into and expect to handle the larger scale games we wanted to be able to make in the future. However, myself and Latency were at the same time scaling back some of our expectations in order to just make something simple. We chose to make an Asteroids clone and used this as the test of the various open source game engines we encountered. Here we will try to focus primarily on our evaluations for small scale use.

What we found was that each engine we tried tended to have one of three basic issues or a combination of the three. These problems were:

• Over Complication: Some engines were too hard to get into and difficult for our small team to develop on.
• Feature Deficiency: Some engines didn't have important features that were necessary for games we knew we wanted to make.
• Performance concerns: Some engines had performance problems when running certain processes.

Before we get into all the reasons that we didn't use several engines, I want to preface by saying we are not here just to bash on other open source engines. While these engines didn't work out for our goals, some of them have had finished games made on them and may be good options for other developers. We learned something new from each engine we have used and appreciate the opportunities that they offer the community. But we are here to explain why we eventually chose Bones over the available alternatives.

Godot

Godot was one of the earliest open source engines we used. At the time we had trouble using it's visual programming system and we discovered some significant performance concerns. In another developer group's game called Ringed, we found it became slow when running very many entities that required basic path-finding. This led to concerns for putting development time into the the engine if it would not be suitable for future projects, even small scale ones.

Armory

Armory had a promising visual programming system and Zicklag became quite well acquainted with this engine. Latency and I made our first Asteroids clone in this engine, which although basic, was fun to play. Unfortunately Armory didn't have game-pad support, as well as other small but important features. Eventually the engine's creator mostly ceased development after finding greater overall interest in one of his other tools.

G-Develop

G-Develop is a small scale engine that has visual programming and was quite easy to develop with. We made our second Asteroids clone in this game pretty quickly. It had some performance limitations though, and we were concerned about organizing a larger amount of data for a game in G-Develop.

Amethyst

Amethyst was mostly in it's decline by the time we came across it and lacked enough developers to maintain the engine. However, it was the first game engine we had found written in Rust and the time spent interacting with Amethyst helped confirm Rust as our preferred programming language.

Bevy

Bevy was in many ways the spiritual successor of Amethyst and had the advantage of being headed up by a talented developer who secured enough funding to work on the project full time. We felt that Bevy could become for open source game engines what Blender had become for open source modeling software. It was however larger scale and more difficult for us to work in during an effort to make a small top-down shooter.

Enter Bones Game Engine

Bones was developed as the result of a collaboration between Zicklag and the Spicy Lobster game dev group. Spicy Lobster was making a Duck Game clone called Jumpy, and they wanted both modding and network multiplayer capability. Originally Zicklag attempted re-writing Jumpy in Bevy, but modding and network play didn't end up being an easy add to Bevy. The result was the decision to write an engine from scratch that would meet these requirements while being as simple as possible; this was Bones.

Latency had taken a break from developing on Bevy for a little while, but by the time he came back, Bones had become an option. We found Bones to be much more feasible to get a handle on because it was written with relatively little code for what it was accomplishing. In the past we have struggled to avoid roadblocks using other engines, but even when it has taken some work, we have yet to encounter an obstacle we could not resolve in Bones. Development has maintained a slow but confident pace. It does also help us to have Zicklag, the designer of Bones, available for support!

On that note we would also like to point out where Bones still needs some work. It's relative simplicity is great, but it is also very raw at this stage. Without certain structures and conveniences in place it isn't an engine that we would suggest to beginners quite yet. It also isn't ready for making large scale triple-A titles at this point. For example, currently it only does 2-D rendering and we have only set it up with simple physics so far. However the design model of Bones was structured to make it very extensible. We can expect to be able to add new functionality to Bones incrementally without having to re-write large pieces of the engine in order to do it. We feel we have started by doing the "first things first" without limiting the engines ability to expand.

Part of the intention of the Skeleton Crew project is to make games that we think will be popular categories among game makers so that there are good examples to base a game off of. By making small games of different types we can prove out Bones' ability to make those games and iron out any issues that we run into along the way. Top down or side scrolling, turn based strategy or platformer, we want Bones to be capable of making a large variety games. This project will continue driving improvements to Bones, making it easier to develop with and more capable.

I'd like to finish by summarizing where we think Bones is at today. The biggest advantage seems to be that it is small scale enough to wrap your head around, while still being very capable. It also offers a couple really neat features that are hard to find in open source engines; live modding and network multiplayer. However, at this time Bones is still raw and has some feature limitations, such as only doing 2-D. We are very excited to keep pushing forward with improvements to Bones as well as new games made with our engine.

Thanks for reading, we hope you enjoyed learning about how we choose Bones for the Skeleton Crew project. See you next time!

Written by, Harsulin: Lead Artist at K-Tech Studio