Heroes of Asgard

Stato
Discussione chiusa ad ulteriori risposte.
Come pensate/pensi di gestire la garbage collection, se parli lato client o server dovrebbe essere già tutto ottimizzato di base o sbaglio?
Migrate a Mongo, quindi prima cosa usavate?
Beh, non è tutto ottimizzato di base. A seconda di ciò che fai, puoi generare più o meno garbage collection.
Ti faccio un esempio banale: il foreach. Se io ho una lista e ci itero sopra con un foreach, verrà creata un'istanza di un enumerator la cui reference sarà persa dopo il ciclo. Questa è una reference che andrà pulita dopo dal Collector. E così tanti altri casi.
Per fortuna siamo già abbastanza abituati a tenere presente questa situazione quando scriviamo codice, quindi sostanzialmente c'è stato poco lavoro da fare (ma nonostante questo, ogni tanto trovo sempre qualcosa da ottimizzare, come i cicli all'interno dei cast delle skill, ultimamente).
Altra cosa importante: nella nuova architettura è stato anche fatto un largo uso di pools di object, anche per i pacchetti, per le entities, ecc. Insomma, è stato organizzato tutto meglio, ma è una cosa ovvia: succede ogni volta che si riscrive una parte di software. Se lo riscrivo altre tre volte, probabilmente altre tre volte migliorerò qualcosa.

Siamo al momento su MySQL, però mi stavo documentando sul cluster MongoDB, dal momento che potrei evitare di scrivermi una logica custom di distribuzione per i dati in MySQL.
Ho appena scoperto ora il progetto e, per quanto ho letto, potrebbe essere interessante (considera che sono cresciuto con Metin), ma un consiglio: potreste prima di far uscire al pubblico una versione (qualsiasi essa sia, sia una possibile Open Beta, sia una versione ufficiale) una specie di Wiki (come quella di Metin2) dove spiegate come sarebbe meglio settare le varie razze, le varie skill, etc?
Ah, se dovesse (non ho ancora letto tutta la discussione) esserci il ninja (o qualche sua variante), per favore, settatelo in modo tale che sia almeno decente nei PvP e nelle risse tra PG;)
Sì, la Wiki sarà una buona idea probabilmente. Ma soltanto per la descrizione dei contenuti e cose simili. Non credo che aggiungeremo guide o tutorial nelle fasi iniziali, dato che a mio avviso vi priverebbe del piacerebbe della scoperta e della sperimentazione per cercare di capire cosa un personaggio può fare e cosa no.
Inoltre, ci sono idee che stiamo valutando riguardanti eventuali diari con appunti dei giocatori (vedi il creature-book che ho citato nel messaggio precedente), magari commerciabili: insomma, l'esperienza nel gameplay che un giocatore acquisisce potrebbe essere merce di scambio con i giocatori meno esperti.
Il che a mio avviso è interessante: un giocatore che investe molto tempo, che scopre segreti, dettagli e diventa esperto può diventare una sorta di guida per il popolo della sua fazione, facendo la differenza. Credo sia un buon esempio di RPG skill based.

Che ne pensate al riguardo?

Abbiamo già discusso riguardo l'Assassin (o Ninja, se vieni da Metin2): non vogliamo creare classi sbilanciate (tutti scelgono quella classe) o troppo piatte (non ha importanza quale scegli, tanto sono tutti forti uguale). Vogliamo creare classi caratteristiche, ad esempio (non è detto che sarà così) l'Assassin può essere debolissimo ad ammazzare tanti nemici, ma essere letale se affronta un nemico singolo ed isolato.
In questo modo non si crea il classico "eh, io prendo il Sura Magia Nera così in PvP e rissa vinco" che è banale, ma si crea una meccanica più sottile, del genere "prendo il Sura Magia Nera perché ho forti danni ad area e con l'attuale composizione di gilda con la quale andiamo in guerra/rissa riesco ad ottimizzare l'output di danno che faccio", quando però becco un Assassin che magari è forte nel duello singolo, non ho speranza perché il mio output di danno ad area non è capace di salvarmi.
Credo sia un miglior approccio rispetto a quello di Metin2.
Datemi una opinione e sentitevi liberi di esprimere idee al riguardo: come avete capito, siamo molto aperti ai suggerimenti fatti con criterio.

Stay tuned!
 
