Primi Salvataggi

Come prevedevo nell’articolo di ieri la struttura dei salvataggi si sta rivelando un lavoro per lo più meccanico e lungo ma abbastanza semplice, una volta impostato.

Son riuscito a creare quasi l’intera struttura di dati attualmente presenti nel gioco, e ho creato anche un sistema per salvare a parte i partiti.

Ecco un esempio del risultato in JSON.


{"id":"pa0","name":"Liberal Party","positions":
[
{"issueId":"is1","importance":9,"favour":4},
{"issueId":"is4","importance":7,"favour":2},
{"issueId":"is5","importance":6,"favour":-4},
{"issueId":"is6","importance":5,"favour":1},
{"issueId":"is9","importance":4,"favour":2},
{"issueId":"is2","importance":3,"favour":2},
{"issueId":"is10","importance":2,"favour":1},
{"issueId":"is3","importance":1,"favour":1},
{"issueId":"is8","importance":0,"favour":0}
],
"coalitionId":""}

Domani proverò il caricamento di dati per vedere se il sistema basato sugli id che ho messo in campo funziona come previsto.

Esperimenti di Salvataggio

In questi giorni non ho portato avanti di molto lo sviluppo del gioco sul Rosatellum perché, dopo aver cominciato a pensare di spostare alcune funzionalità in Lua, sto cercando di risolvere il problema del salvataggio e del caricamento dei dati.

In un gioco strategico come quello che sto preparando ci sono veramente molti dati da gestire: l’approccio che ho sempre tenuto in questo tipo di situazione è quello di usare un database, ma vorrei provare a vedere se riesco a farne a meno mantenendo comunque i dati strutturati e il sistema sufficientemente veloce.

Per salvare i dati occorre serializzarli, e questo è abbastanza facile in Unity fino a quando si parla di classi semplici composte da numeri e stringhe, ma quando cominciano ad esserci diversi riferimenti incrociati tra le classi il problema si complica.

Non sono ancora certo di aver trovato il modo migliore per salvare i dati, ma per ora ho duplicato tutte le mie classi creando una classe solo per i dati puri da utilizzare solo per il caricamento e il salvataggio. In questa classe alcuni riferimenti verranno gestiti utilizzando degli identificativi, che però non ho ancora implementato, e non ho deciso come renderli univoci. L’idea sarebbe avere il numero minimo di dati necessari nel salvataggio, e ricalcolare tutti gli altri al caricamento, ma per alcuni dati statistici come lo storico delle elezioni non so se salvare separatamente i risultati o se ricalcolarli partendo dagli elettori (in ogni caso dovrò conservare lo storico di quello che ha votato ogni singolo elettore, perché inciderà sulle elezioni successive).

Oltre al salvataggio dei dati sto cercando di decidere come gestire la configurazione iniziale del gioco, e in particolare i partiti: i partiti dovrebbero essere precostruiti usando un editor e il gioco dovrebbe scegliere secondo alcune logiche quali partiti creare durante la partita. Questi partiti dovrebbero essere salvati in file separati e in un formato leggibile, mentre il salvataggio del gioco potrebbe anche essere in binario.

Tutti questi passaggi non sono molto divertenti da programmare, e sono anche abbastanza lunghi e per ora ripetitivi. Probabilmente sto sbagliando qualcosa nel modo in cui ho strutturato il progetto e forse dovrei più semplicemente risolvere tutto con un database. Oppure forse ho trovato uno dei motivi per che allungano il tempo di sviluppo tra un gioco semplice per una jam, e un gioco vero: e dal numero di tutorial per unity che consigliano di utilizzare in modo errato le PlayerPrefs per salvare i dati comincio a convincermene.

Alcuni giochi della scorsa settimana (30 Ottobre)

Contrariamente alla scorsa settimana questo lunedì ho l’imbarazzo della scelta nel trovare 3 titoli da segnalare.

Mare Nostrvm

Mare Nostrvm è un gioco strategico di battaglie navali con triremi Romane sviluppato dallo stesso autore di Qvadriga. Come Qvadriga questo gioco si svolge a turni e il sistema di controllo di ogni singola unità ricorda il sistema di guida dei carri nell’altro titolo. Indubbiamente si tratta di un titolo di nicchi, ma penso sia anche l’unico nel suo genere per chi è interessato alla storia romana.

Attentat 1942

