[FAN GAME] Untitled project pokemon: Cottagecore

[sadriparian]

Salve a tutti, sono SadRiparian aspirante designer (e game dev in generale). Seguendo la community delle hack roms e poi successivamente dei giochi costruiti con RPG maker e Pokemon Essentials ho sempre sentito la mancanza di qualcosa di diverso, specialmente perché l'intera produzione di giochi Pokémon ha sempre sfruttato poco le sue carte a mio parere.  Per questo oggi vi presento un'idea per un "piccolo" fan game diverso. 

 

Concept

L'idea è quella di combinare la varietà e il contesto Pokémon con alcune meccaniche tratte dai giochi che vengono chiamati cottagecore, ossia giochi dal contesto leggero, rasserenante, chill, ambientati spesso nel contesto campagnolo, ma con una loro profondità. In questo genere figurano titoli come Harvest Moon, Stardew Valley, Animal Crossing.

 

Realizzazione

L'idea è quella di sviluppare piano piano il design in contemporanea alla realizzazione. Tecnicamente sarà realizzato con Godot Engine e stilisticamente sarà realizzata in pixel art.

 

Scopo

Questo progetto nasce con l'idea di essere un piccolo hobby da portare avanti per migliorare le skill di design e la conoscenza dei mezzi tecnici e per ovvi motivi potrebbe non essere mai reso disponibile, ma il percorso nell'immaginazione e realizzazione di uno spin-off potrebbe essere una attività al quanto divertente da seguire.

 

--------------------------------------

 

[Report] - Aggiornamenti settimanali

Delle specie di dev log e riflessioni.

 

Spoiler

[Report] 01 - Primi Passi - Link

[Report] 02 - Barbeque - Link

 

--------------------------------------

 

Disclaimer!

Questo gioco non sarà probabilmente mai rilasciato in quanto concept e per motivi ovvi motivi di copyright.

 

--------------------------------------

 

FAQ

 

A quando nuovi aggiornamenti?

Nuovo aggiornamenti sullo stato del progetto saranno rilasciati ogni mercoledì (metà settimana circa).

 

Si può partecipare?

Chiunque avesse conoscenze in uno o più ambiti dello sviluppo di videogiochi e fosse interessat* a partecipare, presa consapevolezza che si tratti più di un gioco da portfolio che di uno che sarà rilasciato a tutti gli effetti, mi contatti su Discord: sadripa#1790

[SilverApricot]

Peccato che non abbia la benché minima competenza in programmazione, ma il progetto mi piace moltissimo 

Seguirò con piacere i progressi 

[sadriparian]

11 minuti fa, SilverApricot ha scritto:

Peccato che non abbia la benché minima competenza in programmazione, ma il progetto mi piace moltissimo 

Seguirò con piacere i progressi 

Grazie mille per l'interesse 

Spero di riuscire a essere continuativo con questo progetto.

 

Comunque ci tengo a sottolineare che nello sviluppo di videogiochi ci sono molti ambiti al di là della programmazione, che non considererei in alcun modo il mio punto forte.

[sadriparian]

[Report] 01 - Primi passi

Salve a tutti e benvenuti al primo [report]!

Innanzitutto premetto che sfrutterò questi Report per fare una specie di racconto sintetico dei vari momenti di sviluppo, piuttosto che una lista scarna di informazioni. L'idea è di rendere questo spazio intrattenente (dal momento che probabilmente che il gioco non vedrà mai la luce). Fatemi sapere se vi può piacere.

 

Premessa

Potrei definire questa settimana esplorativa. Diciamo che ho preso il progetto nel modo progettualmente più sbagliato possibile: ovvero procedere a programmare qualcosa senza aver pianificato nulla, senza aver prodotto dei succosi documenti di design. Detto questo, essendo il mio l'intento di fare un reskin, o meglio un mostro di Frankenstein, ed essendo più nel mood di imparare a fare delle cose più che farne già di buone: eccoci qui!