Salve, ho letto tutte le pagine di questo progetto e devo dire che finalmente qualcuno sta facendo diciamo un "metin2" migliore. So che non è un metin2 ma un nuovo mmorpg e questo progetto mi ha preso completamente. Sono rari i giochi che mi prendono completamente uno di quelli fu proprio Metin2. E sta accadendo la stessa cosa o almeno lo spero XD. Detto questo ci sono novità o aggiornamenti? Attendo con ansia questo gioco se uscirà XD
 
  • Mi piace
Reazioni: ManHunter
Ultima modifica:
Guardando l'architettura di rete che proponi ti pongo questa domanda citando uno dei sviluppatori che hanno realizzato l'engine Snowdrop(il migliore dopo unreal/cryengine o anvilnext da quanto dicono)
At Ubisoft we have a lot of engines that are online-compatible; however, the technology that we needed for the game, was completely new. Let's take the normal MMO development as an example: You have servers that you need to connect to. This structure is very old-fashioned. If I'm on a server and you're on a different one, we can't play together. I'm not talking about Massive Online, that's a different story. We needed something that would make it possible for people to play with anybody in the world without barriers as long as they are on their friends list. So we needed a technology that would provide the necessary means in the background.
Come gestite questo problema?
Afferma che per i massive multiplayer è un'altro discorso, non capisco il perché
 
  • Mi piace
Reazioni: ManHunter
Guardando l'architettura di rete che proponi ti pongo questa domanda citando uno dei sviluppatori che hanno realizzato l'engine Snowdrop(il migliore dopo unreal/cryengine o anvilnext da quanto dicono)

Come gestite questo problema?
Afferma che per i massive multiplayer è un'altro discorso, non capisco il perché
Tanta roba lo Snowdrop Engine. Dovrebbe essere il motore di The Division. Dopo mi faccio un po' di ricerche al riguardo, nel caso stessi dicendo stupidaggini. :p

Ti risponderò in modo dettagliato, spiegando un po' di concetti del "dietro le quinte". Quando finirò qui, credo che uscirà fuori un articolo intero sull'argomento. :p

DEFINITION
Per definizione, un MMOG deve mettere in condizione di giocare con una enormità di persone contemporaneamente ed interagire con loro come fosse un normale gioco multiplayer, tutto questo in un mondo persistente.
Ora, se vogliamo sviscerare un po' di più questa affermazione, inizieremo a notare come questo sia impossibile senza applicare vari "trucchi" dietro le quinte.

WE ARE COMPLAINING ABOUT PERFORMANCES
Si può sicuramente capire come al crescere dei giocatori connessi, le performance del server vadano degradandosi.
Molte delle operazioni sul server necessitano di operare sull'insieme totale dei giocatori connessi o su un subset di essi, su tutti gli oggetti in giro, su tutti i mostri e le loro AI, ecc. Il tutto varie volte al secondo: immaginiamo, quindi, di dover iterare su 200 giocatori, dover iterare su 2000 giocatori o dover iterare su 20000 giocatori, ad ogni frame della simulazione. Ad ogni iterazione dovrò mandare pacchetti, fare calcoli, modificare posizioni, ecc. C'è, quindi, una crescita esponenziale del carico computazionale per ogni nuovo giocatore connesso.
Come si può ben immaginare, è una mole di lavoro molto grande per una singola macchina, questo per via di un ovvio cap hardware.
Di solito, quindi, esiste una soglia massima di giocatori gestibili contemporaneamente, oltre la quale il server stesso (la macchina fisica) non riesce a stare al passo, creando un'esperienza di gioco negativa (lag, unresponsive commands, etc).
Si può non accettare nuove connessioni oltre questa soglia finché non si libera un posto, al fine di non rovinare l'esperienza a chi è già collegato e sta giocando.
Si potrebbe quindi avviare più server su diverse macchine ai quali far collegare il giocatore, però ovviamente non potranno interagire con giocatori di altri server.
La divisione in varie "server instance" sicuramente non rientra nella definizione di MMOG, in quanto non ti permette di interagire con tutta l'utenza in un mondo persistente, ma crea istanze differenti dello stesso mondo.

Detto ciò, cosa si può fare per "aggirare" un pochino questo problema? E cosa è stato fatto nello specifico di Heroes of Asgard? Quello che descriverò è frutto della mia esperienza e, quindi, è anche ciò che ho infuso nella scrittura di Heroes of Asgard, tentando ovviamente di ottenere il meglio.

