"Prototipando 'sta roba" parte II - I macelli

In questi giorni son stati fatti dei progressi, seppur nessun traguardo rilevante sia ancora stato toccato.

Ciò che ha portato via molto tempo è stato un lavoro abbastanza pesantuccio di ristrutturazione del codice.

Molti problemi erano scaturiti dal fatto che non stavo "ragionando ad oggetti". I metodi che gestivano l'IA del nemico erano... "metodi volanti", senza capo né coda. Non appartenevano ad alcuna classe, a nessun oggetto che fosse il nemico. I nemici, quando dovevano muoversi o fare qualsiasi altra cosa, richiamavano metodi di un altro oggetto che li gestiva. In sintesi? Si davano il turno, perché i metodi, facenti parte di un oggetto esterno, erano condivisi da TUTTI gli altri oggetti "nemico".

E' come se ciascun nemico avesse dovuto rendere conto ad uno sportello per poter registrare l'azione, che so, di "ronda". C'erano tutti questi nemici in coda, bloccati ad uno sportello che attendevano che il prossimo in fila finisse prima di passare davanti. Questo perché solo ed unicamente quello sportello gestiva le direttive. Quindi "sì, siamo una squadra di ricerca che si coordina, ma finché io non ho finito il mio, tu il tuo non lo fai". Efficienza zero.

Almeno, mi dava un problema del genere.

Quindi niente, ho dovuto spostare e riadattare tutto per la classe che gestiva il nemico, così che ogni oggetto "nemico" avesse le proprie funzioni, i propri campi, ecc.

Ora non c'è alcun "sportello" e i singoli nemici devono render conto solo a sè stessi (e possibile team leader se vengono assemblate squadre di ricerca).
Più logico, decisamente.

E son banalità, eh. Cose a cui avrei dovuto pensare molto prima...

Quindi, devono agire da soli durante un'operazione di ricerca senza attendere che finiscano gli altri? Possono farlo. Hanno le proprie direttive ora, i propri metodi.

Ho risolto anche un problema molto scomodo che rendeva i nemici "ciechi" mentre portavano a compimento azioni abbastanza complesse.

Parlando potabile: ora i nemici si organizzano meglio di prima.
Per quanto concerne la loro capacità di organizzarsi in squadra e andare ad investigare, è stato portato avanti il sistema ma presenta delle problematiche. Figurati se c'azzeccavo al primo colpo...
E si parla di problematiche a livello di algoritmi. Quindi ci sarà parecchia roba da rifare. *Sigh*

Ma io procedo imperterrito. L'idea è riuscire ad avere un prototipo semi-decente prima di cominciare la stagione lavorativa. Ciò taglierà di brutto il mio tempo libero e allora saran rogne se non avrò una base pronta...

"Prototipando 'sta roba" parte I - L'udito nemico

Terminata sceneggiatura, lo scheletro delle cutscene, stilato un numero provvisorio di possibili missioni e rilasciato quel platformino 2D di nome Drill Guy, si ritorna al prototipo di Gameplay di Karma Flou Two!

In un gioco di questo tipo, uno Stealth Game, è molto importante che i nemici siano svegli il minimo indispensabile. E per minimo indispensabile s'intende la capacità di accorgersi quando qualcosa non va o quando... chessò, un agente nemico fa esplodere mezza città lì vicino.

Era uno dei problemi del primo Karma Flow, la mancanza di nemici reattivi a ciò che li circondava. L'unica cosa che garantiva un'allerta era il contatto visivo con il giocatore e nient'altro. I nemici vedevano (solo ed unicamente il giocatore), ma non sentivano e non si organizzavano.

Non era una caratteristica che riuscii ad implementare nel primo capitolo, causa poco tempo a disposizione prima di consegnare il lavoro (Karma Flow fu creato per una competizione con tempo limite di consegna). Non decisi di implementarla nemmeno in seguito con le nuove patch per un semplice motivo: ormai tutto il gioco era stato tarato per non prevedere quella caratteristica. Calibrazione della difficoltà e Level Design, più generalmente gran parte del Game Design del gioco, furono studiati sapendo che il nemico a) non sentiva, b) non si organizzava con gli altri.

