Oppure

Loading
11/12/21 23:11
Thejuster
Salve ragazzi, più che aiuto chiedo un consiglio.
Sto sviluppando un server mmo, Ma mentre sono quasi arrivato alla gestione di tutti i client connessi per una determinata
area mi è sorto questo dubbio.
Siccome è un progetto di test, se funziona come spero, magari lo rilascio per un uso diverso.

In pratica funziona così.

[Luogo 1]
Giocatore-A,Giocatore-B,Giocatore-C,Giocatore-D

[Luogo 2]
Giocatore-E,Giocatore-F,Giocatore-H

[Luogo 3]
Giocatore-I,Giocatore-L


E pensavo al modo migliore per gestire questo enorme flusso di dati.
Il server oltre a stabilire l'essata posizione di ogni utente, deve anche tenere in memoria le relative coordinate ed eventuali azioni in corso.

Penso che inviare una sola e grande lista sia eccessiva come soluzione.
Ma nemmeno o (forse) un loop di richiesta ed aggiornamento di posizoini.
Ma ho pura di mandare sotto stress il server.

Quello che avevo pensato è:
Giocatore-A Invia richiesta al server di ottenere (solo) le informazioni relative a tutti i giocatori presenti in quel livello
così per gli altri.

pensavo se ci sono 5 giocatori in livello A
5 (Giocatori) * 5 (Richieste) = 25 query al db + Invio e Ricezione di 120bytes ogni 50 o 100 ms.

Finché sono pochi, credo potrebbe pure andar bene.
Ma pensavo di usare questo server su larga scala, magari parlando di un qualcosa come 1000 / 2000 utenti connessi

Certo, potrei evitare di eseguire le query, tenendo invece tutto in memoria sul server in liste e strutture.
Ma... Nel caso il server crasha per qualche errore.
Tutte le posizioni ed eventuali stati andrebbero persi.

Chiedo magari se qualcuno ha già provato a fare qualcosa di simile, puoi dirmi se sto proseguendo in modo corretto
o ci sono soluzioni migliori.

Ultima modifica effettuata da Thejuster 11/12/21 23:17
mire.forumfree.it/ - Mire Engine
C# UI Designer
15/12/21 13:07
Snogar
Io invece dividerei la cosa più che per aree che potrebbero essere eccessive, lo mirerei sul singolo personaggio.
Magari legato al suo raggio di vista o poco più. Così sei sicuro di inviare solo i dati che effettivamente interessano e non una sfilza di cose che magari non verranno mai considerate.

Forse la cosa giusta è utilizzare una combinazione di questi due metodi.
aaa
17/12/21 20:39
Thejuster
Uhm si direi che sia la soluzione migliore. Ma volevo mostrarti una cosa.

Anni fa, giocavo ad un mmo al quale erano connessi più di 3000 giocatori.
Ed in un livello ne vedevi almeno 200 o 300 che si muovevano ed eseguivano azioni diverse.

github.com/eathena/eathena/tree/master/…

La cosa che mi incuriosiva, e che utilizzava ben 3 server.
1° per gestire i login.
2° per gestire varie informazioni relative ai personaggi
3° per gestire posizioni ed azioni.

come puoi notare dal link ci sono 3 cartelle che contano più delle altre ovvero i 3 server
login,char,map

Osservando il sorgente, riesco a dedurre che una volta raccolto dati da un giocatore, viene tutto posizionato in una lista e tenuto in memoria. (come sospettavo)
E solo in rare occasioni, eseguire query di salvataggio.

Altra caratteristica, essendo interconnessi in locale,
è possibile scambiare informazioni molto velocemente rispetto ad un socket remoto.
Quindi se il login server gestisce le informazioni basi, il char server gestisce le informazioni dei persaggi,
Il map può inviare una richiesta (pacchetto serializzato) agli altri 2 server per ricevere tutte le informazioni in modo rapidissimo ed elaborare eventuali richieste senza fare decine di query inutile, sovraccaricando il flusso di dati.
E' una genialata non c'è che dire. Ma non sò se sia un buon metodo usare "i 3 server" al posto di 1

Purtroppo non posso ottenere il sorgente del client, ma il server era strutturato proprio bene.
vorrei ottenere qualcosa del genere, ma evitando di usare 3 server differenti intercomunicanti.

