|
5. Reward system created issues with player expectations
At the end of every battle, the player has a chance to win a number of rewards ranging from in-game currency (gold), XP, and gear. In the current spread, currencies are common and gear is a little more sporadic.
Defeating enemies and getting a random reward sounds like standard RPG fare, right? To make things a little more interesting for players, we decided to present them with possible rewards. Players can make their pick, get their reward and ogle the remaining randomly populated rewards as well. The idea was to compel players to do the mission again once they realized what the other rewards were. We felt this added extra pizzazz to an otherwise boring rewards screen while detailing the different kinds of loot available to players.
It did add pizzazz, but it also added frustration!
Though players can win more than three items, showing three choices inherently implies that the players' chances are equal for the items themselves, whether gold or gear. In the end, showing a player what they could have won made the game frustrating even though it followed the same rules probability-wise as the winning reward. As a result, almost every negative review we received mentioned the reward mechanic. Correlation isn't necessarily causation, but it was obviously a major issue.
Had we used a simpler interface to communicate what other items the player could have won, this wouldn't be an issue. It would also have made the game easier to develop.
We've recently revised how the system displays rewards and dramatically changed the odds of winning "nicer" items. This has reduced a lot of the negative feedback on the reward mechanic. We'll continue to keep an eye on it and may completely revisit this gameplay mechanic at a later date.
What's Next for Appy
More and more iOS gamers download Animal Legends every day. We will continue improving the game based on player feedback, like we do with all Appy titles. Since launching Animal Legends we've added one new hero and five new monsters to fight. Our next patch will include more content and a player vs. player mode that allows players to fight with their heroes against others!
The lessons we've learned from Animal Legends and the tech that we've built will also apply directly to our next yet-unannounced-game, which is now in preproduction.
Data Box
Developer and publisher: Appy Entertainment
Release Date: 11/14/2012
Number of developers: 7
Length of Development: 7 months
Platforms: iOS universal app for iPad and iPhone/iPod touch
Development Tools: AppyEngine (Proprietary), Versions, Objective C, Ruby on Rails, Motion, Photoshop, AppCooker, Xcode
|
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.