Monaco's Schatz: 'Do Your Due Diligence' Before Porting Your Game

Choosing someone to port a game can be like choosing a nanny for a child. The original developer should have expectations of trust and proper "social conditioning" to ensure the port achieves a healthy maturity. Andy Schatz of Pocketwatch Games had to face such choices when deciding to take 2010 IGF Grand Prize winner Monaco multiplatform. The game was originally created in Microsoft XNA, limiting it to an Xbox 360 and Windows PC release. But Schatz felt it was important to be able to launch on Mac and PC simultaneously. And while Schatz didn't announce any console distribution deals this week, he said he definitely didn't want to wait until Monaco was finished before configuring the game for multiple platforms. Having realized his skills and interests are more in writing algorithms and implementing game design, Schatz decided to find someone he could trust to handle the port of a game that got him out of a "huge rut" and into the spirit of making games a life-long commitment. Family and friends are traditionally a great place to look for help, and Empty Clip Studios' Francois Bertrand and Matt Shores are not only friends with Schatz, they also live in the same city. The trio frequently got together and supported each other when times got rough, so the trust was there. The developers were also well-enough acquainted to have identified complementary skills and interests in each other, and Empty Clip's Rapid Fire Engine offered the ability to easily port Monaco to every platform. Now that Schatz has found someone he could trust to do well-conditioned ports of Monaco, he says he has time to focus on other things. And even though Schatz says there is no new time frame for Monaco's release, he expresses in the following Gamasutra interview what this free time and flexibility allows, including a possible tablet port. The two developer teams also delve into what led up to porting, what challenges they face, and how they and the Rapid Fire Engine will overcome them. What made you decide to outsource the porting of Monaco? Andy Schatz: Once I decided not to launch the game on [Xbox Live Indie Games] there was really no question. There's really no excuse for not releasing the game on Mac these days. The game was originally built in XNA, which is fantastic for doing quick prototypes of unique concepts, but it's shit in terms of target platforms. The Xbox Indie Games marketplace is an option, of course, but the "high-def" version of XNA (the one with shaders) only runs on fairly high end PCs, so it's really only good for making Xbox games. How is outsourcing helping you now? What's left to do? AS: The Empty Clip guys are finished with a first pass on the porting of the gameplay. That means that the gameplay graphics and most of the actual gameplay features have been implemented in the Rapid Fire Engine, which runs in native C++ and across all major platforms. The UI, sound effects, and networking aren't done yet, and they are going to have to re-port all the changes I've made in the last few months as well. I like my job better. Thank the Earth Mother for Empty Clip. What considerations should be made when deciding to have someone else port your game? AS: Do your due diligence before diving in on a port. The worst thing that could happen to you is if you get halfway through a port before you find out that the new engine doesn't support a feature you previously relied upon. I encountered problems like this even when upgrading my version of XNA (when they went from v3 to v4, they created a more strict and less flexible set of system requirements that meant that many older machines could no longer run the game). This is why I shied away from Unity, as well. I feared that because it's a closed system that I might run into a performance or feature limitation that was simply immovable. What unique challenges or opportunities are there in working with another studio while the game is being developed? AS: Well, we actually haven't yet had to deal with the really serious challenges: at the moment, I just throw code over the wall and the Empty Clip guys handle it (they are awesome). Their first port took a little over two months, during which time I continued to work in XNA. Now they are working on porting those changes. We're gonna keep iterating until they've caught up to me, and then I'm going to switch development over to the Rapid Fire Engine. When we get there, I suspect it will get a bit messier. How does the Rapid Fire Engine prevent any loss of fidelity when porting across platforms? Matt Shores: The Rapid Fire Engine has a number of mechanisms for this. First, on the asset side, you can let the system automatically down-res any assets you have at a "higher" quality. This is the case all assets such as audio, textures, models, etc. If you want to customize any asset on a per platform basis, our tools have this kind of "knowledge" built into them (along with localization). Hence, you can pick and choose what you want to customize on a per-platform basis or just let the system do this for you. On the engine side, we understand that platforms have a wide range of capabilities, however, we have made it so that you can customize modules (such as the rendering module) on a per game basis, per platform basis or per game and platform basis. This allows the greatest amount of freedom yet keeps all of the cross-platform code intact. What are some the drawbacks and advantages to porting a complete versus incomplete game? MS: A completed title has the advantage of being in a frozen or static state. This allows us to make better architectural decisions knowing that the code base and assets will not change. It also provides a nice way to ensure that the port is 100 percent faithful to the original. A drawback can arise if there are complications on a new platform (i.e. a visual feature that needs to be scaled back resulting in a difference from the original) or if a required input change results in poor control of the game (i.e. porting from an Xbox 360 controller input to the iPad). However, these can be easily mitigated and are usually a known quantity from the beginning. When it comes to an incomplete title there different advantages and disadvantages. One advantage is that your port architecture may have a greater influence with the title while it is being actively developed. Assuming that we are working closely with the developer, the base game can take into account a number of issues that might not come up when a title is initially being produced. For example, not only are screen resolutions different on the various platforms, but aspect ratios vary quite a bit, audio hardware and output capabilities are diverse and even simple aspects like save game or DLC tend to have differing implementations per platform. The one disadvantage is the "moving target" concept. You are always playing catch-up with the current code base. With Monaco, we have a pipeline in place to handle these differences and port over the latest code and asset drops. What role did the Indie Fund play in approving the port and/or finding you someone to port Monaco? AS: Indie Fund certainly gave me the financial flexibility to tackle this now, rather than when the game came out, but Empty Clip also has a stake in the game as well, so I'm actually trying to minimize Indie Fund's risk here. How do you free up the time for the developer in porting games? What questions do you still have to ask the developer even when porting a project? MS: Take Monaco as an example. Andy doesn't want to have to spin his wheels sorting out the differences between the various hardware platforms. Monaco is best served when Andy and Pocketwatch Games are focusing on the gameplay. What makes this so cool is that our engine is set up to facilitate what most projects end up doing at the end (or worse, having to bring on additional resources that were not planned from the beginning to solve these problems). Monaco running on one platform runs on all of them with our engine. We provide the layer that integrates all of the changes from his original code-base. Essentially, Andy can just rely on us to make sure Monaco is delivered to the platforms he desires and it will "just work" without him having to spend any cycles worrying about it. Could Monaco be tablet-friendly? AS: Absolutely! I hope to eventually create a tablet-friendly version of the game. That won't be at launch, but it's absolutely possible with the new engine! I'd love to have another use for my iPad other than Reddit and pictures of cats.