|
4. High production values
By mitigating the risks above, we were able to block out all of our planned characters and all of their gear. While this meant artists were very tightly constrained to sizes that they could not deviate from, it also meant that they had a sandbox where they could play to their heart's content.
After having given the tech behind assembling characters such a fair shake we had a pretty good idea of what the system was capable of and what assets would work -- and which wouldn't. As a result, assets that we created in-house or through outsourcing were almost entirely plug-and-play, which saved us a good amount of debug time.
But the greatest advantage was that the artists could really iterate on the heroes and the gear without worrying about the work getting lost due to technical changes. As a result, the heroes are incredibly unique and sport all kinds of crazy animations. By constraining our art team, we actually empowered them to iterate without fear of change.
5. Planning past the future
We knew we would want to launch a large series of content right after launch and we planned out our features for a 1.1 and 1.2 as part of the initial feature set. This meant that as our artists were creating assets for buildings, they were actually creating about 20 percent more than the 1.0 requirements for every type of asset (such as heroes, gear, monsters and buildings).
Doing art assets this way had a similar effect to shooting multiple movies at the same time. The tone on everything was fairly universal. Additionally, things were a little bit faster to make as artists were producing these assets while they were "in their groove" and not re-learning a pipeline to do one or two assets. When you are talking about assets which take one or two days to make, a half day re-learning process is a dramatic increase in time.
A large number of our content (buildings, heroes, monsters and backgrounds) was all ready to go for a Halloween update, a Holiday update and then a major update for 1.1 which added a few new features such as being able to train your heroes and make use of the extra gear you had lying about.
Having this content ready to go right after launch led to a very smooth update path, which helped the app gain lasting appeal and resulted in a healthy number of post-launch downloads.
|
Printer-Friendly Version
I wouldn't see a project or a market for it, as scary, personally. I'd look at it as challenges to overcome, whether technical, aesthetic or business related. If you're prepared for those challenges and honest with yourself and your team about what you can tackle or cannot, it's pretty darn satisfying. Then you can come back and share with us the challenges you faced and the approaches you took.
Best of luck!
Great postmortem BTW!
We export the key data from Motion and have an animation player that replicates the animation curves. It's almost entirely what you see is what you get, with very few landmines.
The result is a pretty dramatic improvement over most of the options in 2d, we like it a heck of a lot more than Flash - that's for sure!
Regarding plists, these were mostly variables which were on the player or deep seated global variables that get initialized immediately upon launching. Though the patch would certainly get downloaded and applied, it would be too late and the player data would be initialized. Unless these variables were referenced multiple times (And they weren't) then the data was immediately out of date. These were entirely our own structuring problems which we were able to fix.
An example of was the leveling curve on the player [How much experience it takes to level, per tier]. This data got initialized first thing, as it was a part of the core player data, was read once by the app and by the time checking for a patch or data change was done the level data was applied and set in stone. A simple fix was adding a second check further on in initialization to double check the patch for data of this type - but it did require us to wait on the resubmit.