Architecture for mobile card game

Question

Architecture for mobile card game

#1 da (2 voti)
#2 da (0 voti)

0

Attualmente sto pianificando un nuovo progetto. È un gioco di carte. Gli utenti possono raccogliere le carte come gioco contro gli altri. Ho iniziato a pensare a come potrebbe apparire un'architettura.

Sono un fan di .NET e userò C # come lingua mia. Voglio anche usare Azure come backend.

Sono curioso, come dividere client e backend?

Metteresti tutta la logica (anche giocando le regole) nel back-end? In questo modo l'intero gioco funzionerebbe come un'API, le diverse piattaforme client sarebbero molto sottili poiché hanno solo bisogno di avvolgere l'API e implementare l'interfaccia utente. Oppure metti solo le cose specifiche dell'utente (login, mazzo di carte personali, ...) nel backend e implementa le regole del gioco sul lato client. Ciò rende il backend meno complesso e creerebbe meno traffico per i client.

Oltre a questo voglio iniziare con un POC offline. Devo considerare qualcosa di speciale o tutte le mie classi NET possono essere riutilizzate in Azure in seguito?

c# architecture azure

posta selmaohneh 15.08.2017 - 06:52

fonte

2 risposte

Leggi altre domande sui tag c# architecture azure

Bluetooth attivo per ricevere il segnale Beacon? Autorizzazione API RESTful per campi aggiornabili

score 2 · Answer 1

Penso a ciò che deve essere sincronizzato in ogni caso. Se la logica è nel front end, devi sincronizzare la logica tra 2 (o più) giocatori. Cosa succede quando ci sono problemi di rete e un giocatore non si aggiorna? Ora hai uno stato non valido su un dispositivo. Come lo riconosci e come lo correggi? Se riesci a rilevarlo, come determini quale dispositivo è sbagliato? Se la logica si verifica sul server, nel peggiore dei casi, l'interfaccia utente di un dispositivo è errata mentre si verificano problemi di rete, ma viene aggiornata non appena viene eseguito il backup della rete.

Inoltre, le cose che sono sul server hanno meno probabilità di essere hackerate per barare. Se il mio dispositivo invia informazioni come il mio punteggio o le mie abilità, potrei essere in grado di hackerare il mio dispositivo per inviare informazioni errate che mi danno un vantaggio. Ma se il server prende queste decisioni, è molto più difficile imbrogliare (almeno in questo modo).

Non ho usato Azure quindi non sono qualificato per rispondere a domande a riguardo.

score 0 · Answer 2

Credo che la logica debba essere sincronizzata sia in back-end che in front end, tuttavia il backend è più importante. Immagina lo scenario in cui l'utente canaglia potrebbe falsificare le richieste al tuo server ( usando le carte che non ha, usando più di 1 carta per turno, leggendo la carta degli ospiti ecc. ) avresti bisogno di questo per essere riconosciuto e proibito sul back-end.

Tuttavia avresti bisogno di alcune parti della logica di gioco sul front-end per mostrare all'utente quando le loro azioni non sono consentite senza controllare il server ad ogni turno. Questo riduce il traffico al backend e rende l'esperienza di gioco più fluida in quanto l'utente non deve aspettare se ha fatto la svolta corretta.

Per quanto riguarda le cose online e offline, dovresti considerare cose come ritardi nelle comunicazioni, abbandono del giocatore, messaggi non ricevuti e forse anche problemi di sicurezza (crittografia dei messaggi). Questo potrebbe richiedere la creazione di un altro strato sottile su backend e frontend che gestirà questo tipo di problemi, ma a parte questo dovrebbe funzionare allo stesso modo.