The DragonVale Lair

The DragonVale Lair er et mobile-first companion-produkt, der omsætter komplekse DragonVale-data til praktiske værktøjer for spillere. Det indeholder en breeding simulator, parent finder, quest matcher, Dragonarium-tracking, profiler, saved state, søgning og et turneringssystem.

Jeg har designet, bygget, administreret og vedligeholdt hele produktet. En repræsentant med tilknytning til udviklingen af DragonVale har diskuteret idéer med mig og testet produktet, men The DragonVale Lair er fortsat et uafhængigt community-projekt og er ikke officielt endorsed af DECA Games.

Projektet kort fortalt

DragonVale indeholder hundredvis af drager, breeding-regler, quests og collection goals. Fællesskabet har skabt omfattende dokumentation, men brugen af informationen kræver ofte, at spilleren skifter mellem spreadsheets, wikisider og separate værktøjer.

The DragonVale Lair samler flere almindelige opgaver i ét responsivt interface. Spillere kan simulere breeding-resultater, finde gyldige parent combinations, matche drager med quests, følge deres Dragonarium, søge i datasættet og bevare personlig state gennem en profil.

Projektet er blevet et regelmæssigt anvendt værktøj med et overvejende mobilt og internationalt publikum. Produktværdien ligger i at reducere den indsats, der kræves for at navigere i et stort og løbende foranderligt spilsystem.

Kontekst og mit ansvar

Jeg er ansvarlig for hele produktet: koncept, arkitektur, interface, implementering, datavedligeholdelse, administration, deployment og løbende featureudvikling. Jeg organiserede og administrerede desuden turneringsfunktionen, da globale community-turneringer var aktive.

Fordi produktet bruges af et etableret fancommunity, krævede udviklingen mere end implementering af beregninger. Jeg skulle forstå det sprog, spillerne allerede brugte, bevare velkendte begreber og designe værktøjer, der passede til eksisterende vaner. Interfacet skulle føles nyttigt med det samme for erfarne spillere uden at blive utilgængeligt for nye brugere.

En repræsentant med forbindelse til spillets udvikling bidrog ved at diskutere idéer og teste produktet. Jeg beskriver samarbejdet præcist: Det gav kvalificeret feedback, men udgør ikke et officielt partnerskab eller endorsement fra DECA Games.

Problemet

Spillets kernedata er tæt forbundet. En spiller kan have brug for at vide, hvilke parents der kan producere en bestemt drage, hvilke resultater et konkret par kan give, hvilken drage der passer bedst til en quest, eller hvilke entries der mangler i en collection.

Informationen findes i community-maintained sources, men rå data skaber ikke automatisk en god brugeroplevelse. Spreadsheets er effektive for maintainers, men besværlige at bruge gentagne gange på en telefon. Wikisider fungerer som reference, men tilbyder ikke personlig tracking eller interaktiv sammenligning.

Det centrale produktproblem var derfor at omsætte komplekse community-data til fokuserede workflows, der besvarer spillerens aktuelle spørgsmål med så lidt friktion som muligt.

Krav og begrænsninger

Produktet skulle:

• Fungere særligt godt på mobile enheder.
• Understøtte flere værktøjer uden at skabe forvirrende navigation.
• Bevare personlige collection-data og tool state.
• Holde lokale dragedata korrekte, når spillet ændrede sig.
• Integrere med DragonVale Compendiums breeding-beregninger.
• Gøre store datasæt søgbare og filtrerbare.
• Forblive gratis og tilgængeligt for fællesskabet.
• Skelne tydeligt mellem community-samarbejde og officiel endorsement.
• Understøtte midlertidige high-interest features som globale turneringer.

En væsentlig arkitektonisk begrænsning er, at breeding-beregninger i øjeblikket afhænger af DragonVale Compendium gennem Google APIs. Det giver produktet adgang til en moden beregningskilde, men skaber også en ekstern dependency, som jeg ikke har fuld kontrol over.

Produkt- og UX-beslutninger

Jeg opdelte produktet i opgavespecifikke værktøjer i stedet for at vise hele datasættet gennem ét komplekst interface. Breeding simulatoren besvarer “hvad kan disse parents producere?”, mens parent finderen vender spørgsmålet om og hjælper brugeren med at finde kombinationer til en bestemt drage. Quest matcher og Dragonarium løser hver deres separate game workflows.

Produktet er konsekvent mobile-first. Nyere analytics viser, at cirka 95 % af trafikken kommer fra mobile enheder, så navigation, touch targets, loading states og result density er designet til små skærme frem for behandlet som desktop-features, der blot kollapser responsivt.

Profiler og saved state gør værktøjerne til en del af et længere spillerforløb. Dragonarium-tracking er særligt afhængig af persistence, fordi værdien vokser i takt med, at brugeren registrerer mere af sin collection.

Søgning og filtrering reducerer den kognitive belastning i et stort datasæt. Spillere kender ofte en del af dragens navn, element, availability eller rolle, men ikke den præcise entry. Interfacet understøtter derfor discovery uden at kræve detaljeret kendskab til den underliggende datastruktur.

