Nell’ultimo mese ho cominciato a lavorare a ncJump, un progetto fatto con l’nCine, che come molti di voi sapranno è un framework open-source scritto in C++ dal nostro @encelo.

Qualche tempo fa, dei membri della community di GameLoop hanno seguito il corso CS50’s introduction to game development, e ho pensato che la sequenza di giochi presentata potesse darmi un buon suggerimento su che tipo di gioco creare.

Un paio di sviluppatori hanno già fatto o hanno cominciato a lavorare ai primi giochi della lista di quel corso. C’è un clone di Pong scritto da @encelo, un clone di Flappy Bird scritto da @Vasile, e un clone di Breakout in sviluppo da @mat3. Quindi ho optato per un clone di Super Mario Bros.

L’idea sarebbe di seguire i passi della lezione 4 del CS50 usando l’nCine invece di Love2D.

Per cominciare a sviluppare un gioco con l’nCine è necessario effettuare alcuni passi che fortunatamente sono documentati nella pagina di download dell’nCine. Quindi ho installato l’nCine, clonato il progetto ncTemplate, e ho cominciato a smanettare sul codice di quest’ultimo.

Un po’ di codice

La cosa principale da considerare dal punto di vista del design del software è che ho rinominato MyEventHandler in JumpHandler e ho introdotto la classe Game. Mentre JumpHandler svolge un ruolo da ponte tra il gioco e l’engine, Game è il nucleo del progetto ed è responsabile del ciclo di vita dei suoi oggetti e della logica dell’applicazione.

Poi ho proseguito con l’implementazione di una classe Entity seguendo l’idea di un Entity component system. L’entità può avere componenti come un’immagine, una macchina a stati, o un corpo per la fisica e le collisioni.

Un’interfaccia grafica è fondamentale per iterare velocemente su nuovi elementi man mano che vengono aggiunti al gioco, sia per avere un feedback visivo quando serve fare debugging sia per cambiare ogni tipo di valore o configurazione a run-time. Per questo motivo ho introdotto una classe Editor, che fa uso massiccio di Dear ImGui di @ocornut, oltretutto direttamente fornita dall’nCine.

Box2D è la mia scelta per quanto riguarda la fisica e le collisioni 2D. È sviluppata da @erincatto ed è molto facile da usare.

Le ultime settimane le ho passate implementando degli importanti stati per l’Entity: idle, move, jump, e fall. Secondo me rappresentano le basi dell’intero gameplay e credo che il risultato sia buono abbastanza per proseguire sui prossimi passi di sviluppo, ma per quelli dovrete aspettare il prossimo devlog, quindi stay tuned!

Buon anno con un nuovo devlog sullo sviluppo di ncJump. Ho passato un po’ di tempo sul refactoring del codice della classe Entity poiché stava diventando troppo monolitica, e ho migliorato Tileset e Tilemap usando perlappunto entities invece di semplici sprite sia per i prototipi di tile sia per i tile concreti. Entriamo nei dettagli.

Everything is entity

È importante considerare che tutto è entity. I personaggi sono entità, i tile sono entità, gli eventi sono entità, e così via. Come si fanno a distinguere tra di loro? Ogni entità può avere più di una componente, che sia un’immagine o una macchina a stati o un corpo fisico. Dunque insiemi diversi di componenti determinano i vari tipi di entità che popoleranno la scena di gioco. In questo devlog esploreremo le varie componenti necessarie alla seconda iterazione dello sviluppo di ncJump.

Transform

La componente transform è un semplice guscio intorno a un ncine::SceneNode. Tutto il resto è relativo a questo nodo, per cui se volessimo muovere l’intera entità, potremmo semplicemente modificare il nodo della transform. È importante notare che uso un UniquePointer per il nodo in modo che venga creato nell’area heap e non sia soggetto a move. Ciò risulta necessario dal momento che l’nCine scene graph lavora per mezzo di puntatori.

Physics

La componente physics agisce sia da abstraction layer tra il gioco e Box2D, sia da contenitore di valori come la velocità massima, la forza di salto, e così via. Più importante di tutti è il puntatore ad un b2Body che ci permette di interrogare lo stato fisico corrente dell’entità.

Graphics e State

A livello base abbiamo una componente grafica con una singola immagine o animazione, e una componente state con un singolo stato che non cambia mai. Queste sono probabilmente comuni alla maggior parte delle entità del gioco.

Ora dobbiamo considerare il concetto di un personaggio in movimento con stati come fermo, muovi, salta, cadi. Anche questo insieme di stati è molto comune per cui ha senso implementarlo direttamente in C++. Il risultato è la seguente gerarchia di classi.

Ne segue che una classe CharacterState sia fortemente accoppiata con la relativa componente grafica, che definiamo come CharacterGraphics, per cui la gerarchia di classi della componente grafica diventa simile alla precedente.

Come considerazione finale, mentre una componente state dovrebbe essere unica per ogni entità, una componente grafica potrebbe essere condivisa tra più entità così da evitare la duplicazione di questo tipo di oggetti che occupa molto spazio in memoria.

Benvenuti su questo nuovo devlog sullo sviluppo di ncJump. Precedentemente ho scritto sui miglioramenti della camera e sulla serializzazione dello stato del gioco, e ho concluso menzionando di essere in grado di cominciare a creare dei livelli veri e propri. Un po’ di bug fixing e miglioramenti generici erano necessari in vari aspetti del codice, ma sono riuscito a modellare qualcosa di interessante che, sebbene possa semprare incompleto, si tratta di una base convincente.