C'è anche tutta la questione della difficoltà a programmare queste cose con un linguaggio visuale come quello di RPG Maker 2003. Questo è uno dei motivi cardine che mi hanno portato a spostarmi sul VX Ace e a sfruttare il suo linguaggio di scripting, l'RGSS3. Sto, quindi, cercando ora di dare un minimo d'intelligenza a quei nemici maledetti. Niente di esageratamente elaborato, ma vorrei quantomeno renderli più reattivi.

In questi ultimi giorni ho introdotto un sistema d'udito che permette ai nemici di sentire e di agire di conseguenza in base al suono. Nel senso che ci sarà una bella differenza per loro tra il sentire dei passi e il sentire un'esplosione del Dio della muerte.

Sentono dei passi? Niente, si girano, neanche troppo allarmati. Non notano il giocatore? Finisce lì.
Sentono degli spari? Vanno a controllare, chissà che non sia proprio l'assassina che stanno cercando.
Sentono un'esplosione? Qui le cose si fanno più pericolose. Decidono di formare quindi una squadra per andare a controllare.

E qui 'sta la rogna, programmare la squadra di ricerca.
Per ora è abbastanza basilare, si forma la squadra, si raggiunge la zona dove il suono finale distruttivo è accaduto e si controllano i dintorni, in maniera neanche troppo approfondita o certosina (ma quanto basta per fare presenza e rompere le scatole un minimo).

Purtroppo, le variabili anche qui son tantine da gestire.
"E se non posso raggiungere il luogo da cui arriva il suono anche se è nelle vicinanze?"
"E se non riesco efficacemente a coordinarmi con gli altri e passare al setaccio l'area in maniera intelligente?"
"E se finisco a voler controllare un pezzo di terra lì vicino senza però rendermi conto che devo fare un giro per casa di Dio prima di raggiungerlo?"
"E se uno della mia squadra morisse? All'adunata me ne accorgerei, no? E quindi?"

E sono solo alcuni dei quesiti che uno dei nemici potrebbe porsi... se riuscissi a renderlo EFFETTIVAMENTE intelligente. Ma a questi livelli ci sarebbe d'aver paura.

E comunque...
Oggi ho terminato di programmare lo scheletro dello scheletro dello scheletro.

I nemici fan quel che devono fare, ma ancora in maniera molto "rozza" e... rimangono appunto i quesiti che vien da porsi là sopra.

C'è anche da gestire i casi in cui, magari, quelli della squadra di ricerca sentono altri tipi di suoni PROPRIO mentre stanno già andando a controllare per l'esplosione appena avvenuta.
Una gran. bella. rogna.
(In realtà, quest'ultimo caso è gestito un poco ora come ora... ma neanche abbastanza).

Nonostante tutto, è già un qualcosa di più avanzato rispetto a quanto visto su Karma Flow - The Prototype.

 

(Grafica ovviamente "placeholder").

Qua un nemico/bambina chibi ha chiamato altri suoi compari per andare a controllare un luogo dove pare sia avvenuta un'esplosione. Solo un nemico si presenta all'appello. Se lo fa bastare e ordina di passare al setaccio.

Quindi sì, insomma. Le guardie sentono i rumori, si muovono, hanno un pathfinding decente per OGNI tipo di movimento che voglion fare ma... mancano tutti i dettagli per renderli... meno rozzi? Dare loro movimenti più plausibili, evitare che s'incastrino per delle caspionate, cose così.

Dai, dai. Siamo solo agli inizi... *sigh*

E infine, ci siamo! (Parte II)

Giorno a tutti, ragazzi!

Ho deciso di dare oggi il via ad un Dev Blog dedicato ad un progetto videoludico che sto portando avanti già da un bel po’ di tempo, Karma Flow.

Il blog fungerà da “diario di sviluppo”. Ho intenzione di scriverci sopra man mano che verranno fatti progressi, con aggiornamenti sullo stato dei lavori e a volte spiegazioni esaustive di cosa ho fatto e perché l’ho fatto in quella determinata fase dello sviluppo… insomma, cose così. E probabilmente non disdegnerò “dell’off-topic” di tanto in tanto.

Attualmente, mi sto concentrando sullo sviluppo del secondo capitolo della saga, Karma Flow 2 – Steel Skin. Il primo capitolo, The Prototype, è disponibile per il download qui.

Se cercate maggiori info su Karma Flow e volete capire di che caspio di gioco si tratta, fate un salto qui.

Vi saluto e vi ringrazio per l’eventuale interessamento.^^