WHAT CAN WE DO?
Ci sono diversi accorgimenti che si possono applicare per migliorare quella soglia massima. Sì, migliorarla: ci sarà sempre una soglia massima oltre la quale è difficile andare mantenendo il medesimo hardware.

YOU ARE THE CODE THAT YOU WRITE
Primo fra tutti: scrivere codice decente, con un cervello collegato e senza inutile spreco di risorse. Può sembrare ovvio e banale, ma non lo è. Sprecare risorse equivale a peggiorare le risorse disponibili del server, facendo giungere prima alla soglia massima di giocatori ospitabili.
Sprecare banda significa esaurirla prima, ogni singolo dato che viene trasmesso va accuratamente selezionato. Se io mando un byte in più per ogni utente, quando ne ho 20000 significa inviare quasi 20KB in più per ogni frame.
Sprecare cicli di CPU è come darsi la zappa sui piedi: le operazioni che si eseguono devono essere ridotte al minimo indispensabile, aggiungere una sola chiamata a funzione in più per utente può significare aggiungere N cicli di CPU, che per 20000 utenti saranno N x 20000 cicli di CPU aggiuntivi.
Sprecare memoria (quindi allocare risorse inutili) è deleterio: l'allocazione richiede sia vari cicli di CPU, sia memoria. E la memoria finisce.
In ambienti managed, inoltre, lasciare risorse allocate provoca Garbage Collection, che può significare spendere enormi tempi di CPU per liberare risorse, anziché servire i giocatori e simulare il mondo.
In definitiva, sprecare risorse nel vostro codice farà sì che spenderete più soldi per server migliori e li spenderete più frequentemente per migliorarli al crescere dell'utenza, al fine di mantenere performance accettabili.

FIX YOUR SIMULATION
Come saprete, la simulazione di un mondo virtuale può essere eseguita un tot di volte al secondo dal server. Questo significa che ogni secondo, tutte le entità e i sistemi presenti nel mondo vengono "simulati" un tot di volte. La simulazione può comprendere routine di AI, aggiornamenti di posizioni/rotazioni, etc. Permette di dare una "vita propria" al mondo virtuale.
Il numero di volte che la simulazione viene eseguita è detto FPS, ovvero Frames Per Second. Va da sè che se la simulazione è pesante e richiede tempo, il nostro hardware tenderà a simulare il mondo meno volte in un secondo. Questo può portare ad un degrado della simulazione.
Ma riflettiamo: per ogni gioco è necessario un gran numero di simulazioni al secondo da parte del server? Dobbiamo per forza sforzare l'hardware in questa maniera? Non si può, invece, migliorare la cosa?
Sì. Per gran parte dei giochi con pochi giocatori nella stessa mappa e una velocità di gioco elevata (vedi gli FPS, con un alto numero di comandi) sono sufficienti 60FPS (o meno, dipende dal tipo di gioco ovviamente).
Per un MMOG possono bastarne anche meno, a seconda del genere.
Non c'è necessità di simulare il mondo quante più volte al secondo possibile, dato che la simulazione cambierebbe in modo minimo sprecando più risorse del necessario.
In Heroes of Asgard, ad esempio, il mondo è simulato 20 volte al secondo per ora.

DO WE NEED TO KNOW ABOUT THE ENTIRE WORLD?
Abbiamo detto che in un MMOG si deve interagire con gli altri giocatori e con l'ambiente circostante e devo avere la possibilità di farlo con chiunque si trovi nel mondo in quel momento. Giustissimo, certo.
Ma dal punto di vista di un giocatore è davvero necessario sapere cosa sta facendo un giocatore dall'altro lato della mappa? No, non sempre. Anzi, nella maggioranza dei casi ad un giocatore non interessa minimamente sapere se un altro giocatore, ad esempio, sta camminando o meno in un'altra area distante. Inviare, quindi, informazioni non rilevanti e che non possono essere mostrate sullo schermo dell'utente equivale ad uno spreco di risorse.
Questa osservazione è importante, ci permette di attuare un'ottimizzazione di un certo spessore.
Come posso fare ad informare un determinato giocatore solo sulle entità che possono interessargli?
Perché non suddividere la mappa (o le mappe) in zone? La suddivisione più facile è quella a griglia: dividere la mappa in N x M zone, dove N ed M sono maggiori o uguali ad 1. Questa tecnica è anche nota come space partitioning o zone partitioning.
In questo modo, un giocatore potrà ricevere informazioni solo sulle entità contenute nella sua zona, senza dover per forza avere conoscenza di entità lontane. Se nella mia mappa sono uniformemente distribuite 8000 entità ed è divisa in una griglia 4 x 4, il giocatore che si trova nella zona [1, 1] avrà l'onere di ricevere informazioni solo su 500 entità. Un bel vantaggio, no?
Ma riflettiamo: se il giocatore si trova sul bordo di una zona, non vedrà i giocatori nella zona vicina, nonostante essi debbano essere visibili.
Possiamo dunque capire che il giocatore dovrà essere informato sulle entità contenute nella sua zona e in quelle immediatamente contigue.
La dimensione delle zone permette di ottimizzare molto questo metodo, quindi a seconda delle dimensioni di una mappa può variare la dimensione della griglia, al fine di ottenere l'effetto migliore. Addirittura, può variare la forma delle zone, per adattarsi meglio alla composizione della mappa.