Troverete di seguito, in ordine cronologico, i vari step della settimana e possibili riflessioni.

 

 

 

A - Non avevo detto 3D?

Se avete letto il primo post, sì nella mia mente c'era l'idea di combinare un ambiente 3D (sempre texturizzato con pixel art), ma mi sono dovuto scontrare con la dura realtà: ho decisamente troppo poca esperienza con il 3D stesso per poter realizzare qualcosa, che anche solo a livello di prototipo, mi possa soddisfare. Onestamente le prove fatte non sono neanche troppo male, mal il distacco con la pixel art pura in 2D (per quanto riguarda le mie skill) non è troppo comparabile. Ho anche riflettuto sull'idea di utilizzare una camera ortogonale/isometrica, cioè una camera che rimuove il senso della profondità (l'altezza non decresce in lontananza), ma il risultato ottenuto è estremamente simile alla pixel art 2D e li dove il 3D risolve determinati problemi ne va a creare altri. Quindi: back to 2D baby!

 

---------------------------

 

 

B - Movimento e Camera

Il primo passo che ho fatto è stato quello di trasportare il player controller fatto per l'ambiente 3D in 2D. Si tratta di una passaggio veramente semplice considerato che quello fatto per il 3D tentava di emulare la camera fissa del 2D. Come si vede nella gif per ora ho realizzato solo un'animazione di corsa e una di idle. La camera è realizzata in modo da dare il senso di star seguendo il personaggio (di essere un po' in ritardo rispetto al suo movimento). É una tecnica molto usata in questo tipo di giochi. Che io sappia ci sono varie soluzioni per realizzarla, quasi tutte più production ready della mia, però sono orgoglioso del fatto che la camera invece di seguire il personaggio in realtà si allontana nella direzione opposta all'input 

 

---------------------------

 

 

C - Il mio primo Pokemon

Dopo aver implementato il movimento base è arrivato il momento di iniziare a creare la base per i veri protagonisti del gioco. La pokeball che vedete è la prima versione di Pokemon che ho realizzato. Lo scopo di questo era principalmente quello di implementare un behavior tree (BT) di base. Si tratta di uno dei pattern più utilizzati per definire il comportamento di oggetti all'interno di un gioco. Come vedete dalla targhetta in bianco a questo step si tratta solo di alternare randomicamente fra lo stare fermo e il vagare in un punto a caso. Per capire come mai ho voluto implementare un behavior tree dovrò elencare alcune delle cose che potranno fare i Pokemon in questo gioco:

• Saranno un po' dei "Pokemon da fattoria" nel senso che potranno vagare nell'ambiente in cui sono collocati e manteranno una propria routine basata sulla specie.
• I pokemon avranno delle abilità che saranno legate ai vari contesti della produzione agricola etc.
• Ai pokemon si potrà assegnare un compito (fra le abilità) che verrà portato avanti da questi autonomamente oppure...
• ... potranno essere convocati nella squadra (fino a 3) per utilizzare le varie abilità manualmente.

Per questi motivi ogni Pokemon avrà un albero comportamentale condiviso e poi "sotto rami" che definiscono comportamenti specifici della specie.

 

---------------------------

 

 

C - Menu radiale

Per motivi elencati sopra ecco la necessità di interagire con il Pokemon attraverso un click. Ho scelto di realizzare un piccolo menu radiale. Per come l'ho realizzato dovrebbe essere abbastanza flessibile e scalabile anche per Pokemon di dimensioni più ingenti (magari ad un certo punto si riesce a mettere un Blastoise che fa da irrigatore a propulsione). Nella gif vedete tre volte la stessa icona solo al fine di provare la disposizione automatica dato un numero massimo di icone (6-7 per esempio).

 

---------------------------

 

 

D - Join the team

A questo punto è arrivato il momento di far entrare i pokemon nel team. Una volta chiesto al pokemon di unirsi questo troverà il primo slot libero nel "party" e continuerà a seguirci. Questa funzionalità è realizzata attraverso tre oggetti invisibili che servono da segna posto nello spazio; questi tre oggetti hanno il compito di seguire un target quando più distanti di un tot (il primo segue il giocatore, il secondo segue il primo ecc.), mentre l'ordine di seguire queste posizioni rimane sempre all'interno del BT dei singoli Pokemon.

 

---------------------------

 

 

E - Dati

Ora che il comportamento è stato aggiornato è necessario pensare ad un qualche script che contenga le informazioni relative ai nostri Pokemon, come ad esempio il ritrattino da inserire nell'HUD una volta che il Pokemon è stato aggiunto al team. Questo file, insieme all'oggetto base su cui è costruito il Pokemon, sono estremamente importanti in quanto permettono di costruire quanti più Pokemon condividendo un'unica solida base. Si avrà infatti un unico oggetto al quale si passa il file con tutti i dati sul Pokemon e questo si inizializzerà automaticamente.

 

---------------------------

 

 

F - Oddish, scelgo te!

Per finalizzare la base di quello che è già stato fatto era necessario aggiungere i dati dello spritesheet/animazioni del Pokemon del file contenente i dati e settare le varie condizioni che gestissero il flusso delle animazioni e la direzione. Per questo compito è stato scelto il nobile Oddish che, in quanto palla con le gambe, risulta il soggetto veloce e perfetto da realizzare. Per ora è ancora tutto basic con una semplice animazione di camminata e una di idle. Nel aggiungere le varie condizioni ho dovuto sistemare un bug nel BT e migliorare lo script che permette di seguire il giocatore: siccome la posizione deve essere aggiornata ogni frame lo spazio percorso deve essere infinitamente piccolo per sembrare un movimento realistico, tuttavia la velocità giusta per il following causava una strana vibrazione una volta raggiunta la distanza ideale (inoltre se si guarda la gif sopra i Pokemon si muovo in maniera estremamente lineare a tratti). Per ovviare a questo problema ho creato più range per cui il Pokemon rallenta una volta vicino o accelera quando troppo lontano. In basso a sinistra si può anche vedere la simpatica faccina di Oddish (tax evader).

 

---------------------------

 

 

G - Orologio e Calendario

Ultimo punto della settimana è la base del sistema di tracciamento del tempo (in basso a destra). Il loop di gioco sarà basato sull'avanzare dei giorni (per la crescita delle coltivazioni/ Pokemon) e sull'alternanza di giorno e notte. Nello specifico questa alternanza prevede:

• Una fase di giorno dedicata alla coltivazione e al rapporto con i propri Pokemon
• Una fase notturna dedicata alla protezione dei propri raccolti dagli agguati di Pokemon golosi o altre insidie
• Inoltre i Pokemon potrebbero avere comportamenti diversi, specialmente in base a se il Pokemon sia diurno o notturno. Per esempio Oddish potrà essere convocato in team solo nella fase serale mentre avrà una sua funzione passiva durante il giorno (in quanto si rintana sotto terra).

Ad ogni modo il sistema si basa per ora su un rapporto semplice in cui un secondo nella realtà può corrispondere ad una certa quantità di secondi virtuali (nella gif ogni secondo corrisponde a tre minuti per mostrare il salto di giorno).

Il ragionamento su una possibile stagionalità è per ora da tenere via in quanto necessiterebbe di un lavoro quadruplo per gli asset visivi e sicuramente degli accorgimenti per rendere significativa a livello di gameplay l'esistenza delle stagioni stesse.

 

Con questo vi ringrazio per l'attenzione e rimando nuovi aggiornamenti alla prossima settimana.

Se avete suggerimenti, domande o altro lasciateli pure qua sotto.

 

[Riolu007]

Molto bello come progetto, non capisco nulla di programmazione Quindi alcune cose non le ho capite ma vabbè dai. Il progetto mi piace molto e seguirò con piacere il suo avanzare. Lo “schema” della fattoria mi ricorda questo gioco qui: 

Spoiler

 

[sadriparian]

On 14/7/2021 at 10:09, Riolu007 ha scritto:

Molto bello come progetto, non capisco nulla di programmazione Quindi alcune cose non le ho capite ma vabbè dai. Il progetto mi piace molto e seguirò con piacere il suo avanzare. Lo “schema” della fattoria mi ricorda questo gioco qui: 

  Nascondi contenuto

 

 

Grazie per l'interessamento. Non sapevo di questo gioco di Doraemon e devo dire che lo stile acquerello. In genere questi giochi sono tutti un po' derivativi di Harvest Moon. (Mi scuso della risposta in ritardo ma non avevo attivita le notifiche XD).

[Vale]

Ma che idea carinissima quella di creare un simulatore di fattoria chill sui Pokémon

Mi è piaciuto tantissimo leggere il report di questa settimana, è davvero interessante e comprensibile anche da chi, come me, non ha idea di come si programmi un gioco, sicuramente seguirò anche quelli futuri!

[Riolu007]

12 ore fa, sadriparian ha scritto:

 

Grazie per l'interessamento. Non sapevo di questo gioco di Doraemon e devo dire che lo stile acquerello. In genere questi giochi sono tutti un po' derivativi di Harvest Moon. (Mi scuso della risposta in ritardo ma non avevo attivita le notifiche XD).

Mi pare sia programmato proprio da quelli di Harbest Moon, io lo conosco per averci giocato la demo

[sadriparian]

On 16/7/2021 at 22:43, Vale ha scritto:

Ma che idea carinissima quella di creare un simulatore di fattoria chill sui Pokémon

Mi è piaciuto tantissimo leggere il report di questa settimana, è davvero interessante e comprensibile anche da chi, come me, non ha idea di come si programmi un gioco, sicuramente seguirò anche quelli futuri!

Grazie mille! Come ho scritto nel post è proprio quello l'obiettivo dei report.

 

On 17/7/2021 at 10:30, Riolu007 ha scritto:

Mi pare sia programmato proprio da quelli di Harbest Moon, io lo conosco per averci giocato la demo

Non a caso ha una valutazione veramente alta, se lo becco in sconto lo prendo sicuro.

[sadriparian]

[Report] 02 - Barbeque

Salve a tutti e benvenuti al secondo [report]!

Questa settimana porto decisamente meno sviluppi, ma ci concetreremo un po' di più sul design. Già mi scuso per il mood da "wall of text".

A - Sistemi & Sistemi

É bene iniziare con una riflessione su quale siano le priorità in nello step di prototipazione. Ora, come già ho detto nel report precedente, sto seguendo una metodologia fondamentalmente sbagliata in quanto bisognerebbe sembre costruire una base di pre produzione discreta prima di approcciare del codice o degli asset, ma come ho sempre detto fra quelle righe, questo è un progetto un po' cazzeggiante fatto per sperimentare un po'. Tuttavia è importante capire che almeno fra i primi obbiettivi vi è quello di strutturare i vari sistemi base attraverso i qualsi si possono poi eseguire i primi test e andare a limare il design o la user experience. Fra questi sistemi per ora figurano:

• Personaggio: tutto ciò che concerne il movimento, le risorse e le interazioni del giocatore con il resto del gioco (e dei sistemi).
• Pokemon: risorse, comportamenti dei pokemon come agenti del sistema.
• Orologio e Calendario: sistema che scandisce il gameloop andando a toccare crescita delle piante, comportamento dei pokemon, evneti specifici e quindi ritmo con il quale il giocatore deve interagire con il gioco in una o in un'altra fase.
• Griglia e Coltivazione: come in molti altri giochi del genere, lo spazio viene gestito attraverso una griglia che permette al giocatore di interagire con un determinato spazio unitario (la zolla di terreno da coltivare).

Come forse saprete i primi tre sistemi, per quanto in modo embrionale sono già stati impostati la settimana scorsa ed è per questo che il prossimo obbiettivo è avere una griglia funzionale con la quale il giocatore possa interagire e che faccia da intermediario con le singole celle per tracciare e gestire lo stato e la crescita delle piante.

 

---------------------------

 

B - Bacche alla griglia

Come ho appena spiegato, ragionare e impostare una base di griglia è stato ciò su cui lavorato per questo progetto nelle poche ore disponibili questa settimana. Prima di approfondire alcuni passi in questa direzione parliamo di alcuni concetti utili da tenere a mente.

 

TILESET > Nei giochi 2D il concetto di tileset è un concetto radicatissimo sin dai primi passi del videogioco. Si tratta di realizzare sprite in modo che ogni ambiente possa essere "spezzettato" in unità regolari, nel nostro caso quadrati. Questa tecnica permette di produrre degli sprite modulari con cui si possono "dipingere" gli ambiente invece di realizzarli uno per uno. Permette quindi sia di rispariare su lavoro effettivo, sia di aver maggiore flessbilità nel level design, sia ancora di risparimare di spazio nella memoria (specialmente in passato). Se non avete idea di come possa presentarsi visivamente una cosa simile date per esempio un'occhiata alle tileset di interni di pokemon Smeraldo:  Pokémon Emerald - Interior Tilesets

 

GRIGLIA (GRID) > La griglia è una suddivisione dello spazio in celle di dimensioni uguali. Quando si parla di spazio in questo caso si parla letteralmente di un ambiente basato su coordinate cartesiane, in cui il centro di una cella sarà determinato da un punto (x, y), generalmente definito come Vector2, mentre i quattro punti che definiscono il perimetro della cella saranno ulteriori quattro punti. Un possibile esempio di griglia è proprio quella necessaria per utilizzare un tileset: all'interno della griglia infatti riempiamo ogni cella con uno sprite e grazie alle dimensioni regolari otteniamo un'immagine coesa. Una volta definite le celle è anche possibile semplificare il modo con le quali possono essere richiamate chiamandole sempre con numeri interi a coppie (x, y), ma riferiti all'ordine invece che alla collocazione specifica nello spazio, un po' come battaglia navale. In questo caso per esempio (0, 0) sarebbe la prima cella in orizzontale e in verticale rispetto all'origine e via dicendo. In generale la griglia può essere usata per tantissimi tipi di funzionalità, inclusa per esempio la generazione procedurale.

 

A noi però la grilgia interessa non solo per la possibilità di creare degli ambienti ma come abbiamo detto prima per gestire la crescita delle piante e le relative interazioni con il giocatore. Si pongono problemi di programmazione che richiedono una scelta di design:

• Si tratta di un'unica griglia per scena o di multiple griglie per scena? (ovvero tutto l'ambiente è preso in analisi o solo piccolo pezzi di questo)
• Se è una sola griglia per scena, sarà possibile estendere l'area giocabile attraverso scene separate? (muovendosi fra vari livelli indipendenti l'uno dall'altro)
• Se sono multiple griglie, sono dinamiche o vengono definite di design? (la griglia viene per esempio creata nel momento in cui comincio una coltivazione ed è indivuale per quella coltivazione)

