Scourge of War Waterloo - data di rilascio

Si Angiel, senza contare che sara' interamente in italiano.

Non c'e' scritto nelle specifiche ma e' stato tradotto tutto, messaggi dei corrieri compresi.

 

La c

Tecnicamente si è un casino da capire conosco solo il concetto generale, ma sostanzialmente ci sono engines che ciclano a frame e engine che ciclano a tempo fisico (quindi frame indipendenti); in quest'ultimo caso il gioco fa delle interpolazioni e sposta il ciclo ad un frame successivo se quello attuale è troppo lento. Mentre per quelli frames dipendenti vale un esempio che ho letto "in un gioco di macchina fps dipendente progettato per girare a 30 fps, se forzato a girare a 60 fps la macchina si muove al doppio della velocità".

I motivi esatti della scelta frame dipendente non li conosco, ma immagino siano: meno complessità per piccoli sviluppatori (l'engine grafico è la parte più pesante e costosa), meno potenza di calcolo richiesta alla macchine (l'FPS richiede anche tempo CPU non solo GPU) se vuoi mantenere bassi requisiti ,la logica dell'engine, funzionamento del multiplayers per evitare desync,ecc.

Come dicevo, non è che in singolo l'effetto è sensibile (Gettysburg era meno ottimizzato di Waterloo e ci giocavo bene), lo vedi però in multi dove un giocatore con frame molto basso impatta gli altri, perchè per motivi di sincronia tutti i giocatori devono ricevere gli ordini di tutti.

 

@mitra grazie.
Gioco intrigante, vediamo i prezzi e le specifiche complete (ho un portatile con i3 e HD 6550M come GPU ma spero a breve di cambiarlo con i7/i5 e Geforce 850M o similare).

Ciao

 

Buongiorno a tutti.

Colgo l'occasione della presenza di Mitra in questo forum per fargli i miei più sinceri complimenti per il lavoro svolto sull'IA di SOWW.
Da estendersi a tutti gli altri ragazzi che hanno collaborato su altri aspetti, s'intende.
Un grosso in bocca al lupo per la release.

Il mio grande desiderio, da appassionato napoleonico, è che questo gioco possa convertirsi finalmente in un prodotto di riferimento, maturo/versatile/longevo, per simulare battaglie (e magari mini-campagne) dell'intera epopea.
Che avvenga attraverso addons ufficiali o meno, mi cambia poco.

E qui entrano in gioco i miei timori, poichè ho intravisto tecniche ed approcci di programmazione non propriamente all'avanguardia per gli standard attuali.
Già a suo tempo ero difatti rimasto abbastanza perplesso in merito all'impossibilità di avere uno sprite ratio 1:1 fluido, senza dover ricorrere ad artifici e scale varie.
Adesso leggo che il rendering ed il networking sono interdipendenti ed, ipotizzo io, si aggiornano sullo stesso thread.
Se due indizi fanno una prova, sono giunto alla conclusione che in questo gioco manchi un'ingrediente architetturale a mio avviso fondamentale: il multithreading.

Il primo punto era aggredibile con la creazione di un thread dedicato alla preparazione in background delle risorse (texture DDS degli sprites nella fattispecie, quindi lettura da disco/decompressione/notifica al thread principale/ecc.).
Si sarebbe così implementato un cosiddetto "streaming di texture" che avrebbe consentito di non aver contemporaneamente in memoria video tutte le uniformi utilizzate dallo scenario, bensì di offrirle all'engine grafico in base alle reali necessità della scena presentata.
Poi si faceva una cache per non duplicare le richieste, gestirle a seconda delle priorità (distanza dalla camera?) e contenerle entro un dato budget (soldati prussiani a piedi molto molto distanti? usa uno sprite nero di default), un po' di LOD per minimizzare le animazioni, un parallel_for (secondo Intel TBB) per spalmare l'aggiornamento e la selezione del frame delle stesse.
Certo, uploadare eccessivamente in VRAM ogni volta che ci si sposta sulla mappa può essere costoso. Si potrebbe mettere un budget pure lì e nel frattempo (si parla di frazioni di secondo) utilizzare sprite neutri (per gli Inglesi: fanti rossi, cavalieri rossi, artiglieri rossi, ecc.).
Il problema non può di certo essere renderizzare 50.000 poligoni, comunque. Figuriamoci...

