Architettura del sistema di badge simile a StackExchange?

1

Voglio implementare la gamification nella mia applicazione mobile education. Ho un database con attività dell'utente e voglio analizzarlo e dare badge a un utente. Ci saranno molti badge con condizioni totalmente diverse. Alcuni badge saranno dati una volta, altri ripetutamente.

Il mio approccio attuale:

  1. tabella badges_awarded che contiene un badge, un timestamp e un argomento stringa contenente l'id dei dati utilizzati per questo premio
  2. tabella badges_evaluation contenente l'ultima chiamata di ogni algoritmo di badge e data in cui deve essere eseguita nuovamente
  3. quando l'utente termina un gioco eseguo uno script in background che eseguirà regole di assegnazione. La tabella di valutazione viene utilizzata per saltare alcuni algoritmi che hanno il prossimo tempo di esecuzione in futuro.
  4. se il gioco ha prodotto alcune condizioni che invalidano le regole di alcuni badge, aggiornerò il loro prossimo tempo di esecuzione nella tabella badges_evaluation (ad esempio un badge che l'utente non fa errore 5 volte di seguito può ricominciare a contare quando un utente ha sbagliato nel gioco ).

Questa tattica riduce alcune valutazioni e query di database. Il gioco funziona su un dispositivo mobile, quindi devo ridurre la complessità il più possibile. Mi piacerebbe leggere alcuni suggerimenti e strategie. È fondamentale progettare questa funzione in modo efficiente.

Un altro approccio rappresenta Fitbit: carica i dati sul server e ricevi i badge indietro. Ma preferisco assegnare un figlio anche offline.

Esempio di badge:

  1. l'utente ha giocato 3 giorni consecutivi per l'argento e 7 giorni per il distintivo d'oro
  2. utente non ha fatto errori 10x, 25x o 100 volte di seguito (bronzo, argento, oro)
  3. l'utente ha terminato una partita in X, Y o Z secondi (bronzo, argento, oro)
posta Leos Literak 14.05.2016 - 08:27
fonte

1 risposta

3

Il tuo approccio funzionerà e probabilmente è il modo più comune per raggiungere questo obiettivo. Se lo hai confrontato ed è troppo lento, c'è un modo più efficiente, ma è molto più difficile da implementare.

Quello che puoi fare è trasformare ogni regola in un automa a stati finiti con transizioni quando si verificano eventi rilevanti. Ad esempio, supponiamo di avere un badge "completare sia l'attività A che l'attività B entro 1 ora". Puoi tradurre questo in un FSA con le seguenti transizioni di stato:

state 0
  - if task A completed, go to 1
  - if task B competed, go to 2

State 1
  - if task B completed go to 3
  - if 1 hour elapsed, go to 0

State2
  - if task A completed go to 3
  - if 1 hour elapsed, go to 0

State 3
  - award badge

È quindi possibile mantenere un elenco di eventi attivi che possono causare una transizione e aggiornare lo stato quando si verifica l'evento, senza richiedere alcuna attività in background o query di database. L'unico problema è che ogni badge diventa molto più difficile da implementare. Se ne possiedi molti potrebbe anche valere la pena progettare un semplice DSL che compili fino agli appropriati elenchi di transizione.

    
risposta data 14.05.2016 - 15:08
fonte

Leggi altre domande sui tag