Developers across the globe may lay their heads down on their pillows at night dreaming of a featured spot on Apple's App Store, but according to one studio, such a promo push may not be all it's cracked up to be.
Grand Cru's CTO Maikko Wilkman has taken to the firm's blog to stress the importance of marketing a developer has direct control over, claiming that an early featuring by Apple may do more harm than good if parts of the game aren't yet up to scratch.
Wilkman claims a “significant portion of new potential players” can be lost “if the game becomes unresponsive or at worst doesn't accept new users at all."
Not so super start
"This is particularly true for Supernauts as our concurrent multiplayer features and social aspects of the game make it quite a bit more heavy on the server side than many other, more single player oriented games," said Wilkman of the firm's big release.
"Database scalability is something we've kept in mind from day one of Supernauts development. We wanted to set up a database that is flexible for developers and enables fast production updates".
"The database had to support sharding out of the box and also be reliable as we are providing a service for users who are investing their time and money on the game."
Choosing the most reliable database system is crucial, then. Grand Cru opted for MongoDB, which offered vital features straight "out of the box."
"We investigated a lot of different systems and ended up choosing MongoDB as it provides sharding and replica sets out of the box. It has a handy document model that lets us do the server to database communication without any additional object-relational mapping layers in between."
Options open
There's no harm in using different specialist tools in your backend to ensure everything runs as smoothly as possible, Wilkman also argues. For this reason, Grand Cru opted to use the tool Redis in areas where MongoDB was less-than optimal.
The most critical part to test is the login flow of a new user.Maikko Wilkman
"MongoDB isn't always optimal for all purposes," added Wilkman. "For more temporary data and service to service messaging we're using a wonderful tool called Redis. We use it mainly as a server index to figure out in which servers each world is running in, but also to store temporary listings like high score lists or user online status.
"The killer feature for us in Redis is it's pub/sub (publish and subscribe) system that allows fast messaging between different services. This is critical for features like team chat where team members might not sit on the same server at the same time."
Estimating initial traffic is another fundamental part of pre-launch, and can be difficult to assume with any accuracy. It's best to over-estimate, then, so that you can better avoid "surprises".
Smooth sailing?
"For launch we're doing our best to over estimate initial traffic and to guarantee there's some headroom on the database for surprises - there's always surprises," he detailed.
"We can always scale the database cluster down once we know the real volumes of players but it's better to worry about this later on than to spend the launch week scaling services up under load."
Estimating isn't enough, though. Extensive load tests must be ran to ensure your servers can handle the capacity, as well as isolate potential issues which can be the difference between a smooth launch and a disaster.
"We've estimated beyond our wildest dreams the number of potential new users trying to enter the game directly at launch and ran tests to make sure these are the volumes we can handle," he continues.
"The most critical part to test is the login flow of a new user: this is one of the heaviest operations that happen on the backend as we need to set up all the data structures for a full player. Later in the game we can just do small updates to this data.
"During load testing we've caught multiple issues that would have wreaked havoc at launch if not discovered beforehand."
Despite covering all of the bases, assuming that your launch will be smooth sailing is "ridiculously stupid." To better prepare yourself for the worst it's best to have all key tools in place and ready to go.
"If the assumption is that anything can go wrong, then you simply need to be prepared for everything. All the backend components need to have high enough log levels on to make sure we see what's going on."
