Advertisement
  1. Game Development
  2. Programming
Gamedevelopment

Creare un Neon Vector Shooter in jMonkeyEngine: Nemici e Suono

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Cross-Platform Vector Shooter: jMonkeyEngine.
Make a Neon Vector Shooter in jMonkeyEngine: The Basics
Make a Neon Vector Shooter With jME: HUD and Black Holes

Italian (Italiano) translation by Chip (you can also view the original English article)

Nella prima parte di questa serie sulla crazione di un gioco ispirato a Geometry-Wars con jMonkeyEngine, abbiamo implementato l'astronave del giocatore e la abbiamo fatta muovere e sparare. Questa volta, aggiungeremo i nemici e gli effetti sonori.


Panoramica

Ecco a cosa lavoreremo per tutta la serie:


... sd ecco a cosa arriveremo alla fine di questa parte:


Per implementare le nuove caratteristiche, avremo bisogno di alcune nuove classi.

  • SeekerControl: Questa è una classe per il comportamento del "nemico ricercatore".
  • WandererControl: Anche questa è una classe per il comportamento, questa volta per il "nemico nomade".
  • Sound: Gestiremo il caricamento e la riproduzione di effetti sonori e musica con questa classe.

Come si può immaginare, aggiungeremo due tipi di nemici. Il primo si chiama seeker (cercatore); inseguirà attivamente il giocatore fino a quando non muore. L'altro, il wanderer (viandante, che vagabonda), si aggira intorno allo schermo in maniera casuale.


Aggiunta dei nemici

Creeremo i nemici in posizioni casuali sullo schermo. Al fine di dare al giocatore un certo tempo per reagire, il nemico non sarà attivo immediatamente, bensì si esaurirà lentamente. Dopo che è sbiadito completamente, inizierà a muoversi nel mondo. Quando si scontra con il giocatore, il giocatore muore; quando si scontra con un proiettile, muore lui.

Generazione dei nemici

Prima di tutto, abbiamo bisogno di creare alcune variabili nuove nella classe MonkeyBlasterMain:

Arriveremo ad usare i primi due abbastanza presto. Prima, dobbiamo inizializzare enemyNode nella simpleInitApp():