Non sono un'esperto di multiplayer, tuttaltro, e non conosco nemmeno l'architettura (server-client? peer-to-peer?) od il protocollo di networking (reliable UDP?) che impiegate.
Però posso immaginare che, anche in questa modalità, sia indispensabile un'altro thread per processare in background tutti i pacchetti (almeno) in entrata.
Freezare il thread principale perchè non arriva un pacchetto con un'ordine o uno stato di gioco, mi sembra un prezzo da pagare esagerato.
Il rendering e il processamento degli input (mouse, tastiera) dovrebbero idealmente rimanere sempre reattivi.
La stessa IA dovrebbe poter continuare a svolgere il suo lavoro, salvo poi tornare sui propri passi e fornire uno stato di gioco aggiornato da presentare.
Pure qualche incogruenza estetica, tipo spostare bruscamente un'unità avanti o indietro di tot passi, è a mio avviso preferibile ai rallentamenti.
Credo esista una vasta letteratura in materia di gestione delle latenze ed algoritmi per mitigare gli effetti indesiderati.

Dopo questi due thread (uno soltanto in SP), avrei inoltre ritenuto opportuno far gestire i rimanenti ad un task scheduler come quello di Intel TBB (consigliatissimo).
I task sono concettualmente un'unità di esecuzione più piccola del thread ed hanno un'overhead di creazione/distruzione assai inferiore.
Suppongo sarebbero tornati molto comodi per spezzettare le varie sottocomponenti dell'IA (pathfinding, ecc.) e farle aggiornare in parallelo.
Però capisco che farlo in questa fase di sviluppo risulterebbe molto complicato.
Bisogna infatti individuare per tempo le dipendenze (ossia i dati in memoria da condividere, i quali mai e poi mai possono essere letti e scritti da più di un thread in contemporanea!) e fornire eventualmente le opportune sincronizzazioni.
C'è da dire che in un gioco di questo tipo (non sparatutto o di macchine per intenderci), parechio codice IA può lavorare tranquillamente con dati del frame precedente, che non essendo sovrascritti da nessuno durante l'aggiornamento della medesima (sono read-only in pratica), non hanno bisogno di alcuna (spesso costosa) sincronizzazione.

Mi sono dilungato troppo, quindi mi fermo qui.
In sintesi, il multithreading è un'orizzonte che vi consiglio vivamente di esplorare, magari a piccoli passi, e che renderebbe le prospettive del gioco ancor più "intriganti", almeno dal mio punto di vista (ma credo da chiunque voglia ragionare più ad ampio respiro).

Ciao.

 

Ciao Risorgimento

Interessantissimo post tecnico ; non so rispondere sui motivi di scelte tecniche fatte, che probabilmente derivano dal fatto che l'engine originale era quello di Manassas e certi cambi comporterebbero un rifacimento da zero, comunque solo Norb stesso potrebbe rispondere. Il threading è stato implementato ad esempio per le LOS in singolo (infatti le prestazioni sono superiori a gettysburg di almeno 5-10 fps, almeno sul mio PC), ma per il multi si è dovuto disattivare il nuovo sistema per il momento, dato che comportava l'uso del valore di direzione nell'individuazione dei targets, ma questo valore nell'engine originale era un valore float e l'uso dei valori float è out of limit per i processi che devono girare in sincrono come quelli dell'IA, perchè ogni processore può restituire le operazioni di float in modo diverso, generando discrepanza di risultato. Dato che non c'era il tempo fisico di sostituire questa parte del codice di Gettysburg una volta scoperto il problema e di fare i test necessari si è disattivato il threading in multi per adesso. Avendo la deadline a stretto giro di vite (magari aver avuto i 10 anni di War in Flames...), la politica è stata quella di mettere subito solo le features che potevamo implementare e testare nei mesi previsti. Aggiungere si può sempre con calma e valutando i feedback dei giocatori, ma un gioco deve uscire stabile altrimenti parte già con una cattiva fama e ogni patch diventa una deadline; fare la fine di Histwar o peggio ancora Artic Circle non era un'opzione.

 

Mitra, io ho maturato una certezza ed un'idea sui napoleonici. Provo a condividerle qui.

La certezza è che un gioco di tale genere, se programmato a regola d'arte dalle fondamenta, possa tranquillamente girare sulle macchine di oggi a centinaia di FPS.
Consentendone quindi, in una seconda fase, di spenderne un po' per "la ciliegina sulla torta": fisica, balistica (importante per l'artiglieria, meno per la fucileria dove un'approssimazione statistica è più che sufficiente a mio parere), effetti grafici e sonori, ecc.
Quindi, alla lunga, conviene metterci le mani in profondità.