Turneringssystemet udvidede platformen fra et individuelt værktøj til en fælles community-oplevelse. To globale turneringer tiltrak hver tæt på 200 spillere. Der er ikke en global turnering aktiv nu, men systemet viste, at platformen kunne understøtte tidsafgrænset deltagelse og konkurrence ud over referenceværktøjerne.

Teknisk implementering

Applikationen er bygget med Next.js og TypeScript. Redux håndterer shared client state på tværs af værktøjer, mens Supabase understøtter profiler, saved user data, turneringsdata og persistent application state. Sass bruges til den visuelle implementering.

Det centrale dragedatasæt ligger i selve projektet. Det blev oprindeligt indsamlet gennem scraping og bliver nu vedligeholdt manuelt, når spillet ændrer sig. Det lokale datasæt giver mig kontrol over søgning, filtrering, interface-performance og de felter, produktet har brug for.

Breeding-beregninger bruger aktuelt data og calculation logic fra DragonVale Compendium gennem Google APIs. Applikationen sender requests til den tilknyttede Google Sheets-kilde og omsætter resultaterne til et interface, der er tilpasset spillere. Integrationen modtager cirka 750 requests om dagen, hvilket repræsenterer direkte tool usage og ikke besøgende eller page views.

Opdelingen skaber en praktisk arkitektur: Produktet ejer brugeroplevelsen, lokale referencedata, profiler og saved state, mens en specialiseret community-kilde leverer det aktuelle beregningslag til breeding. Det skaber samtidig projektets største tekniske risiko. Ændringer i den eksterne sheetstruktur, adgangsregler eller beregningsmodel kan påvirke produktet uden et deployment fra min side.

Min foretrukne fremtidige retning er at flytte breeding-beregninger til en backend, jeg selv kontrollerer. Det vil reducere den eksterne dependency og gøre beregningslogikken lettere at teste, optimere og udvide. Jeg undersøger i øjeblikket, hvad der kræves for at reproducere de relevante spilregler korrekt.

Kommunikation og samarbejde

Projektet krævede kommunikation med både teknisk vidende bidragydere og almindelige spillere. Feedback fra spilrepræsentanten hjalp mig med at vurdere, om idéer gav mening i spillets større systemer, mens community-brug viste, hvor terminologi eller workflows var uklare.

Når værktøjerne forklares, undgår jeg at eksponere brugerne for strukturen i spreadsheets, APIs eller state management. Produktet præsenterer begreber i spillets eget sprog: parents, resultater, quests og collections. Oversættelsen fra tekniske data til velkendt brugersprog er en af de vigtigste dele af arbejdet.

Turneringsadministration tilføjede et andet kommunikationsansvar. Regler, deadlines, scoring og deltagelse skulle kunne forstås af et stort internationalt publikum. Featuren fungerede kun, når det tekniske system og den offentlige forklaring var enige.

Resultater og nuværende status

The DragonVale Lair er live og modtager cirka 35.000 page views og 16.000 besøgende om måneden. Den gennemsnitlige tid på sitet er omkring 30 sekunder, hvilket passer til et utility-produkt, hvor mange besøg er fokuseret på hurtigt at besvare et konkret spørgsmål.

Cirka 95 % af trafikken er mobil, og omkring 65 % kommer fra USA. Tallene validerer beslutningen om at prioritere en hurtig mobiloplevelse og præsentere produktet på engelsk for et internationalt community.

Breeding-integrationen håndterer aktuelt cirka 750 Google Sheets-requests om dagen. Platformen har desuden afviklet to globale turneringer med tæt på 200 deltagere i hver.

Sitet bliver fortsat aktivt vedligeholdt. Det vigtigste fremtidige tekniske mål er at reducere afhængigheden af den eksterne beregningskilde og samtidig forbedre datavedligeholdelse og personlige collection-features.

Læring og retrospektiv

Projektet lærte mig, at community-data og produktdata ikke automatisk er det samme. Et spreadsheet kan være korrekt og værdifuldt for expert maintainers og stadig kræve et separat produktlag, før det bliver intuitivt for et bredt mobilt publikum.

Jeg lærte også at behandle ekstern community-infrastruktur som både en fordel og en risiko. Integrationen med Compendium gjorde det muligt at levere avancerede breeding-resultater uden straks at genskabe et etableret system. Samtidig skabte den en operationel dependency, som nu begrænser kontrollen over performance og videreudvikling.

Hvis jeg designede arkitekturen igen med den nuværende usage data, ville jeg prioritere en first-party calculation service tidligere. Jeg ville også formalisere data-update workflowet, så ændringer i spillet kunne valideres og publiceres mere systematisk.

Hvad projektet viser

The DragonVale Lair viser, at jeg kan omsætte et komplekst specialiseret datasæt til et fokuseret produkt, der bruges af et internationalt community. Projektet demonstrerer erfaring med mobile-first UX, state management, authentication, eksterne dataintegrationer, søgning, persistente brugerværktøjer, community-drift og tydelig kommunikation i et uofficielt tredjepartsøkosystem.