We were highly intrigued by the fact that Retromite spans the entire Atlantic, with Gregg programming here in the US and Kawe whipping up art in Germany. How did the two of you meet up and decide to create Retromite, and what unique challenges does a development team face when they’re spread so far apart?
Kawe: I think I was working in Montreal at the time. I was looking for some fast cash for a trip, and Gregg was looking for an artist. That’s the start of a modern friendship for you. Retromite only recently came to life because we needed some sort of label to stick on what we’re doing. The biggest challenge is the time, really. Gregg usually wakes up one to two hours before I go to bed and vice-versa. So a lot of what we’re doing needs to be written down, tracked and followed up.
Gregg: The other big challenge would simply be communication; sometimes it’s just worlds easier to explain something in person. I’ve run into situations where I’m trying to re-create some animation, for instance, and it’s just not clicking. Kawe is explaining it, but it’s still not really making sense right away, whereas if we were physically present, I’m sure he could have simply shown it to me and it would have made sense right away.
Gregg: I started out doing a lot of work in the game emulation scene, working on custom Ultima Online servers and so forth, but my first real commercial experience in the videogame industry was bootstrapping Centurion Games, and releasing a number of titles. Before and during this time I actually worked in the semiconductor industry, doing mostly custom software tools for CPU validation, and emulation models. With the creation of Retromite, however, I’ve left behind the mega corporations per se, and am completely dedicated to building and expanding Retromite.
Kawe: I made my first game in ’86, and was working with companies such as: Gameloft, EA and Glu in roles like Senior- and Lead-Artist. I like games but have doubts when it comes to the industry.
How did the team end up deciding on a 90s-style, 2D platformer as Retromite’s first project? Was this only one of several ideas being kicked around at first, or were both of you pretty much on the same wavelength from the beginning when it came to game design?
Kawe: I actually think that the constant overflow of ideas was one of the biggest challenges we had to face during prototyping as well as development. With this in mind, RobotRiot was our first “real” game, as in, we were spending more than one week on it without hopping to another fun-prototype to fool around with. Also: I’m almost 40 now, so me being into 80s/90s-style retro gaming is pretty much the “Mommy/Granny listening to Motown Chartbusters” over and again. Cool thing if you ask me.
Gregg: I grew up in the 8-bit/16-bit/arcade scene for the most part when it came to gaming, and so this has certainly stuck with me. So even today, I tend to favor 2D games that have an emphasis on gameplay and challenge, instead of the approach that most modern games take.
Speaking about RobotRiot directly, during the planning stage I had thrown together a design doc for a samurai style platformer, but it didn’t really click at the time, and Kawe said something about Robots. So I threw down a few lines of text, and RobotRiot was born. It then continued to grow kind of organically until the end of production.
We know of at least two platforms you’re planning to tackle with RobotRiot, with an Xbox 360 release planned in addition to iOS. Did you have a multiplatform release in mind from the very beginning, and was that a deciding factor in the programming language(s) you chose for building the game?
Kawe: Cross-platform works more or less for any game. We’ll see how that goes, but there’s certainly good fun and some cash when it comes to publishing a game on more than one platform.
Gregg: Absolutely, most everything we are planning is geared towards multi-platform. As for programming language consideration, it does factor into that a great deal. For instance, I code iOS projects mostly in straight C/C++ while avoiding Apple’s Objective-C, as it basically doesn’t port anywhere outside the Mac environment. Usually though, it’s about minimizing platform-specific technology or libraries. For instance, I don’t use Apple’s powerful UIKit and GUI capabilities, and instead choose to do most things from scratch via OpenGL, as the OpenGL version is cross platform, and can also be adapted to DirectX and so forth easily.
Gregg: Three main tools really stood out for the most part, while realistically, I’ve probably made six or seven that get used frequently as part of our development pipeline. The big ones are “Loki,” our custom level editing tool, “Odin,” our sprite animation tool, and “Baldur,” our bitmap font tool.
Advantage wise, it all really just depends. If it’s a closed source tool, then if you need a feature you’re at the mercy of the makers of the tool. If it’s open source, or you get the source along with purchasing the tool, then you have more freedom, but of course you then need to invest time learning someone else’s potentially large code base, and discovering any inherit design limitations that may prevent you from adding the expanded functionality you want.
In the case of Loki, the feature set went far beyond what you find in most available tile editors, and instead had a ton of entity support as well. All of those traps, conveyor belts and so forth are actually completely configured in Loki, and can be previewed in the editor, allowing quick adjustments. With Odin and Baldur, there just weren’t any suitable alternatives that we could find. Kawe had worked with similar tools at Glu and Gameloft that were pretty big keystones in their production flow, and these tools just don’t exist out in the public, so I made them from scratch.