Salta più in alto

Dal punto di vista del gameplay, il giocatore prende confidenza con gli elementi di interattività del gioco. Dapprima si muove, poi salta, poi salta più in alto. L’implementazione è semplice grazie a Box2D. Se il pulsante di salto è ancora premuto, continua ad applicare una piccola forza diretta verso l’alto. Si tenga a mente che tale forza dovrebbe essere più debole della forza di gravità altrimenti il personaggio decollerebbe nello spazio.

void can_jump_higher(Input& input, Entity& entity) {
  if (input.jump.down) {
    auto force = b2Vec2(0.0f, small_amount);
    entity.physics->body->ApplyForceToCenter(force, true);
  }
}

Ridimensionare la tilemap

Questo è stato meno semplice. Sto cominciando a credere che maggiore qualcosa sia noiosa, maggiore sia la difficoltà dell’implementazione. Molte cose devono essere prese in considerazione. Per semplicità qui mi concentrerò solo sulla griglia dei tile concreti.

All’inizio usavo un semplice vettore per conservare i tile concreti della mappa e con una semplice formula (y + x * height) ero in grado di accedere ad una cella della griglia. Poi ho realizzato che ridimensionare questo vettore non era conveniente dal momento che l’ordine dei tile nelle celle non sarebbe stato conservato.

Come soluzione, ho cambiato la struttura da semplice vettore a vettore di vettori, ovvero una lista di colonne. Ciò ha semplificato l’indicizzazione visto che si può usare il subscript operator per accedere al tile giusto (tiles[x][y]).

Ha anche semplificato il ridimensionamento. Se si vuole cambiare la lunghezza della tilemap, basta modificare il numero di colonne invocando tiles.resize(new_width). Come si può immaginare, se la larghezza diminuisce, si perdono le colonne, mentre se la larghezza aumenta, si ottengono nuove colonne con un tile concreto di default. Non posso sorvolare sull’importanza dei valori di default. Cambiare l’altezza è leggermente differente dato che si devono ridimensionare tutte le colonne.

for (uint32_t i = 0; i < width; ++i) {
  tiles[i].resize(new_height);
}

Spero che questo devlog vi sia piaciuto. Stay tuned per il prossimo in cui tratterò di entità dinamiche!

È passato un po’ dal mio ultimo devlog, ma finalmente ne ho scritto uno nuovo. È pieno di cose interessanti quindi l’attesa si farà ripagare. Let us ncJump into it!

Dying state

Sicuramente uno degli stati fondamentali. Ogni entità vivente dovrebbe morire a un certo punto, e questo stato rappresenta quel lasso di tempo in cui un’animazione dovrebbe essere mostrata per dire al giocatore che un nemico è sconfitto o che il gioco è finito. Il metodo di update di questo stato è semplicissimo:

void DyingState::update(Entity& entity)
{
    if (entity.animation.has_finished()) {
        entity.set_enabled(false);
        // just reuse this entity for something else
    }
}

Enabled flag

Questo ovviamente spiega il metodo Entity::set_enabled() appena introdotto nella sezione precedente. Invocandolo, possiamo effettivamente disabilitare un’entità e tutte le sue componenti senza distruggere nulla, o rilasciare memoria, cosicché possa essere riciclata e riusata successivamente quando, per esempio, dobbiamo spawnare un’altra entità.

Array of states

Questa è stata un’importante ottimizzazione. Prima, ogni transizione di stato innescava la distruzione del vecchio stato e la creazione del nuovo stato, cosa non proprio necessaria e non scala col crescere della scena. Ora, lo state component tiene traccia di un array di tutti gli state objects possibili, insieme a un puntatore che ci indica quale sia lo stato corrente.

Initial position

Un altro requisito della scena consiste nel definire dove dovrebbe apparire il personaggio. La posizione iniziale è una coppia di coordinate che ci dice esattamente questo. Quando la scene inizia, mettiamo il personaggio lì.

Definitions and factories

Adoro questo pattern e penso che lo userò d’ora in poi per tutti i miei progetti. In pratica, abbiamo a che fare con oggetti grossi e pesanti non proprio facili da serializzare. Si pensi a dei wrapper per componenti third-party come Box2D bodies o nCine sprites. Ho provato a trovare un modo di serializzare questi oggetti e penso di aver trovato una soluzione niente male che in realtà è molto usata, quindi probabilmente ho solo reinventato la ruota qui, ma va bene.

Non serializzo questi oggetti. Serializzo le loro definizioni. Una definizione è una collezione di tutti i parametri necessari alla costruzione dell’oggetto. Prendiamo come esempio un graphics component di ncJump.

// Very simplified
auto def = GraphicsDef(GraphicsType::TILE);
def.path = String("image.png");
def.layer = 2;
auto gfx = GraphicsComponent(def);

Come si puo vedere, il costruttore del graphics component prende un graphics definition come parametro. Un graphics definition, come tutte le altre definizioni, e’ un Plain Old Data (POD) structure, che permette l’uso di nlohmann macros per definire automaticamente tutte quelle funzioni necessarie alla serializzazione. Fatto. Fantastico.

// That's it
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(GraphicsDef, type, path, layer);

CI and automatic deploy

This will blown your mind, poiché il progetto ora compila automaticamente, mediante GitHub actions, per Linux, Window, MacOS, Android, e che ci crediate o no per il web. Infatti, cliccate qui e preparatevi a dire wow. Tutto il merito di questa roba qua va all’eccezionale autore dell’nCine: @encelo!