Okay, ora andiamo sul codice di generazione dei nemici: sovrascriviamo simpleUpdate(float tpf). Questo metodo viene chiamato dal motore più e più volte, e semplicemente continua la sua funzione di produrre nemici fintanto che il giocatore è vivo. (Avevamo già impostato i dati utente alive a true nell'ultimo tutorial.)

E questo è come generiamo i nemici:

Non lasciatevi confondere dalla variabile enemySpawnCooldown. Non è lì per fare generare nemici con una frequenza discreta di 17ms, sarebbe troppo breve come intervallo.

enemySpawnCooldown è in realtà lì per garantire che la quantità di nuovi nemici sia la stessa su ogni macchina. Su computer più veloci, simpleUpdate(float tpf) viene chiamata molto più spesso rispetto a quelli più lenti. Con questa variabile, controlliamo circa ogni 17ms, se dobbiamo generare nuovi nemici.
Ma vogliamo generare nemici ogni 17ms? Noi in realtà vogliamo generarli casualmente, quindi introduciamo un'istruzione if:

Minore è il valore di enemySpawnChance, più è probabile che un nuovo nemico si riproduca in questo intervallo di 17ms e quindi più nemici che il giocatore dovrà affrontare. Ecco perché sottraiamo un pò di enemySpawnChance ad ogni tick (n.d.a. unità che indica un singolo frame aggiornato): significa che il gioco otterrà più difficile nel corso del tempo.

Creare seekers e wanderers è simile alla creazione di qualsiasi altro oggetto:

Creiamo uno spatial, lo muoviamo, aggiungiamo un controllo personalizzato, lo impostiamo come non-attivo, e lo attribuiamo al nostro enemyNode. Cosa? Perché non è attivo? Questo perché non vogliamo che il nemico inizi ad inseguire il giocatore non appena si genera; vogliamo dare al giocatore un pò di tempo per reagire.

Prima di addentrarci nei controlli, abbiamo bisogno di implementare il metodo di getSpawnPosition(). Il nemico deve generarsi in modo casuale, ma non proprio accanto al giocatore:

Calcoliamo una nuova posizione casuale pos. Se è troppo vicino al giocatore, si calcola una nuova posizione e ripetiamo il tutto finché non è ad una distanza decente.

Ora abbiamo solo bisogno che i nemici si attivino iniziando a muoversi. Lo faremo nei loro controlli.

Controllo del comportamento dei Nemici

Ce ne occuperemo prima con il SeekerControl:

Concentriamoci sucontrolUpdate(float tpf):

In primo luogo, abbiamo bisogno di verificare se il nemico è attivo. Se non lo è, dobbiamo dissolverlo in ingresso lentamente (n.d.a. "fade out"=dissolvenza, "fade in"=assolvenza ma non si usa).
Poi controlliamo il tempo trascorso da quando abbiamo generato il nemico e, se è abbastanza a lungo, lo impostiamo come attivo.

Indipendentemente dal fatto che è stato attivato, abbiamo bisogno di regolarne il colore. La variabile locale spatial contiene lo spaziale a cui il controllo è stato attaccato, ma dovreste ricordare che non abbiamo agganciato il controllo all'immagine attuale, l'immagine è un figlio del nodo a cui abbiamo allegato il controllo. (Se non sapete di cosa sto parlando, date un'occhiata al metodo di getSpatial (String name) che abbiamo implementato nello scorso tutorial.)

Così; otteniamo l'immagine come figlio di spatial, otteniamo il suo materiale ed impostiamo il suo colore al valore appropriato. Niente di speciale, una volta che vi sarete abituati agli spatials, materiali e nodi.

Info: Vi chiederete perché abbiamo impostato il colore del materiale a bianco. (I valori RGB sono tutti 1 nel codice). Non vogliamo un un nemico giallo e uno rosso?
E' perché il materiale mescola il colore del materiale stesso con i colori della texture, quindi se vogliamo visualizzare la trama del nemico così com'è, abbiamo bisogno di mescolarlo ad uno sfondo bianco.

Ora abbiamo bisogno di dare un'occhiata a quello che facciamo quando il nemico è attivo. Questo controllo è chiamato SeekerControl per un motivo: vogliamo che i nemici con questo controllo collegato inseguano il giocatore.

A questo fine, calcoliamo la direzione dal seeker al giocatore e aggiungiamo questo valore alla velocità. Dopo di che, riduciamo la sua velocità del 80% in modo che non cresca all'infinito e spostiamo il seeker di conseguenza.

La rotazione non è niente di speciale: se il seeker non è ancora in piedi, lo ruotiamo nella direzione del giocatore. Quindi lo ruotarlo un pò di più, perché il seeker nel Seeker.png non è rivolto verso l'alto, ma a destra.

Info: Il metodo rotateUpTo(Vector3f direction) di Spatial ruota uno spaziale in modo che il suo asse y punti nella direzione data.

Questo per il primo nemico. Il codice del secondo nemico, il wanderer (errante, viandante), non è molto diverso:

Prima la roba facile; la dissolvenza in ingresso del nemico è la stesso del controllo del seeker (ricercatore). Nel costruttore, abbiamo scelto una direzione casuale per il wanderer, verso cui volerà una volta attivato.

Suggerimento: Se si dispone di più di due nemici, o semplicemente desiderate strutturare il gioco in modo più pulito, si potrebbe aggiungere un terzo controllo: EnemyControl che gestirebbe tutto quello quello che i nemici hanno in comune: il movimento del nemico, la dissolvenza in ingresso, l'attivazione ...

Ora le principali differenze:

Quando il nemico è attivo, prima cambiamo un pò la sua direzione, in modo che il wanderer non si muova in linea retta per tutto il tempo. Lo facciamo cambiando directAngle un pò e aggiungendo la directionVector alla velocity. Poi applichiamo la velocità, proprio come facciamo nel SeekerControl.

Dobbiamo verificare se il wanderer è al di fuori dei confini dello schermo e in caso affermativo, cambiamo il directionAngle in una più appropriata in modo che venga applicata al prossimo aggiornamento.

Infine, ruotiamo un pò il wanderer. Solo perché un nemico ruotante è più carino.

Ora che abbiamo finito l'implementazione dei due nemici, è possibile avviare il gioco e giocarci un pò. Ti dà un pò l'idea di come sarà il gioco, anche se ancora non possiamo uccidere i nemici e loro non possono uccidere te. Aggiungiamo il prossimo.

Rilevamento Collisioni

Per rendere i nemici capaci di uccidere il giocatore, abbiamo bisogno di sapere se collidono tra loro. Per questo aggiungeremo un nuovo metodo, handleCollisions, chiamato nel simpleUpdate(float tpf):

E ora il metodo:

Dobbiamo iterare tutti i nemici avendo contato i figli del nodo e raggiungendoli uno ad uno. Dobbiamo solo controllare se il nemico uccide il giocatore quando il nemico stesso è attivo. Se non lo è, non ci interessa. Quindi, se è attivo, controlliamo se il giocatore e il nemico si scontrano. Questo lo facciamo in un altro metodo, checkCollision(Spatial a, Spatial b):

Il concetto è abbastanza semplice: in primo luogo, si calcola la distanza tra i due spatials. Abbiamo bisogno di sapere quanto vicino devono essere i due spatials per considerarli in collisione, quindi otteniamo i raggi di ogni spaziali e li sommiamo. (Abbiamo impostato tra i dati utente "radius" nel getSpatial (String name) nel precedente tutorial.) Quindi, se la distanza effettiva è inferiore o uguale a questa distanza massima, il metodo restituisce true, il che significa che si sono scontrati.

E adesso? Abbiamo bisogno di uccidere il giocatore. Creiamo un altro metodo:

In primo luogo, rimuoviamo il player dal suo nodo padre, questo lo rimuove automaticamente dalla scena. Quindi, abbiamo bisogno di ripristinare il movimento nel PlayerControl, altrimenti, il giocatore potrebbe ancora muoversi quando si rigenera di nuovo.

Quindi impostiamo il dato utente alive su false e creariamo un nuovo dato utente dieTime. (Ne abbiamo bisogno per il respawn del giocatore quando è morto)

Infine, stacchiamo tutti i nemici, poiché per il giocatore sarebbe difficile combattere subito con nemici già esistenti appena viene rigenerato.

Oltre ai già citati respawning, cerchiamo di gestire il prossimo. Ci sarà, ancora una volta, da modificare il metodo simpleUpdate(float tpf):

Quindi, se il giocatore non è vivo ed è rimasto morto abbastanza a lungo, impostiamo la sua posizione al centro dello schermo, lo aggiungiamo alla scena, e, infine, impostiamo nuovamente il suo dato utente (userdata) alive a true!

Ora potrebbe essere un buon momento per avviare il gioco e testare le nostre nuove funzionalità. Per circa venti secondi avrete difficoltà, perché lo sparo è inutile, quindi cerchiamo di fare qualcosa a riguardo.

Al fine di rendere i proiettili capaci di uccidere i nemici, aggiungeremo del codice del handleCollisions():

La procedura per uccidere i nemici è più o meno la stesso che per uccidere il giocatore; iterare tutti i nemici e tutti i proiettili, verificare se si scontrano e, se lo fanno, li sganciamo entrambe.

Ora eseguiamo il gioco e vediamo quanto lontano andiamo!

Info: Iterare ogni nemico confrontando la sua posizione con la posizione di ogni proiettile è un pessimo modo per verificare la presenza di collisioni. Per semplicità va bene per questo esempio, ma in un vero e proprio gioco avremmo dovuto implementare algoritmi migliori, come il rilevamento di collisioni quadtree. Fortunatamente, jMonkeyEngine utilizza il motore fisico Bullet, così ogni volta che avremo della fisica 3D complessa, non ce ne dovremo preoccupare molto.

Con il gameplay principale abbiamo finito. Andremo ad implementare i buchi neri, a visualizzare il punteggio e la vita del giocatore, poi per rendere il gioco più divertente ed emozionante aggiungeremo alcuni effetti sonori ed una grafica migliore. Queste ultime cose le otterremo con un filtro di trasformazione bloom post processing, alcuni effetti particellari ed un effetto al background molto bello.

Prima di considerare questa parte della serie finita, aggiungeremo un pò di audio e l'effetto bloom.


Riproduzione di Suoni e Musica

Per l'audio del vostro gioco creeremo una nuova classe, chiamata semplicemente Sound:

Qui cominciamo impostando la variabile AudioNode e inizializzando gli array.

Quindi, carichiamo i suoni, facendo la stessa cosa più o meno per ogni suono. Creiamo un nuovo AudioNode, con l'aiuto del assetManager. Poi, lo impostiamo non posizionale e disabilitiamo il riverbero. (Non abbiamo bisogno che il suono sia posizionale perché non abbiamo uscita stereo nel nostro gioco 2D, anche se sarebbe possibile implementarlo, se vi piace.) La disattivazione del riverbero rende la riproduzione il suono così come è nel file; se attivo potremmo fare suonare a jME l'audio come se ci trovassimo in una grotta o in un sotterraneo, Dopo di che, abbiamo impostato il looping a true per la musica e a false per qualsiasi altro suono.

Suonare i suoni è piuttosto semplice: ci basta chiamare soundX.play().

Info: quando semplicemente chiamiamo play() su qualche suono, questo riproduce il suono. Ma a volte vogliamo giocare lo stesso suono due volte o anche più volte contemporaneamente. Questo è ciò che playInstance() fa: crea una nuova istanza per ogni suono in modo che lo si possa suonare lo stesso più volte allo stesso tempo.

Lascio il resto del lavoro a voi: è necessario chiamare startMusic, shoot(), explosion() (per uccidere i nemici), e spawn() nei punti appropriati della nostra classe principale MonkeyBlasterMain().

Quando avrete finito, vedrete che il gioco è ora molto più divertente; quei pochi effetti sonori aggiungono davvero molto all'atmosfera. Ma cerchiamo di pulire un pò di più la grafica.


L'aggiunta del filtro Bloom post-processing

L'attivazione del boom è molto semplice in jMonkeyEngine, poiché tutto il codice e gli shader necessari sono già implementati. Basta proseguire ed incollare queste righe in simpleInitApp():

Ho configurato il BloomFilter un pò; se volete sapere che cosa fanno queste impostazioni, dovreste dare un'occhiata al tutorial jME sul bloom.


Conclusioni

Congratulazioni per aver finito la seconda parte. Ci sono ancora altre tre parti da affrontare, quindi non distraetevi giocando troppo! La prossima volta aggiungeremo l'interfaccia grafica e i buchi neri.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.