Per trovare una possibile soluzione credo che l'aspetto principale su cui sia necessario riflettere è la progressione del gioco. Prendiamo due casi da analizzare e a cui ispirarci:

• Stardew Valley: in questo titolo l'ambiente coltivabile o in generale manipolabile dal giocatore è limitato a quello della propria fattoria. Il terreno della fattoria ha una dimensione prefissata e viene data al giocatore in uno stato di abbandono. Attraverso i numerosi ostacoli da rimuovere e la limitazione determinata dalla barra della stamina (che costringe il giocatore a scegliere delle specifiche azioni da compiere in una giornata) si determina una progressione ben scandita. Questo sistema funziona bene, ma le dinamiche di gameplay di Stardew Valley non si limitano alla gestione della fattoria ed infatti la mappa si estende molto più largo, offrendo differenti tipi di gameplay come le interazioni sociali, la pesca, il dungeon crawling ecc. Questa varietà arrichisce il gameplay (evitando momenti morti causati dalla crescita delle piante) e spinge in direzioni diverse, come quella della socialità. Questo tipo di gameplay non è per ora nelle nostre intenzioni, che tendono molto di più ad un gameplay che mantenga il proprio flow grazie all'uso delle abilità e all'interazione con i Pokemon.

          

 

• Forager: questo titolo condivide con Stardew Valley il gusto per la varietà offrendo infatti anche uno skill tree che si ramifica in campi opposti. Tuttavia si tratta di un gioco estremamente più frenetico e adatto quindi a un pubblico diverso da quello di Startdew. Entrambi questi giochi però condividono un focus sulla progressione e sull'utilizzo delle risorse ambientali. L'aspetto interessante che ci piacerebbe prendere da Forager è la struttura della sua mappa: si tratta infatti di blocchi unici contenenti uno specifico bioma, degli specifici oggetti, nemici ecc. che vengono sbloccati passo a passo dal giocatore con la valuta di gioco. Ovviamente questa struttura sacrifica molto il realismo dello spazio e il senso di immersione, ma favorisce il senso di crescita e il controllo che il giocatore ha su ognuna della aree sbloccate. 

          

 

