Gli errori per principianti più visti nella programmazione multiplayer / giochi online?

Question

Che tipo di errori per principianti hai visto e quali sono le cure?

Uno che si verifica più volte è il client non viene verificato in alcun modo rispetto al server.

Ad esempio:

• L'utente decompila la fonte del gioco in flash o ascolta il traffico di rete e vede dove stanno andando i dati dei punteggi più alti e invia lì falsi punteggi alti nemmeno giocando.
• L'utente utilizza il trainer e ottiene un oggetto che potrebbe anche non apparire nel livello corrente. Questo è stato inviato al server come "client X ha ottenuto l'articolo Y" e il server lo accetta e basta

Il semplice rimedio è ovviamente gestire il client di gioco solo come API per il server. Quindi l'utente può usare i trainer e altre manipolazioni della memoria quanto gli piace, ma il server dice solo che non puoi farlo. Pensa al server come a un database in cui puoi interrogare le cose con le regole del gioco sopra di esso.

Ad esempio

• Client: avvia il gioco
• Client: si collega al server
• Client: richiede la quantità di denaro disponibile dal server
• Utente: abilita il trainer che imposta il denaro su infinito
• Client: server.buyItem ('molto costoso')
• Server: controlla il gamestate (l'utente può comprare cose ora). Controlla il giocatore [0] .money - > nessun bonus.
• Client: server.buyItem ('can get this')
• Server: controlla il gamestate (l'utente può comprare cose ora). Controlla il giocatore [0] .money, ok. player [0] .items.add ('can get this') che ridurrà il costo del player [0] .money. Quindi informare l'invio del client (player [0], 'items', 'can get this'); send (giocatore [0], "denaro", giocatore [0] .money).

L'altro modo è registrare i movimenti del client e inviarlo al server di punteggio più alto dove il server lo riproduce. Naturalmente questo può portare a quel record molto grande.

Answer 1

Senza dubbio, fiducia cieca del cliente. In un gioco a cui sto lavorando, ora conserviamo tutte le "logiche aziendali" lato server e le macchine client ci inviano solo i comandi che stanno eseguendo; ad esempio " il giocatore B vuole spostarsi a destra " - ma il server calcola quanto a destra si sono spostati. Questo ha un sovraccarico prestazionale (e ovviamente problemi di ritardo che potrebbero essere gestiti meglio), quindi una possibile via di mezzo potrebbe essere quella di fare i pesanti calcoli sul lato client e avere ancora dei controlli sul server; per esempio controllando se il giocatore del cliente si sta muovendo più di quanto si supponga sia possibile nel tempo tra gli aggiornamenti; vale a dire se la velocità massima del giocatore è di 200 unità / secondo, se dopo 0,5 secondi si ottiene un aggiornamento che dice che hanno spostato 150 unità, avviarle.

Naturalmente, questo non impedisce necessariamente a qualcuno di codificare un bot per inviare quelle pressioni di tasti, quindi ci sono altri modi per proteggersi da questo. Tuttavia, non avere alcuna convalida è assolutamente un errore da principiante (che, ammettevo, ero colpevole di quando ho preso le scorciatoie)

Answer 2

L'approccio adottato da Valve (almeno, ad un certo punto) era di far simulare il gioco in modo indipendente dai client e dal server. Quindi il server esegue la simulazione autorevole e invia aggiornamenti di stato a tutti i client per correggere i loro errori / tentativi di hacking.

es. se premi la freccia sinistra il tuo personaggio si sposterà immediatamente a sinistra; non è necessario attendere che il server dica "OK". Ma se scopri che ti sei hackerato attraverso un muro, il prossimo aggiornamento del server ti farà apparire proprio accanto al muro, poiché il server lo vede solido.

Allo stesso modo, se un client vede un personaggio spostarsi in avanti, supporrà che continuerà a muoversi in avanti fino a quando il server non ritorna con una risposta autorevole.

Questo approccio sconfigge i tentativi di hacking man mano che il server prende le decisioni principali (ed esegue i controlli di integrità nel processo di simulazione) e si occupa anche del ritardo poiché i client fanno previsioni fino a quando non ricevono notizie dal server.

Un altro grosso errore legato alla "fiducia nel client" è pensare che il protocollo di rete non possa essere simulato. Le persone tendono a presumere che se inviano blocchi binari al server, che questi blocchi binari non verranno mai retroingegnerizzati e che nessuno tenterà di incasinare i dati per vedere cosa succede. Ciò ha portato a tutti i tipi di problemi.

Answer 3

Ragazzi avete praticamente coperto tutto ciò che può andare storto con i client fidati del server. Non ci sono altri problemi reali che mi vengono in mente.

Quindi, invece di dirti cosa può andare storto, guarda cosa può andare bene.

Valve ha dedicato molto lavoro al suo netcode . Leggi