L'idea che mi sono fatto invece riguarda soprattutto l'IA.
Secondo me in questo settore c'è un margine di semplificazione tecnica enorme.
Sono propenso a credere che non siano necessari pesantissimi calcoli, effettuati magari in real-time (alla Total War), per raggiungere l'auspicato realismo.
Semmai parrebbe esser vero il contrario.
L'ufficiale subordinato napoleonico, ad esempio, io tenderei a considerarlo un'agente molto "vincolato": ai manuali, alle dottrine, alle componenti geometriche e funzionali dello schieramento, agli ordini, alle informazioni, ecc.
Tutte cose molto "lineari" (ergo performanti) da programmare.
E con determinate (comode per un PC) tempistiche di attuazione e reazione, per giunta!
Poi i CiC necesiterebbero sicuramente di maggiore "libertà di pensiero" diciamo, ma già si sono ridotte le potenziali elaborazioni in misura rilevante...

Gli stessi algoritmi di LOS, tematica a me quasi interamente sconosciuta, potrebbero non richiedere sempre di una risoluzione millimetrica.
Forse anche un po' di matematica intera su griglie potrebbe fare la sua sporca figura...
Questo almeno nel campo del ragionamento tattico/strategico.
In caso di potenziale firefight tra unità, invece, credo sarebbe opportuno passare ad un grado di raffinatezza superiore - che non si sparino con un'ostacolo insuperabile nel mezzo.
Ma intanto, pure qui, hai tagliato drasticamente i calcoli...

Il problema contro cui siete andati a sbattere penso sia in linea di massima questo:
http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/
Non conosco i dettagli, ma ipotizzo che il risultato possa essere che un'unità di un giocatore assuma di vederne una nemica, ma un giocatore nemico giunga ad una conclusione perfettamente contraria ("non mi dovresti vedere").
Questo perchè lo stato del gioco è localmente derivato dagli ordini condivisi tra i giocatori e contententi valori floating-point (le cui operazioni sono spesso non deterministiche).
E dall'equivoco possono derivare delle successive valutazioni distorte...
Difficile dirlo da fuori.

Per il resto condivido in pieno.

Un saluto.

 

Un'informazione, ma il forum ufficiale di Waterloo è solo quello della Matrix o c'è una home page con tanto di forum come per Gettysburg? Io ho cercato un pò ma non ho trovato nulla.
Grazie per eventuali notizie.

 

qui http://www.norbsoftdev.net/forum/96-discussion

 

5-10 fps in più rispetto a gettysburg... mi fa sperare che forse potrò giocarlo col mio vecchio pc (amd athlon 64 X2 4800+, ati radeon HD4650)

 

TI dirò l'impianto logico l'ho trovato già fatto, anzi era già molto più semplificato del necessario e non è pesante in se, il problema grosso è stata l'interazione con l'ambiente. In potenza non c'era limite, nella pratica il limite me lo davano considerazioni (di Norb più che mie, dato che non avevo ne le competenze ne la possibilità di valutare l'impatto del codice sull'hardware) di dover evitare di usare in maniera esagerata funzioni pesanti di interazione con l'ambiente, come la ricerca di oggetti sulla mappa o caratteristiche della stessa per un raggio troppo ampio. Singolarmente non sono pesanti ma ripetuti centinaia di volte al secondo lo diventano, quindi mi sono dovuto arrabattare ottenendo un output decente usando il minimo di input necessario. Per un PC gaming oriented probabilmente no, ma il target di base di Scourge spesso ha ancora PC non proprio all'ultimo grido, anche se l'obiettivo è attrarre anche i giocatori magari stufi dei TW con qualcosa di più complesso ma non troppo dissimile (ecco perchè la GUI più user-friendly ed un embrione di campagna).

SI qualcosa del genere. Mi sembri parecchio ferrato sull'argomento, per passione o lavoro?

 

Ciao Mitra.

Secondo me le analisi del campo di battaglia dovresti tentare di precomputarle quasi tutte.
Memorizzandole poi nei formati maggiormente accessibili dall'IA.
Più facile a dirsi che a farsi.

Ho un'altra idea architetturale / sui massimi sistemi che, chissà, potrebbe tornarti utile.
Parecchi anni fa ricordo di aver letto un regolamento per soldatini che si basava su ordini scritti e COS (changes of situation).
Il sistema mi pare si chiamasse "Variable Length Bound". Era assolutamente ingiocabile a mano, ma molto stuzzicante.
Si potesse programmare un'IA, o parti di essa, che in real-time lavori quasi solo in risposta ad eventi (magari filtrandone il dispatching con un sistema centralizzato di "sensori"), sarebbe di certo molto performante e probabilmente rimarrebbe comunque realisticamente dinamica.
Anche qui, una parola...

Semplice diletto.

Ciao.

 

