Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Appy Entertainment's Animal Legends
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Postmortem: Appy Entertainment's Animal Legends

May 6, 2013 Article Start Page 1 of 5 Next

Animal Legends is the newest game from Appy Entertainment -- an independent developer out of Carlsbad, California. We're the developers behind Trucks & Skulls NITRO, FaceFighter Ultimate, and SpellCraft: School of Magic. Our motto is, "Deadly Serious About Stupid Fun."

Appy's games have been downloaded more than 22 million times and Apple has featured all our titles. With Animal Legends, we wanted to build on 2011's SpellCraft to create a game where players can command archetypal fantasy heroes on dangerous quests for loot and glory -- while still fitting Appy's well-known goal of making fast-playing, humorous games with broad appeal.

With SpellCraft, we added an asymmetric multiplayer mode that taught us a lot about developing multiplayer games on iOS. Animal Legends, with its asymmetric "borrowing of heroes" was a natural next step.

The development of Animal Legends lasted roughly seven months. The game was built by seven internal developers and a few external contractors (such as Quinn Dunki of One Girl, One Laptop Productions.) We launched in November 2012, worldwide. Animal Legends was our second free-to-play game.

What Went Right 

1. Extensive iteration in mockup stage

The App Store has an unbelievable number of games and apps -- but buried within all that software are apps that can help you make even more apps! 

AppCooker was our secret weapon in Animal Legends and it was used extensively in the early mockups of the game. For an iPad app, AppCooker is on the expensive side, but one very powerful tool is worth every penny: an iPad-native prototyping platform that allows developers to create flow between UI screens. 

Developers can import images from an iPad and/or Dropbox, add them to a screen, adjust them, turn them into a button and then begin linking to other screens. The next step is to "play" the mockup to experience it as a full-screen app. Once happy with your prototype, AppCooker allows you to export these screens in multiple formats, the most useful of which is a free version of the product called AppTaster, which allows you to send AppCooker versions to whoever you like. 

In roughly two days we completed a full first draft mockup of all the UI screens in the game and we were able to hand it over to someone and observe whether they were getting stuck or lost. This meant we could focus-test the UI without spending a single hour of programmer time. The ability to mockup an app as a webpage is one thing... Creating a mockup that runs on the target device at the proper resolution is a whole new game. 

The final version of Animal Legends was extremely close to our early mockup, saving us a huge amount of time on UI iteration. It's really hard to describe the vast difference between showing someone a UI flow on the device versus describing it to them. 

We will be using AppCooker in all of our designs for iOS moving forward. 

Left: Mockup, Right: Final

2. Online components 

In the past couple of months, we heard of a number of small studios who were forced to pull their apps due to skyrocketing server costs. This had us a little worried since the core of Animal Legends -- being able to borrow and lend heroes to friends -- meant heavy interaction with social networks and an always connected setup. It was easy to do a "back of a napkin" estimate on what the costs would be -- our main concern was bottlenecks on the server, unprecedented hits which would cause the number of instances to spin up dramatically.

In Animal Legends, players can freely borrow heroes for adventuring from other players. Once the hero is used on a quest, that hero is sent back with a reward. This meant that players would need to register their social binding, see other players who are connected to their Facebook/Game Center accounts, pull down that player's data, pull down their hero's data, and then finally handle the various interactions of using that hero and sending a reward back to the player. This was a lot of data moving around for a mobile app. On top of that, combat was core to the main loop of the game and it needed to be accessible in three- to five-minute chunks -- that meant we had to pre-cache a lot of this data.

One of the best ways to be surprised in development is to hand a system over to hundreds of thousands of people to bang on it for man-years in a single day. When that system can cost you a substantial amount of cash, surprises can be deadly 

Article Start Page 1 of 5 Next

Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States

Server Programmer
Giant Sparrow
Giant Sparrow — Playa Vista, California, United States

Junior 3D Artist


Alex Schearer
profile image
Thanks for this great post mortem. It's a bit scary reading about the struggles a studio such as yours goes through knowing that for my own games I will be even less prepared, knowledgeable, etc. Best of luck on your next title!

Rory McGuire
profile image
Absolutely, glad you enjoyed it!

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!

Remy Trolong
profile image
Thanks for the time you took writing this great post mortem! Honesty (Cr*p, I've the song in mind now T_T) is really important for moving forward, that's nice to read and learn from others' experiences. Best of luck!

Mark Nelson
profile image
I'm curious about the character animation for the game seeing as how you're using Motion. Did you export animation key data from Motion, or PNG image data? I'm not a Motion user, but it appears to make for a great sprite animation tool!

Great postmortem BTW!

Rory McGuire
profile image
Thanks, Mark!

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!

Sean Kauppinen
profile image
Excellent Post-Mortem! I have to say Yodo1 is who we work with on almost every mobile game when it comes to China. They are the best partner there. Also, thanks for the info on the plist updates, that's something we often recommend so you can tune economy in real-time, but also hadn't run into a testing issue there. I would love to ask, what were the specific issues with the three bugs? Was there a string that reset the update later in the code as it ran? Thanks again Appy!

Rory McGuire
profile image
Thanks Sean! Yeah, Yodo1 has been remarkable to work with. Excellent guides through the trying and often confusing Chinese market.

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.