The DragonVale Lair

The DragonVale Lair is a mobile-first companion product that turns complex DragonVale data into practical tools for players. It includes a breeding simulator, parent finder, quest matcher, Dragonarium tracking, accounts, saved state, search, and a tournament system.

I designed, built, administered, and maintained the entire product. A representative associated with the DragonVale development team discussed ideas with me and tested the product, but The DragonVale Lair remains an independent community project and is not endorsed by DECA Games.

Project overview

DragonVale contains hundreds of dragons, breeding rules, quests, and collection goals. The community has created extensive documentation, but using that information often requires moving between spreadsheets, wiki pages, and separate tools.

The DragonVale Lair brings several common tasks together in one responsive interface. Players can simulate breeding outcomes, find valid parent combinations, match dragons to quests, track their Dragonarium progress, search the dataset, and preserve personal state through an account.

The project has grown into a regularly used utility with a predominantly mobile and international audience. Its product value comes from reducing the effort required to navigate a large and changing game system.

Context and my responsibility

I am responsible for the complete product: concept, architecture, interface, implementation, data maintenance, administration, deployment, and ongoing feature development. I also organised and operated the tournament functionality when global community tournaments were active.

Because the product serves an established fan community, development required more than implementing calculations. I had to understand the language players already used, preserve familiar concepts, and design tools that fit existing habits. The interface needed to feel immediately useful to experienced players without becoming inaccessible to newer users.

A representative connected to the game’s development team contributed by discussing ideas and testing the product. I describe that collaboration carefully: it provided informed feedback, but it does not constitute an official partnership or endorsement from DECA Games.

The problem

The core game data is highly interconnected. A player may need to know which parents can produce a specific dragon, what outcomes are possible from a particular pair, which dragon best matches a quest, or which entries are still missing from a collection.

The information exists across community-maintained sources, but raw data does not automatically create a good user experience. Spreadsheets are powerful for maintainers yet difficult to use repeatedly on a phone. Wiki pages are useful for reference but do not provide personal tracking or interactive comparison.

The main product problem was therefore to transform complex community data into focused workflows that answer a player’s immediate question with as little friction as possible.

Requirements and constraints

The product needed to:

• Work especially well on mobile devices.
• Support several tools without making navigation confusing.
• Preserve personal collection data and tool state.
• Keep local dragon data accurate as the game changed.
• Integrate with the DragonVale Compendium’s breeding calculations.
• Make large datasets searchable and filterable.
• Remain free and accessible to the community.
• Clearly distinguish community collaboration from official endorsement.
• Support temporary high-interest features such as global tournaments.

A major architectural constraint is that breeding calculations currently depend on the DragonVale Compendium through Google APIs. That gives the product access to a mature calculation source, but it also creates an external dependency that I do not fully control.

Product and UX decisions

I divided the product into task-specific tools rather than exposing the full dataset through one complex interface. The breeding simulator answers “what can these parents produce?”, while the parent finder reverses the question and helps users find combinations for a target dragon. The quest matcher and Dragonarium each address separate game workflows.

The product is explicitly mobile-first. Recent analytics show that approximately 95% of traffic comes from mobile devices, so navigation, touch targets, loading states, and result density are designed around small screens rather than treated as desktop features that merely collapse responsively.

Accounts and saved state allow the tools to become part of a longer player journey. Dragonarium tracking is especially dependent on persistence because its value increases as the user records more of their collection.

Search and filtering reduce the cognitive load of a large dataset. Players often know part of a dragon’s name, element, availability, or role but not the exact entry they need. The interface therefore supports discovery without requiring detailed knowledge of the underlying data structure.

The tournament system extended the platform from a private utility into a shared community experience. Two global tournaments attracted close to 200 players each. Although no global tournament is currently active, the system demonstrated that the platform could support time-limited participation and competition in addition to reference tools.

Technical implementation

The application is built with Next.js and TypeScript. Redux manages shared client state across tools, while Supabase supports accounts, saved user data, tournament data, and persistent application state. Sass is used for the visual implementation.

The core dragon dataset is stored with the project. It was initially collected through scraping and is now maintained manually as the game changes. Keeping that dataset local gives me control over search, filtering, interface performance, and the fields required by the product.

Breeding calculations currently use data and calculation logic exposed by the DragonVale Compendium through Google APIs. The application sends requests to the connected Google Sheets source and translates the results into an interface suited to players. The integration receives approximately 750 requests per day, which represents direct tool usage rather than visitors or page views.

This division creates a practical architecture: the product owns the user experience, local reference data, accounts, and saved state, while a specialised community source supplies the current breeding calculation layer. It also creates the project’s main technical risk. Changes to the external sheet structure, access rules, or calculation model can affect the product without a deployment from my side.

My preferred future direction is to move breeding calculations into a backend I control. That would reduce the external dependency and make it easier to test, optimise, and extend the calculation logic. I am currently investigating what would be required to reproduce the relevant game rules accurately.

Communication and collaboration

The project required communication with both technically knowledgeable contributors and ordinary players. Feedback from the game representative helped me test whether ideas made sense within the game’s wider systems, while community usage exposed where terminology or workflows were unclear.

When explaining the tools, I avoid exposing users to the structure of spreadsheets, APIs, or state management. The product presents concepts in the language of the game: parents, results, quests, and collections. This translation from technical data to familiar user language is one of the most important parts of the work.

Tournament administration added another communication responsibility. Rules, deadlines, scoring, and participation needed to be understandable to a large international audience. The feature only worked when the technical system and the public explanation agreed.

Results and current status

The DragonVale Lair is live and receives approximately 35,000 page views and 16,000 visitors per month. Average time on site is around 30 seconds, which is consistent with a utility where many visits are focused on answering a specific question quickly.

Approximately 95% of traffic is mobile, and about 65% originates from the United States. These figures validate the decision to prioritise a fast mobile experience and to present the product in English for an international community.

The breeding integration currently handles about 750 Google Sheets requests per day. The platform has also run two global tournaments with close to 200 participants in each event.

The site remains actively maintained. The main future technical objective is to reduce dependence on the external breeding calculation source while continuing to improve data maintenance and personal collection features.

Lessons and retrospective

The project taught me that community data and product data are not automatically the same thing. A spreadsheet can be accurate and useful to expert maintainers while still requiring a separate product layer before it becomes intuitive for a broad mobile audience.

I also learned to treat external community infrastructure as both an advantage and a risk. Integrating with the Compendium allowed me to provide sophisticated breeding results without reproducing an established system immediately. At the same time, it created an operational dependency that now limits control over performance and future development.

If I were designing the architecture again with today’s usage data, I would prioritise a first-party calculation service earlier. I would also formalise the data-update workflow so changes to the game could be validated and published more systematically.

What this project demonstrates

The DragonVale Lair demonstrates my ability to turn a complex specialist dataset into a focused product used by an international community. It shows experience with mobile-first UX, state management, authentication, external data integrations, search, persistent user tools, community operations, and clear communication around an unofficial third-party ecosystem.