No, non penso sarebbe ideale nel nostro caso, forse con giochi strategici che fanno enormi calcoli e con un livello di cambiamento della situazione meno rapido di un rtt, ma per come funziona l'IA (routine logiche in sequenza in ordini di priorità con uscita dalla sequenza quando si hanno le condizioni di esecuzione di questa routine) un sacco di informazioni precomputate non sarebbero usate, e comunque sarebbero obsolete il loop dopo e quindi non usabili; non ci sarebbe risparmio di potenza di calcolo.

Adesso gli eventi sono gestiti, ma sono eventi contestuali neutrali; ad esempio il fatto che un'unità sia sotto il fuoco non è dato da un evento generato dall'unità che mi sta sparando, ma dal semplice calcolo di quanto tempo è passato dall'ultimo morto. Vedo problemi di sincronia in multi con una gestione attiva degli eventi da un giocatore all'altro, uno dei motivi per cui il battlescript degli scenari non può essere usato in multi. E' un gran lavoraccio correggere i problemi di sincronia perchè non sono ben evidenti come il classico crash da debug

 

Ciao Mitra.

Se riesci a trovare 5 minuti liberi, potresti riferire a Norb questa proposta da parte mia?

Nei prossimi mesi (soprattutto agosto), senza fretta però, mi piacerebbe provare a sviluppare per voi una sorta di prototipo di renderer asincrono degli sprite (e rispettive animazioni).

Poi lo profiliamo / cronometriamo approfonditamente e valutiamo se vale la pena implementarlo nel progetto.

Sono argomenti di ottimizzazione per cui nutro un profondo interesse e anche qualche competenza teorica, sebbene arrugginita. Mi piacerebbe passare alla pratica, insomma.

Partirei con un quadtree che gestisca una griglia immaginaria del campo di battaglia (per selezionare unità - e corrieri? - visibili dalla camera), frustum culling sulle singole figure delle unità selezionate dal QT, e da lì via via giù fino a cache di sprite (con budget e priorità di caricamento), semplici strategie di LOD per le animazioni (unico inconveniente è l'inconsistenza temporale dell'animazione tra un riutilizzo efficente e l'altro della memoria delle informazioni di stato dello sprite... in parole povere: se uno sprite esce dalla scena non te lo ritrovi poi al punto ipotizzabile dell'animazione, bensì resettato od, in alternativa, random), risorse "proxy" (con interfaccia di default quando non pronte) preparate in background da un'altro thread, aggiornamento parallelo con Intel TBB delle animazioni, quads degli sprite batchati per materiale con tecniche di HW Instancing (DX9), ecc.

Il vero problema è programmare questo prototipo con tecniche il meno dissimili possibili da quelle attuali del gioco.

Altrimenti servirebbe a poco (sarebbe un casino incorporarlo).

Pertanto uno snapshot del codice sorgente, o almeno della parte grafica di esso (SDK di Power Render in particolare), risulterebbe assai utile. In alternativa anche qualcosa di vecchio, ma non troppo diverso...

Fammi sapere se è interessato.

Ciao.

 

Ti dico la verità avrei seri problemi a tradurre in inglese tutti i concetti; non è un problema scrivere a Norb se mi passi un'email in inglese di cosa ti piacerebbe provare a fare con una tua presentazione di te stesso e la tua email, giusto per fargli capire il tuo background, gliela passo.

Riguardo il codice sorgente chi decide è Norb; noi del team abbiamo tutti dovuto firmare e spedire un accordo di non divulgazione prima di partecipare, non so quanto stretto sia per lui la non divulgazione del codice sorgente della parte grafica. Probabilmente se passate a colloqui bilaterali senza me tra i coglioni, in prima istanza fa prima lui a spiegarti la teoria e rispondere alla tue domande che farti leggere il codice, per poi passare a qualcosa di più pratico.

Potrebbe poi interessarti anche entrare nel team se il progetto ti viene a piacere, ma ovviamente questo significa sviluppare entro binari ed in una direzione definiti da Norb stesso, sulla base di limiti e tempi da rispettare.

Fammi sapere.

 

Ciao Mitra.

Innanzitutto perdonami se continuo a tenerti in mezzo.
Purtroppo sono veramente incasinato ultimamente.
Mio padre si è pure rotto il femore mentre correvamo in bici domenica scorsa per colpa di un'emerito imbecille in macchina, ed è ancora ricoverato a 60 km da casa mia.
Un'intermediario con Norb mi farebbe tanto ma tanto comodo in questa fase di approccio.

I concetti in inglese dell'ipotetico prototipo dovrebbero essere indicativamente questi:

