Introduzione

Il punto di inizio per imparare il BGE è capire come funziona, cosa viene calcolato per ogni frame (chiamati anche tick), che è un’unità di misura pari ad una frazione di secondo, nel classico 60fps sono appunto 60 in 1 secondo, da qui è facile calcolare la durata di un Loop o un’animazione.

Quello che leggerai in questa pagina è una traduzione di un PDF che ho scaricato da blenderartist.com creato da Monster anni fa ma resta un valido supporto.

Il Game Loop

Ogni Loop viene eseguito per ogni singolo frame dell’esecuzione del gioco, questo vuol dire che ogni frazione di secondo il motore di gioco calcola in tempo reale una serie di dati, più ottimizzati sono i dati da calcolare più il gioco sarà fluido. Nel diagramma di flusso seguente si vede l’esecuzione del loop generale :

Quando il gioco inizia si innesca il Game Loop, la prima cosa che viene processata è la Scenes loop (la vedremo in dettaglio più avanti), vengono controllati gli input (mouse e tastiera) ed infine viene renderizzato 1 fotogramma, la sequenza di 60fps rende la scena fluida all’occhio umano, ma quello che interessa a noi è che ogni singolo tick del motore di gioco vengono processati parecchi dati (quanti dipende anche da noi) e se i dati prima del Render finale occupano troppo tempo di calcolo il frame può essere saltato, da qui il famoso lag o rallentamento, è possibile vedere per qualche attimo l’immagine ferma il motivo è perché il motore sta calcolando qualcosa. C’è un limite di quanti Renders si possono saltare prima che venga in effetti bloccata l’esecuzione anche della Logica, se si preme un pulsante il gioco non risponde, questo limite di default è 5, si trova nella tab del World, nella tab Physics Logic Step.

Scene Loop

Questo invece è quello che accade nella Scene loop. La logica nell’immagine a fianco è racchiusa nella triade SCA (sensor-controller-actuator) viene eseguita per prima SEMPRE nello stesso ordine SCA. Poi è il turno della fisica (se implementata) e in fine il suono.

L’ordine è sempre lo stesso, tienilo a mente

  • Non vedrai mai l’esecuzione di un Controller prima che un Sensor sia valutato.
  • Non vedrai mai un’Actuator attivato prima che tutti i Controller siano eseguiti.
  • La Fisica viene aggiornata dopo che tutti gli Actuators sono stati eseguiti, ma prima che viene disegnato il Render. E ci da la possibilità di capire quando viene calcolata una collisione.

Triade SCA

 sensors_valutazione

I Sensors attivi saranno SEMPRE valutati indipendentemente dai parametri impostati. Non esiste un parametro che previene che un Sensor venga valutato ogni frame; queste due frasi suonano un pò come monito, riportano però interessanti spunti, adesso sappiamo che un Sensor viene valutato. Poi prosegue.

Questo significa se un Sensor non è connesso a nessun Controller di uno State Mask attivo non viene valutato. Questo può tornare utile se si vuole fermare la valutazione di un Sensor pesante come Radar o Ray.

Dipende poi da quali parametri di valutazione i Sensors inviano un impulso ai Controller collegati.

Tutti i Controllers che ricevono un impulso vengono eseguiti, indipendentemente se il segnale è True o False.

Solo i Controllers che ricevono l’impulso saranno eseguiti, indipendentemente se il segnale è True o False.

Non esiste modo di eseguire un Controller che non ha ricevuto un’impulso da un Sensor. Di conseguenza è importante scegliere il giusto Sensors per il Controllers.

I Controller che vengono eseguiti inviano l’attivazione o la disattivazione agl’Actuators collegati in accordo con l’input ricevuto dai Sensors.

Attivazione e disattivazione sono input che provengono dai Controllers collegati. Per questo si chiamano segnale di attivazione e segnale di disattivazione. Ricevuti questi segnali non è detto che l’Actuator si attiva o disattiva. Questo dipende dall’implementazione e dai parametri dell’Actuator.

Per quanto tempo un’Actuator resta attivo dipende dal tipo e da parametri da noi impostati.

Ci sono Actuator che si disattivano dopo 1 frame, altri che aspettano il segnale di disattivazione e altri che rimangono attivi troppo a lungo da ignorare il segnale di disattivazione; nel testo originale è scritto così, probabilmente si riferisce al fatto che alcuni Actuator vanno in loop e quindi fino alla durata dell’oggetto resteranno in glitch.

Python contro SCA

Il concetto di SCA (sensor-controller-actuator) costruisce un sistema di eventi molto efficente. Permette di separare gli eventi derivati da calcoli. L’esecuzione intensa delle risorse è calcolata solo se necessario.

L’interfaccia grafica di Blender permette un facile settaggio della logica.

Ma per la natura dell’interfaccia stessa la logica è limitata da True/False dello stato del Sensor e dei segnali d’attivazione e disattivazione dei Controller.
Per aumentare la flessibilità c’è l’opzione di usare il Python come un Mattone. Purtroppo è disponibile solo come Controller, in questo modo ci si può creare un Controller personalizzato.

Inoltre quel Python Controller può eseguire le azioni degl’Actuators. Il che vuol dire che può cambiare lo stato del gioco. Cosa che solo gli Actuator posso fare.

Se riguardi la parte dello Sceen Loop, vedi che i Controllers sono eseguiti prima che gl’Actuators vengano attivati. Questo significa che il codice viene interpretato prima che l’Actuator venga attivato. E’ una piccola cosa, ma molto importante.

Suggerimenti per il Python

Notare che :

Alcuni cambiamenti nel gioco non sono processati immediatamente (esempio : cancellare un oggetto, cambiare scena). Sono messe in coda e verranno processate in seguito o in un momento migliore. Questo può portare un pò di confusione.

Per la Performance :

Il codice Python deve essere terminato il prima possibile.

Codici troppo lunghi rallentano il gioco causando del lag.

Un loop infinito può causare il blocco del gioco.

E’ più veloce eseguire un Controller che eseguire un Controller che non fa niente. Per questo è importante scegliere il Sensor giusto. Evitare i collegamenti non necessari con Controllers. Tieni a mente che il Controller Python è il più “pesante” in termini di tempo di calcolo.

I Mattoni logici sono di solito più veloci del codice Python. Per questo è raccomandato di non ricreare Mattoni già esistenti (esempi : And Controller, Motion Actuator). La strada migliore di solito è quella di cambiare le opzioni di ogni singolo Actuators sopratutto se non cambia mai.

Il Python può essere più efficente se un pezzo di codice processa in uno step una serie di Logic Bricks (esempi : convalidare l’input da tastiera, aggiungere oggetti multipli alla scena).

Panoramica

In fine i due loop nella stessa immagine :

Avete forse perso i dettagli sul Render ? E’ escluso in questo file perchè i dettagli del Render non sono importanti per la logica di gioco.

Tieni a mente :

Gli Shaders non influenzano la logica o la fisica.

La logica influenza gli Shaders.

Nell’ultima pagina ci sono saluti e in bocca al lupo a chi vuole dedicarsi alla creazione di gioco con il BGE.

Partendo da questa base logica inizierò un percorso legato ai Mattoni Logici e come creare questa fantomatica logica snella che dice Monsters nel suo file, saranno inclusi gli State e le Properties, perchè per creare una logica come si deve bisogna impastare tutto molto bene.

Qui il link per scaricare il file originale