A Brief History of Geoid

Marble Blast is a fantastic series. I have great memories of playing Marble Blast Gold as a kid, and Marble Blast Ultra on the 360 was a surprisingly good party game. However, due to the Marble Blast series being stuck in some kind of intellectual property quagmire, it has not been available for sale anywhere since 2011 (not unlike the reason why the Chip’s Challenge sequel sat unpublished from 1991 until 2015).

While there have been some fan attempts to inject some new life into Marble Blast, these attempts have been flawed for a few reasons: first, they’re very focused on punishingly difficult gameplay, and second, they’re using the Marble Blast name and engine. This combination unfortunately means that only a very small niche group of people will ever play them.

In 2013, I decided to fix this situation. I set out to re-imagine a rolling ball game that does things a bit differently. I wanted to avoid overused power-ups like ones that just make the ball roll faster, or ones that just make you jump really high. Instead, I wanted power-ups that change the flow of time, or let the player select a new, arbitrary gravity direction by touching an angled surface. And most importantly, I wanted a game that was infinitely moddable, particularly for player-designed levels, but also for player-designed new game mechanics.

There was really only one indie-friendly game engine that would work well for a rolling ball game back in 2013 however, and that was Unity. However, the free version of Unity looks like your average 3D game from 2002, and they had only recently allowed indie developers access to real-time shadows (well, real-time shadows from exactly one directional light, but still, it was better than nothing). From August 2013 until April 2014 I developed the game in Unity. I had a lot of serious issues with Unity, not the least of which is that I would need to implement a full level editor and scripting environment myself to provide modders with the tools they need (which is essentially what the Cities: Skylines folks had to do). I already had a prototype level editor that used IronPython for scripting game mechanics, but making it rock-solid with a good UI would be very time-consuming.

In March 2014, Epic released Unreal Engine 4, with a surprisingly affordable pricing structure (which they’ve since made just a royalty instead of a royalty and a monthly fee). I had been trying to figure out what to do with Unity, as the pro version was priced way beyond what I could afford, and my hope was that with Epic charging way less for Unreal, it would cause Unity’s pricing to drop to a reasonable level. I waited about six weeks to see if Unity would respond to their new competition, then gave up and began porting all of my assets to Unreal Engine. This was a real challenge, not the least of which because in the beginning there was a lack of good documentation and forum posts, and honestly, the initial Unreal Engine 4 release was a bit rough around the edges. I also had to learn C++, which isn’t the simplest of languages. But all of a sudden I had access to a triple-A lighting and shading system, built-in multiplayer net-code that actually works, and a way to provide a level editor to players without writing my own from scratch.

It took months to get the game stable in Unreal, but once it was, development time returned to normal, and I was able to return to working on new content. If I’ve learned anything from the process of building a game from scratch, it’s that I really appreciate how lucky modders have it that all the base mechanics are stable when they’re messing with stuff. When you’re developing from scratch, early on in the process there’s always something broken that blocks you from figuring out if something will be fun or not.