Overview of my work on Castleville Legends



This is an overview of my work on Castleville Legends. Castleville Legends is a Zynga mobile game where players harvest crops, craft items, and send heroes on quest and adventures. The player also manages a gameboard (the kingdom) and places buildings and decorations on it. Castleville was already live when I was brought on, my main focus was working with the Design Team (Design) to create story driven events for DLC releases.



The whole team usually had about 2 months to deliver the content. This meant we had 6 weeks of design and implementation and 2 weeks of play test, QA, and bug fixes. The design team would either be given a theme for the event or decide on a theme. Some themes were very focused such as Christmas and Halloween, while others were more general giving Design more creative freedom with what we wanted to do.

Planning


Designers would work together to plan out the whole event. Once the overall story and quest structure was established, any new art assets and functionality needed would be conveyed to the art and dev team. All disciplines would meet for costing and if everything could be done in that release cycle, we went ahead with the planned event.



Implementation


Design created the game assets, quest, and objectives, as well as the rewards (loot). After implementation, the functionality of each system would be tested. Once all systems worked correctly, designers would play test the whole event.

The new items would follow a crafting map which detailed what was required to craft them, the building time, the drop rate percentage (if it was a chance item), and many other parameters.



The gameboard assets ranged from decorations and buildings to the whole event center. How each asset type functioned had to be defined and items that spawned from them had to be listed. If it was a building that could be changed over time, the trigger for each state had to be specified. These assets allowed the players to be immersed in the game because their actions changed the state of the buildings.

The quests were the last things to be implemented. The story would be established in quest dialog boxes. Each story had multiple quests and each quest had multiple objectives. Quest givers would present the objectives through dialogue. Each objective was listed and clearly defined in the quest log. Requirements for completion of quest objectives were tuned and balanced for accessibility. By running through the complete story structure, a designer would be able to test all components and functionalities of the event.



Player Experience


After the content was implemented, Design would play through the whole event and fix bugs in parallel. By playing the whole event over and over, the numbers would be adjusted for a better player experience.



Crafting maps for items would be evaluated. All the required crafting components, the number of times the player would have to craft specific items, and how much time the players would spend doing these activities were aspects Design examined.

Progression through the quest was examined: how much experience the player gained for each quest, and how each quest was unlocked (through quest chains or time gated) were details designers balanced out.

After items and quests felt balanced, Design would look at the event as a whole: the overall length of the event and how much the player was able to rank up during the event.



The Leaderboard was a major system designers had to take into account. This mode of play allowed players to compete against each other for better prizes based on ranking and tier grouping. Dealing with players who obtained the event currency too quickly, cheaters, and other exploits were issues designers had to tackle with each event.



Conclusion




That is my overview of the work I did on Castleville Legends. I hope it was informative, if somewhat lengthy. I will be posting about specific mechanics I worked on in Castleville in the future. Thanks for reading.