Attentat 1942 è una avventura grafica basata su dialoghi e immagini che ci porta nella Cecoslovacchia occupata dai Nazisti. Attraverso alcune testimonianze rivivremo la vita dei civili in quegli anni. Il gioco per la sua idea di documento storico può essere comparato a Revolution 1979 che però ha una grafica 3D ed è molto più simile ad una avventura della TellTale. Anche Attentat 1942 è un titolo unico che ci porta a scoprire un lato della storia non molto popolare al di fuori dell’ex Cecoslovacchia.

Skytropolis

Skytropolis è un city builder verticale, ovvero dovremo costruire una città su più piani (una sorta di grattacielo, ma composto da tante costruzioni più piccole). Il gioco ricorda Block Hood ma con una importante differenza. Skytropolis è completamente giocabile in realtà virtuale, e penso si tratti di uno dei primi titoli manageriali in vr. Questo titolo è interessante anche solo per come è stata studiata l’interfaccia grafica, in particolare in un manageriale dove si ha sempre bisogno di mostrare almeno un minimo di grafici. Skyrtopolis probabilmente non sarà nulla di eclatante dal punto di vista delle meccaniche di gioco, ma questo titolo guadagna certamente punti per l’audacia nel tentare qualcosa di simile ottimizzata per il VR.

Stellaris e la correzione degli errori strutturali

Come ho detto più volte Stellaris in questo momento è il mio gioco preferito, ma dal punto di vista militare è anche uno dei giochi meno divertenti.

Anche gli sviluppatori si rendono perfettamente conto di questo problema, e le precedenti patch che hanno sistemato tutti i problemi secondari hanno solo reso questo problema principale ancora più evidente.

La causa del problema non è il sistema militare per se stesso: questo è già discretamente complesso e ogni singola battaglia può anche risultare divertente. Il problema è a livello strategico, ovvero come si creano queste battaglie e come le flotte si muovono attraverso la galassia.

L’errore strutturale è stata la decisione di inserire 3 modalità di viaggio interstellare: in questo modo in una grossa guerra con molti alleati per parti le flotte tendono a muoversi quasi casualmente sulla mappa, e non c’è modo che le difese fisse possano rivelarsi di una qualche utilità. Sul piano strategico la questione si risolve ammassando la flotta e andando a caccia della flotta avversaria, tanto qualunque sistema stellare è uguale all’altro per una battaglia.

Per risolvere questo problema gli sviluppatori devono tornare sui loro passi ed escludere due modalità di FTL lasciando solo l’iperspazio in modo che la mappa possa avere dei corridoi definiti e delle strozzature fortificabili. Oltre a questo gli sviluppatori hanno pensato di ricalibrare completamente il sistema con cui vengono definiti i confini degli imperi in modo che ogni sistema appartenga ad un unico impero e che l’espansione non sia per zone di influenza, ma per singolo sistema.

Tutte queste modifiche sono strutturate in modo da rendere i conflitti più divertenti, ma sono evidentemente un cambiamento radicale di tutto il videogioco: il tipo di cambiamento che ci si aspetterebbe in un sequel.

Una scelta molto coraggiosa quella di prendere un gioco con un milione e 200 mila giocatori, e l’83.7% di recensioni positive su Steam e metterlo a rischio cambiandolo in un modo che certamente scontenterà qualcuno.

Altre case avrebbero appunto cominciato a lavorare direttamente ad un sequel, ma Paradox preferisce portare avanti il suo titolo con il sistema dei DLC e apparentemente questa strategia commerciale – unita ad una base consolidata di clienti – funziona in maniera sufficientemente buona dal coprire i costi di sviluppo e non scontentare gli investitori.

La storia di Stellaris ci mostra benissimo come oggi qualunque gioco non è completo fino a quando viene abbandonato.

Un Tutorial per Cominciare con Unity

Mancano circa 2 mesi al prossimo Ludum Dare, e non è ancora troppo tardi per imparare alcune basi di programmazione dei videogiochi per partecipare all’evento.

Unity può essere un buon sistema anche per i principianti: nonostante si tratti di un motore utilizzato in ambito professionale per la creazione di videogiochi non è particolarmente complesso da affrontare per creare applicazioni abbastanza semplici come ad esempio un gioco da tavolo.

Il sito di Unity ha una ottima collezione di tutorial e lezioni sui vari aspetti del sistema ma se vuoi un approccio ancora più pratico Quill 18 affronta diversi tipi di progetto con vari livelli di complessità.

Ultimamente ha cominciato proprio a programmare un gioco da tavolo: ecco il primo video