Per quanto il nostro gioco Pokémon chill abbia una connotazione diversa, l'idea di poter sbloccare piccoli lotti di terra e quindi, per rispondere alla domanda precedente, avere tante piccole griglie, risulta una soluzione ideale in quanto non solo ci fornisce gli strumenti per limitare e semplificare il level design di ogni area, ma ci da anche l'opprtunità di creare tanti ambienti diversi per potere ottenere una buona varietà di pokemon, coltivazioni e dinamiche. Questo tipo di progressione è caratteristica di quasi tutti i giochi che includano una qualche forma di esplorazione (si considerino i classici deserti, vette innevate, vulcani, colline verdeggianti, spiagge ecc.).

L'obbiettivo in questo caso aggiungere un'ulteriore livello di agency (quantità di interazione/cotrollo del giocatore attraverso le sue azioni). Abbiamo così:

1. Controllo sulla crescita delle piante
2. Controllo sulla crescita e sulle abilità dei Pokemon
3. Controllo sulla macro struttura all'interno della quale sono contestualizzati i due elementi precedenti

Va quindi considerato, per ora, un'ultimo elemento derivato da questa scelta. Si noti infatti che sebbene l'aumento di agency sia un pro nella percezione del giocatore, la quantità di gestione a carico sembrebbe andare contro lo scopo di realizzare un prodotto chill, da gustare senza affaticarsi. Una possibile risposta a ciò, può essere per ora individuata in tutto ciò che scandisce e limita la quantità di azioni possibili al giocatore in un determinato loop di gameplay (come visto sia in Stardew che Forager):

1. Le piante richiedono numerosi loop di gameplay (giorni) per maturare e trasformarsi in nuove risorse.
2. I Pokemon possiedono una quantità di azioni limitata e la loro diponibilità effettiva può cambiare a secconda della loro etologia.
3. Ottenere Pokemon nuovi non è troppo semplice e assomiglierà più una forma di addomesticazione su più loop di gameplay che a una cattura.
4. Gli ambienti richiedono numerose risorse per essere sbloccati, permettendo quindi al giocatore di imparare a sfrutturare il lotto precedente abbastanza bene da diventare un'operazione non complessa o comunque semi automatizzata.

Queste sono alcune speculazioni base che provvederò a elaborare e mettere in pratica nella prossima settimana/e. Come avrete capito in realtà ci sono ancora molte dinamiche fumose specialmente per quanto riguarda l'economia delle risorse e molti tipi di interazione, ma le elaboreremo un passo alla volta.

Con questo vi ringrazio per l'attenzione e rimando nuovi aggiornamenti alla prossima settimana.

Se avete suggerimenti, domande o altro lasciateli pure qua sotto.