Se riesco ad ottenere prestazioni simili, il progetto passerà poi su unity.

Quindi credo proprio che farò in questo modo, avere un range di visibilità oltre la risoluzione dello schermo e raccogliere un tot di player. (anche per poter udire eventuali suoni emessi da combattimenti ecc. )

L'unica altra soluzione che vedo, e quella di pre-caricare in momoria al momento del login, tutte le informazioni che occorrono in seguito. ma poi si ritorna al punto iniziale, sovraccaricando di memoria il server.
Ultima modifica effettuata da Thejuster 18/12/21 7:16
mire.forumfree.it/ - Mire Engine
C# UI Designer
18/12/21 14:05
Snogar
Se hanno deciso di utilizzare 3 server è per una questione prestazionale dei singoli server (immagino) ....quindi se hai una macchina potente la cosa può essere ovviata utilizzando 3 software diversi sulla stessa macchina .....a questo punto penso che potresti farti uno studio di come deve funzionare il tuo mmo e cercare di suddividere il software in tanti sottoservizi così da avere il massimo delle prestazioni sulla singola macchina.

E pensandoci bene ora che si hanno i multicore lanciare operazioni in parallelo dovrebbe essere una cosa abbastanza alla portata ....magari suddividere in sottoservizi di livello critico e quelli di base, dove quelli di livello critico devono avere la priorità assoluta ed essere consegnati nel minor tempo possibile (un esempio scemo può essere la posizione del pg e di quelli che lo cirdondano) mentre quelli base possono essere consegnati con più calma tanto non sono essenziali per le funzionalità del gioco.
aaa
18/12/21 16:04
Thejuster
si ottima idea. Credo proprio che farò in questo modo.
Magari dando anche priorità ad alcune richieste rispetto ad altre.

Ad occhio ragionando su due piedi, possono sembrare cavolate, ma sono queste cavolate che fanno la differenza.
Risparmiare bytes e richieste, ne aumentano le prestazioni così come tanti altri fattori che magari chi gioca ignora completamente la complessità della cosa.

già solo il fatto di gestire strutture con quaternioni, comportamenti, status è caos.
Vedremo un pò cosa riesco a tirare fuori.

Grazie per le delucidazioni.
mire.forumfree.it/ - Mire Engine
C# UI Designer
20/12/21 19:32
Snogar
Postato originariamente da Thejuster:

si ottima idea. Credo proprio che farò in questo modo.
Magari dando anche priorità ad alcune richieste rispetto ad altre.

Ad occhio ragionando su due piedi, possono sembrare cavolate, ma sono queste cavolate che fanno la differenza.
Risparmiare bytes e richieste, ne aumentano le prestazioni così come tanti altri fattori che magari chi gioca ignora completamente la complessità della cosa.


In effetti il segreto dovrebbe essere quello, sottoservizi con vari livelli di priorità che stipano dati nel loro database personale e che all'occorrenza lo consultano per rispondere all'applicazione principale .....ora non so che tipo di db utilizzi ma inizia anche a prendere in considrazione quelli "snelli" tipo sqlite .....tanto le operazioni che ogni servizio svolge deve essere al top della semplicità, quindi implementare un db pesante con mille funzioni non avrebbe senso ....anzi magari è pure controproducente.
Bisognerebbe fare uno studio su questo tipo di db per beccare quello con le prestazioni migliori. (io conosco solo sqlite ma immagino ce ne siano altri con le medesime caratteristiche di "leggerezza";).
Ovviamente la maggior parte delle informazioni va tenuta in memoria ....ma chiaramente non puoi tenere tutto li, quindi un db del genere è un buon compromesso.

Postato originariamente da Thejuster:

già solo il fatto di gestire strutture con quaternioni, comportamenti, status è caos.
Vedremo un pò cosa riesco a tirare fuori.

Grazie per le delucidazioni.


Figurati per così poco :k:
aaa
23/12/21 6:43
Thejuster
Il database è mysql,
semplicemente per creare gli account di gioco, o gestire un portale web comunicante con il server occorre un dbmysql.
o magari per la possibilità di alcune funzionalità di eventuali app mobile.
mire.forumfree.it/ - Mire Engine
C# UI Designer