- An application class handling .ini parsing, SOWFS and Power Render setup, scenario loading (basically size of battlefield and location of entities + width of units?), main loop (update+render?), winproc, input devices, etc.

- An asyncronous virtual filesystem (SOWFS) working with packed archives, uses Boost.Asio (IOCP?), callbacking for completion and reading events.

- BattleManager, Entity (anims of figures are advanced/updated, possibly in parallel, only for visible entities + some brutal LOD by distance?), EntityQuadTree (selection by frustum culling, I might even experience with hierarchical grids), EntityQuadTreeUpdater (should inherit from some sort of BAI's "entity is moving" event listener), etc.

- BattleCamera, BattleRenderer, TerrainRenderer (dummy, maybe just one big quad), EntitySpriteRenderer (HW Instancing with InstanceDataVertex={Color,UV}, camera-facing billboarding, state changes minimization, back-to-front sorting, what method for shadows?), etc.

- EntitySpriteResource ("proxy" resource, when it's being prepared it fallbacks to default per-side/per-entity_type sprite, which is a white texture + alpha mask always resident in memory), EntitySpriteCache (budget, load policy by camera distance, update/DDS preparation on separate thread, only one animation - with all its frames and perspectives - is loaded at once, thus the files structure inside archive must reflect this), etc.

Capitolo presentazione: mi terrei abbastanza sul vago, por ahora.
In primo luogo perchè formalmente non avrei nemmeno i titoli di studio per cimentarmi in queste cose, e secondo perchè sono scarsissimo con l'inglese non tecnico.
Ho comunque accumulato una decina di anni di esperienza col C++ e programmazione di videogiochi.
E preferirei spendere quella mezz'ora per documentarmi sulle tecniche di spatial partitioning piuttosto...

La mia email è risorgimento59, gmail, com.

Ciao.

 

Guarda non c'è problema, tanto anche Norb è sempre incasinato, più che altro è che eventualmente sarai lui a scriverti appena è libero.

Perfetto

Titoli di studio specifici non li ha nessuno nel team, Norb è l'unico tecnico professionista (io pure ma non in C++, in SAP R/3 che non c'entra nulla). Hai già competenze in abbondanza da quello che leggo. Più che altro pensavo a nome e cognome veri (mandami un PM).

 

Un breve video della Matrix.

Niente di che a mio avviso.

Scourge of War - The Waterloo Diaries Part 1

 

Dopo averlo riguardato una mezza dozzina di volte... mi sembra proprio una gran figata!

Confido pure che nel prossimo video della NSD si possa apprezzare qualche "contesa morale colonna vs linea" in più, e qualche firefight in meno...

Penso dipenda molto dallo stile di gioco del ragazzo della Matrix, o sbaglio?

Ciao.

 

Ciao Risorgimento, questo video/diario e' un collage di immagini tratte dal video principale fatto un paio di settimane fa'.

Probabile che abbiano fatto vedere volutamente solo certi aspetti per approfondire con qualche altro video/diario successivo.

Dal mio punto di vista sul morale abbiamo dovuto scendere a compromessi. Io sono sempre stato un forte assertore sul valorizzare l'aspetto del morale rispetto ad altri bilanciamenti del gioco. Purtroppo un morale "incisivo" avrebbe un impatto sul giocatore medio abbastanza traumatizzante.

Ho messo a perdere Mitra cercando di valorizzare l'aspetto morale. Lui, a catena, ha spinto su Norb per cercare di ottenere un po' piu' di "umoralita" sul gameplay ma ci siamo scontrati con le esigenze di mercato.

In ogni caso grazie a Mitra il risultato e' stato apprezzabile.

Fortunatamente ci sara' sempre la possibilita' di moddare a piacimento e secondo i gusti.

Qui sotto vi metto anche il precedente video di un'ora fatto dalla Slitherine che nei post sopra non e' piu' disponibile perche' ritirato per audio difettoso. Questo funziona tutto ed e' in HD.

 

Mostrate a Norb questo video qua e poi ditemi se non si ricrede...



Il morale e la suggestione collettiva rappresentavano l'essenza del combattimento napoleonico.

I firefight erano quasi sempre inconcludenti e rovinavano momentum, iniziativa e coesione delle unità.

I combattimenti corpo a corpo avvenivano solo nei centri abitati (con attacchi e contrattacchi tra disordinati ed organizzati provenienti dalle riserve).

Le abilità delle unità, etc... tutto bello, ma se non si coglie appieno questo passaggio qua si rischia un'altro titolo simil-ACW.

Resto ottimista comunque. Ho fiducia in Mitra.

Ciao.