LOOK FAR AS THE EYE CAN SEE
Come detto, la divisione in zone offre già un discreto livello di ottimizzazione permettendoci di inviare informazioni su di una entità solo ai giocatori che realmente possono trarne beneficio.
Ma poniamoci una domanda: all'interno delle zone di interesse (che ricordiamo comprendono anche quelle contigue, quindi in una normale griglia saranno 9 zone nel peggiore dei casi) possiamo individuare informazioni inutili? Certo che sì.
Molto probabilmente ad un giocatore non interesseranno comunque le entità più distanti del suo raggio d'azione, ma di più non interesseranno le entità al di fuori del suo raggio visivo.
Se io non posso vedere un'entità, non mi interessa tracciare cosa sta facendo, nonostante possa trovarsi nella mia zona di interesse. Quindi l'invio di informazioni su quell'entità è uno spreco di risorse.
Come si può determinare quindi cosa effettivamente interessa ad uno specifico giocatore? Il modo più semplice è quello di tracciare, appunto, il raggio visivo. Tutto ciò all'interno di quel raggio è ciò che interessa allo specifico giocatore, le entità al di fuori sono non necessari alla simulazione del mondo per quello specifico giocatore.
E dal momento che abbiamo già una divisione in zone, possiamo semplicemente iterare sulle entità nella zona di interesse (invece che su tutte le entità nella mappa) per stabilire chi è dentro il nostro raggio visivo. Questa concetto è anche chiamato area of interest o AoI.
Quindi, riprendendo l'esempio di prima, itereremo su 500 entità invece di 8000, per estrapolarne quegli ipotetici 25 che rientrano nel raggio visivo e scambiare informazioni attraverso la rete solo con loro.
Da 8000 a 25, un bel risultato. E il tutto senza che l'utente risenta delle mancate informazioni, dato che non le vede. Anzi, potrà notare un minore utilizzo di risorse.
Si può ulteriormente migliorare l'area of interest, applicando vari accorgimenti:
  • organizzare vari livelli di raggi visivi; le entità più distanti riceveranno aggiornamenti meno frequentemente
  • filtrare ulteriormente le entità interessanti a seconda della morfologia della mappa; se una entità è nel nostro raggio visivo, ma dietro ad una montagna, posso eventualmente ignorarla. Quest'ultimo accorgimento, però, a mio avviso ha senso soltanto se già utilizzate il culling per altre cose, in modo da non introdurre ulteriori calcoli solo per filtrare poche altre entità

DISTRIBUTE YOUR COMPUTATION LOAD
Abbiamo già detto che una singola macchina avrà comunque una certa soglia oltre la quale, nonostante tutte le ottimizzazioni fatte, si avvertirà un degrado delle prestazioni (e quindi una cattiva esperienza di gioco).
Bene, ma quindi perché non sfruttare più calcolatori contemporaneamente?
Ci sono ovviamente diversi modi per farlo.
Ad esempio, in Heroes of Asgard ogni mappa che compone il mondo è ospitata su un processo a parte. Questo fa sì che ogni mappa può essere ospitata su una macchina fisica diversa.
Ovviamente, però, si può scendere ancor più di livello e ospitare insiemi di zone su processi separati (in modo che una singola mappa possa essere divisa in più parti e ospitata da diversi server).
Si possono, inoltre, raggruppare servizi globali (come la chat) su processi differenti e/o server differenti, in modo da dare l'impressione che, anche essendo collegati a mappe diverse (quindi server diversi), si possa interagire con giocatori distanti. Inoltre, scindere questo tipo di servizi dal mondo principale fa ottenere un ulteriore guadagno in termini di prestazioni.
 
