Tapaustutkimus
Dice Cat: Pöytäpelien matchmaking-sovellus
Laajuus
1,413
Committia
~72,300
TypeScript-riviä
87
React-komponenttia
10,000+
Peliä tietokannassa
86
SQL-skeematiedostoa
<500 ms
Osumahaun kesto (ennen 3-5 s)
Ongelma
Lautapelien harrastajat keräävät suuria kokoelmia ja kehittävät vahvoja mieltymyksiä, mutta on todella vaikeaa löytää paikallisia pelaajia, joilla on samat pelit, jotka sopivat aikataulultaan yhteen ja joiden pelityyli on samanlainen. Nykyiset vaihtoehdot - Facebook-ryhmät, Discord-palvelimet, Meetup - vaativat manuaalista koordinointia, eikä niissä ole pelivalikoiman yhteensovitusominaisuutta.
Keskeinen toive: kehitä lautapeleille Tinderin kaltainen sovellus, joka todella tuntee pelikokoelmasi.
Yleiskatsaus
Tuote sai alkunsa nimellä "Meeplr" - käyttökokemuskonseptina, jota edelsi perusteellinen tutkimus jo ennen kuin yhtään riviä koodia oli kirjoitettu.
- ·Kilpailuanalyysi nykyisistä yhteisö- ja parinmuodostustyökaluista
- ·Käyttäjäprofiilin luominen - muualta muuttanut pelaaja, jolla ei ole paikallista peliryhmää
- ·Kolme kierrosta ääneen ajattelua hyödyntävää käytettävyystestausta, johon osallistui 15 henkilöä
- ·Kano-analyysi: kaikki suunnitellut MVP-ominaisuudet todettiin toimiviksi tai houkutteleviksi
- ·Nimeksi muutettiin Dice Cat, kun tavaramerkkitutkimus esti alkuperäisen nimen käytön - nimi jäi paremmin mieleen testissä
Tärkeimmät ominaisuudet
- ·Moniulotteinen paritus: pelikirjastot, maantieteellinen läheisyys, aikataulujen päällekkäisyydet ja pelityylimieltymykset
- ·Yli 10 000 pelin tietokanta, jossa on paikallinen sumehaku ja mahdollisuus lisätä pelejä manuaalisesti
- ·Visuaalinen viikkosuunnitelman laatija, jossa tunnistetaan mahdollisten aikataulujen päällekkäisyydet
- ·Yhteyspyyntöjärjestelmä, jossa suoritetaan keskinäinen yhteensovitus ennen viestien lähettämistä
- ·Salattu sovelluksen sisäinen viestintä istuntojen suunnittelua varten
- ·Push-ilmoitukset Firebase Cloud Messagingin kautta
- ·Mukautettava SVG-avatarien luontityökalu, jossa on kerroksellinen komponenttijärjestelmä
- ·Lähellä olevien pelaajien karttanäkymä PostGIS-paikkatietokyselyjen avulla
Kuvakaappaukset
Tekninen arkkitehtuuri
Tekniset kohokohdat
Tietokannan suorituskyky
Ottelupisteiden laskemiseen käytetyt monitaulukoiden JOIN-kyselyt kestivät alun perin 3-5 sekuntia. Strategisen PostGIS-indeksoinnin ja kyselyjen uudelleenrakentamisen ansiosta niiden suoritusaika lyheni alle 500 millisekuntiin.
Ulkoisen sovellusliittymän riippuvuuden virhe
BoardGameGeek lopetti API-käytön kesken kehitystyön. Siirryimme rakentamaan paikallista, yli 10 000 pelin tietokantaa, johon yhteisö voi lisätä sisältöä - näin saimme paremman toimivuuden offline-tilassa eikä tulevaisuudessa ole riippuvuusriskiä.
Push-ilmoitusten käyttöoikeuksien rakenne
Trigger-pohjaisessa ratkaisussa ilmeni käyttöoikeusvirheitä tuotantoympäristössä. Siirrettiin logiikka Supabase Edge Functions -palveluun, mikä ratkaisi käyttöoikeusongelman tyylikkäästi.
Mitä opin
Pöytäpelien matchmaking-sovellusta arvioidaan sillä, lähettävätkö ihmiset toisilleen viestejä, mikä osoittautuu eri tavoitteeksi kuin se, osuuko yhteensovitus oikeaan.
Yhteensopivuuspisteet ovat tuotepäätös, ei laskutoimitus
Käyttäjät kertoivat, että pisteet pysyivät jatkuvasti alle 20 prosentin, minkä seurauksena kukaan ei tuntenut tarvetta ottaa yhteyttä. Laskelmat olivat perusteltuja; tuote oli joka tapauksessa epäonnistumassa. Perusteiden ja painotusten tasapainottaminen niin, että hyvä yhteensopivuus näkyy 76 %:na 65 %:n sijaan, kun taas heikot yhteensopivuudet näkyvät edelleen selvästi heikompina, muutti käyttäytymistä muuttamatta sijoitusta. Käyttäjälle näytetty pisteet on kutsu, ei mittaus, ja se on kalibroitava sen päätöksen mukaan, jota häneltä pyydetään tekemään.
Kaiken hakeminen toimii, kunnes joku on suurkäyttäjä
Yli tuhat viestiä sisältävien keskustelujen avaaminen kesti noin kymmenen sekuntia. Sadan viimeisimmän viestin lataaminen laskevassa järjestyksessä ja niiden järjestyksen kääntäminen näyttöä varten lyhensi avaamisaikaa alle sekuntiin, eikä se vaikuttanut mitenkään lyhyisiin keskusteluihin. Kysely toimi moitteettomasti kaikissa sen kirjoittamishetkellä olemassa olleissa tilanteissa, ja juuri siksi tämäntyyppiset ongelmat ovat niin hankalia.
Pakollinen kenttä, joka ei ole kaikille pakollinen
Profiilin vahvistuksessa vaadittiin sijaintitietoa kaikilta, myös pelaajilta, jotka pelaavat ainoastaan verkossa eivätkä tarvitse sitä, minkä vuoksi kokonainen käyttäjäryhmä ei pystynyt saattamaan rekisteröitymistä päätökseen. Kun sijaintitiedon antaminen sidottiin pelimieltymyksiin ja kunkin tapauksen selventäminen siirrettiin huomautuksesta otsikkoon, sekä este että sen taustalla ollut sekaannus saatiin ratkaistua.