Thejuster (Admin)
Guru^2
Messaggi: 2305
Iscritto: 04/05/2008
|
Buongiorno ragazzi, vorrei discutere con voi su alcune cose che
tutt'oggi non mi sono chiare.
Ho notato che fino ad oggi, non esiste nessun server per giochi scritto in c#
Tranne 1 ed'è anche potente.
https://github.com/Willyham/SagaRO2
E un server per Rangarok 2 online scritto completamente in C#.
Ma ne ho visti invece milioni scritti in C o C++
Tempo fà avevo un dubbio.
E il linguaggio che fà differenza?
Ma ad oggi guardando quel server che riesce a tenere online più di 1000 giocatori in un ambiente 3d
mi viene il dubbio che sbaglio io completamente l'approccio nel realizzare un server.
Allora mi domando, Come si può strutturare un server senza che causi lag?
Come funziona? come può tener traccia di tutti quei utenti compreso di azioni, movimenti, stati ed animazioni?
Con i miei test al max camminavano e dovevo inviare tipo 1 messaggio * numero di player
ogni millisecondo.
Come è possibile?
C'è qualche sistema?
Ho provato a guardarlo ma e difficile senza conoscere il funzionamento del progetto
come e concepito quel server
un esempio che tempo fà feci per gestire gli utenti online
https://www.youtube.com/watch?v=vIkgkQ9FPpg
Ultima modifica effettuata da Thejuster il 26/06/2017 alle 9:13
|
|
nessuno (Normal User)
Guru^2
Messaggi: 6402
Iscritto: 03/01/2010
|
Bisogna saper programmare molto bene (soprattutto nell'area network) e avere hardware potenti.
Il linguaggio principe una volta era il C ... Oggi il risultato che ottieni dal compilatore C# è paragonabile e dunque non ci sono tante differenze.
Ovviamente, a causa del gran numero di sorgenti disponibili in C/C++, questi sono la maggior parte.
Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
---
Il grande studioso italiano Bruno de Finetti ( uno dei padri fondatori del moderno Calcolo delle probabilità ) chiamava il gioco del Lotto Tassa sulla stupidità. |
|
Thejuster (Admin)
Guru^2
Messaggi: 2305
Iscritto: 04/05/2008
|
capito grazie nessuno.
Quindi come immaginavo il problema sono io.
Anche se sinceramente ho provato solo con due socket.
La questione che mi sono sottoposto era:
E' il procedimento giusto inviare continuamente messaggi al server sulla posizione, animazioni, frame e direzione di ogni giocatore?
Quindi ho pensato che inviare questo gran numero di messaggi poteva effettivamente causare lag.
per evitare questo problema, avevo pensato di utilizzare una sola stringa per ogni giocatore
quindi del tipo se ci sono 10 giocatori il server inviare al client 10 messaggi ogni 100ms
Ma guardando un pò il lavoro degli altri, ho notato che utilizzano dei pacchetti anziché utilizzare stringe come faccio io.
del tipo
Codice sorgente - presumibilmente Tutto e di + |
unsigned char packet[7] = {
0x24,
0x00,
0x00,
0x44,
0x14,
0x1E,
0x00
};
SendPacket(packet, 7);
|
Da quel che ho potuto capire, (Correggimi se sbaglio nessuno) i pacchetti in questo modo oltre ad essere più leggeri, sono anche più veloci da ricevere per un server.
Quindi ne aumenterebbe la velocità?
|
|
nessuno (Normal User)
Guru^2
Messaggi: 6402
Iscritto: 03/01/2010
|
Un "pacchetto" o una "stringa" è sempre una sequenza di byte, quindi la cosa rilevante è il numero di byte trasmessi e ogni quanto li trasmetti.
Quello che dovresti fare è "comprimere" le informazioni, inviandole in binario piuttosto che in ASCII e in maniera "compressa" (diciamo zippata per capirci) quando le informazioni sono in numero rilevante.
Ad esempio, una cosa è inviare la stringa
32767 65535 32768\0 fatta da 18 byte, altro inviare
FF 7F FF FF 00 80 00 fatta da 7 byte senza terminatore
Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
---
Il grande studioso italiano Bruno de Finetti ( uno dei padri fondatori del moderno Calcolo delle probabilità ) chiamava il gioco del Lotto Tassa sulla stupidità. |
|
Roby94 (Member)
Guru
Messaggi: 1170
Iscritto: 28/12/2009
|
D'accordo con nessuno, la scelta della stringa è pessima, ma più che per dimensione trovo che il punto di debolezza sia il parsing che il server e il client devono fare. Una struttura viene inviata come dato raw e ricomposta semplicemente per trascrizione bit a bit. Una stringa deve prima essere generata a partire dai dati, poi una volta giunta a destinazione deve essere interpretata char to char. Ti conviene definire uno o piu frame e rispettare quelli per ogni comunicazione. Inoltre bisognerebbe capire qual'è il protocollo migliore per inviare determinati dati, in alcuni casi l'UDP può essere un buon compromesso tra velocità e pacchetti consegnati.
|
|
Thejuster (Admin)
Guru^2
Messaggi: 2305
Iscritto: 04/05/2008
|
Ma certo! non avevo proprio pensato alla possibilità di utilizzare il netstream
per scrivere una struttura o una lista da inviare direttamente al client o al server come dati raw in byte.
Questo sistema lo avevo utilizzato per ricreare texture2d partendo da un immagine bitmap a runtime.
Perché normalmente per ricreare una texture deve esistere un file, ma nel mio caso è l'utente a scegliere il file immagine, quindi non potendola avere come immagine standard la ricreavo a runtime utilizzando il memory stream
ottenendo i byte e ricostruivo l'immagine partendo da esso.
Non avevo proprio pensato a questa possibilità
Grazie roby e nessuno per l'illuminazione.
|
|
HeDo (Founder Member)
Guru^2
Messaggi: 2765
Iscritto: 21/09/2007
|
Ti condivido un link che a suo tempo mi ha aperto gli occhi e mi ha dato un sacco di spunti: http://fabiensanglard.net/quake3/network.php
è la descrizione del protocollo di comunicazione di Quake 3 Arena (1999) e ti fa capire cosa è necessario mettere in piedi per ottenere un gameplay godibile. Dopo che hai letto e capito pensa che questo è successo 18 anni fa e che nel frattempo sono stati fatti progressi ma l'idea base dello snapshot è sempre quella.
|
|
Thejuster (Admin)
Guru^2
Messaggi: 2305
Iscritto: 04/05/2008
|
Grazie mille Hedo.
Conosco bene Quake 3, E il motore di gioco più veloce che sia mai stato creato.
ci ho giocato per tanti anni
Direi veramente uno spunto eccellente.
geniale l'aggiornamento parziale dei byte, così si evita tantissimo spreco di memoria.
veramente bello l'articolo grazie hedo.
|
|