Our industry, as all other creative endeavors, thrive when collaborative teams iterate on each step of the process, plus-ing the outcomes as early Disney artists would call such process.
At the core of this continuous improvement is the prototype, an opportunity to visualize and test your ideas in the real world, and transforming your personal vision into a shared team goal.
We do it with our gameplay mechanics, our code, and our art. Perhaps that's the reason why business seem so arbitrary. You rarely seem to iterate, or prototype there. Could we transfer this practice to business? We may.
One of the exciting things of being a video game developer is that our industry develops at such a rapid pace, that we are constantly updating our techniques and skill sets; learning new things.
There's so much change, that every once in a while, for some of us, we switch platforms completely and get a fresh new start. That's been my case in the last couple of months, when I moved from developing for the XBox, into developing for the iOS.
On the technology side, besides the obvious hardware differences, my programming skills didn't require drastic adaptation between platforms. However, most of my adaptation was required in learning about the process of getting the game approved for sale, the way a user gets a hold of your game, how they provide feedback and other interactions, and others like that.
It isn't a technical challenge. The challenge comes from that dreaded word we programmers and our fellow artists flee from, but can't avoid if we want our games to reach the players: business.
When you talk about testing for business, the problem is that making it a real test requires real users that access your product through regular means.
You may put out a beta version for some people to acquire, but there's still a gap on the way things are different when users are buying the real thing. But to get a "real thing", you need to go for a gold master. A gold master prototype? In a way, that's what we did at my new company, Eosch.
The company itself was coming into iOS games for the first time. And as I said, we had experience on the technical and game design areas of the industry. But the iOS and its associated business implications were new for all.
While I can't currently go into details of the main project we are working on, we didn't want our first approval process to be for that game. Large resources are being put into it, and we wanted to minimize the risk of anything going wrong on the business side of the release, or even with the platform itself in a real world scenario, with real customers. That's how we came to the idea of prototyping it.
From such idea came Firebreather, the company's first release, which is smaller in scope, produced on a very tight schedule, but with quality standards that made us confident of bringing it to the market at the lowest price point (99 cents) instead of free. It certainly required us to put some resources aside from the production of the main game, but at the same time it allowed us to test all the implications of having a game selling on the App Store.
It certainly proved worth it. We learned of backward compatibility issues, answered requests from players on international markets, tried the different communication alternatives with users, and most important of all, we went through a full submission process.
And as a side benefit, we have an extra game in our portfolio, that even after hours of testing and iterating it on all other domains, we are still having fun playing, and love seeing the joy in our first paying players.
I would certainly recommend other studios to try similar schemes, where you try a game smaller in scope, but specific to the platform you are going for, and using game mechanics similar to those you're aiming for. This is particularly useful, when you have digital distribution platforms, that minimize the cost of bringing a finished game to the players. The business end can start iterating, as much as we iterate in the technical and artistic ends of our industry.