Quale sarà la connessione minima ottimale per giocare senza troppi problemi?
Un normale piano ADSL di oggi è più che sufficiente, ovviamente, in termini di banda passante. Discorso a parte è per la qualità: connessioni con un elevato tasso di pacchetti persi possono aver problemi, in quanto alcuni dati verranno mandati in modo "unreliable", in quanto non vale la pena rimandare un dato ormai vecchio. Molti altri dati sono reliable, vengono cioè inviati finché non ricevuti.
Ma questo penso che avviene per ogni gioco: se la vostra connessione perde costantemente pacchetti, qualsiasi gioco cui giocate va una schifezza. :p
 
Utilizzando Unity3D, che linguaggio hai utilizzato?
Hai esperienza anche con Unreal Engine 4? Con quale ti sei trovato meglio?
Abbiamo utilizzato sempre il C#.
Ho utilizzato anche un po' Unreal Engine 4, che è un validissimo engine: non l'ho usato abbastanza, però, per poter fare un paragone sensato.
L'unica cosa che posso dire è che Unity mi è sembrato più immediato inizialmente, più produttivo ecco.
Ovviamente utilizzando UE4 e facendoci l'abitudine, probabilmente può essere anche lui produttivo allo stesso modo.

Ci tengo a sottolineare che sia Unity sia UE sono strumenti: quale viene utilizzato meglio dipende da chi li utilizza.

P.S: ricomincerò ad utilizzare UE4 a breve, vorrei provare varie estensioni che ho trovato.
 
Abbiamo utilizzato sempre il C#.
Ho utilizzato anche un po' Unreal Engine 4, che è un validissimo engine: non l'ho usato abbastanza, però, per poter fare un paragone sensato.
L'unica cosa che posso dire è che Unity mi è sembrato più immediato inizialmente, più produttivo ecco.
Ovviamente utilizzando UE4 e facendoci l'abitudine, probabilmente può essere anche lui produttivo allo stesso modo.

Ci tengo a sottolineare che sia Unity sia UE sono strumenti: quale viene utilizzato meglio dipende da chi li utilizza.

P.S: ricomincerò ad utilizzare UE4 a breve, vorrei provare varie estensioni che ho trovato.
Ma a che punto siete con il progetto?
 
Abbiamo utilizzato sempre il C#.
Ho utilizzato anche un po' Unreal Engine 4, che è un validissimo engine: non l'ho usato abbastanza, però, per poter fare un paragone sensato.
L'unica cosa che posso dire è che Unity mi è sembrato più immediato inizialmente, più produttivo ecco.
Ovviamente utilizzando UE4 e facendoci l'abitudine, probabilmente può essere anche lui produttivo allo stesso modo.

Ci tengo a sottolineare che sia Unity sia UE sono strumenti: quale viene utilizzato meglio dipende da chi li utilizza.

P.S: ricomincerò ad utilizzare UE4 a breve, vorrei provare varie estensioni che ho trovato.

Quando hai cominciato con Unity sapevi già il C# o lo hai imparato col tempo?
 
Ultima modifica:
Ma a che punto siete con il progetto?
Ci sono delle problematiche piuttosto serie a livello amministrativo che ci stanno bloccando, in quest'ultimo periodo.
Si tenterà di riprendere il prima possibile, con una buona dose di fortuna.

Quando hai cominciato con Unity sapevi già il C# o lo hai imparato col tempo?
Conoscevo già il C#. Ma ovviamente si migliora sempre.
 
Ci sono delle problematiche piuttosto serie a livello amministrativo che ci stanno bloccando, in quest'ultimo periodo.
Si tenterà di riprendere il prima possibile, con una buona dose di fortuna.


Conoscevo già il C#. Ma ovviamente si migliora sempre.
Vi prego non fatelo sprofondare nel dimenticatoio. :(
 
Qualche altra strategia per poter portare avanti il progetto.
In tutta sincerità, della parte finanziaria se ne sta occupando il nostro CEO.
Il Dev Team non può fare molto, se non cercare di dare il massimo quando può. Non essendo più un lavoro non si può costringere la gente a lavorare gratis. Come avrete capito, nessuno di noi è un teenager :p
 
  • Mi piace
Reazioni: Yosiri
Nessuna novità, al momento. Io personalmente sto sistemando il framework di networking: sperando possa essere prima o poi utilizzato, direi :p
 
Stato
Discussione chiusa ad ulteriori risposte.