Ring around the World, nuovo gioco per Amiga Opzioni

[saimo]

Dopo mesi di intenso lavoro, un gioco che praticamente nessuno aspettava è finalmente uscito!
Qui mi limito a dire che si tratta di un'avventura punta-e-clicca - per il resto, sentitevi liberi di darci un'occhiata ;)



https://www.retream.com/Ring_around_the_World
https://retream.itch.io/ring-around-the-world

Come tutti i giochi RETREAM, anche questo è 100% gratuito, ma, se vi piace, vi chiedo di offrire un qualunque aiuto a chiunque sia vittima di un qualunque tipo di violenza.

Messaggio modificato da saimo il 6 Mar 2023, 18:09

[saimo]

Ho appena rilasciato una versione corretta (v1.1).

Non c'è opzione di aggiornamento - aggiornare una copia installata precedentemente consiste semplicemente nel cancellarla e installare la nuova versione.
A causa dei bug e dei cambiamenti, le snapshots della v1.0 non sono più supportate - usarle causerà risultati imprevedibili, per cui non usatele.

Nonostante la v1.0 sia stata rilasciata dopo averla giocata dall'inizio alla fine molte volte su macchine diverse, alcuni bug sono riusciti a infilarcisi
Il primo è stato trovato senza nemmeno guardare il gioco o il codice: si è presentato da sé all'improvviso nella notte insonne seguita al rilascio del gioco. Il secondo è stato notato guardando qualcun altro giocare e il terzo è stato riferito proprio da costui dopo che gli ho rivelato l'altro bug. Poi, svariati altri bug sono stati trovati e sistemati dopo aver cominciato la revisione del codice.
Ho colto l'occasione anche per apportare alcuni miglioramenti.

Ecco la lista dettagliata dei cambiamenti...

v1.1 (17/03/2023)
* Fixed the cave entrances (they could be entered from above; also, they brought the protagonist to the place from where he last exited the cave, which might be different).
* Fixed the protagonist escape from the cave when he needs to sleep and the closest exit is the north one, but the access to it is blocked by the chasm (he would virtually take that exit anyway).
* Fixed the handling of the protagonist's sleep when requested by the player (multiple tiles replacements where generated whereas none were needed; when sleeping just because of the physical need, the protagonist would sleep while standing on his feet).
* Fixed the drinking balance handling (a check was done too late, which could cause the thirst to seem quenced when, instead, it was quite strong).
* Fixed the palette of the game over screen (was slightly off).
* Fixed the initialization (did not handle errors relatively to a certain group of operations).
* Fixed the triggering of the earthquake (it could happen because of the loading of a snapshot if saving had been done in the upper part of the cave).
* Fixed the protagonist bob image upon loading of a snapshot (its index was calculated, but that did not work when he was standing on the raft).
* Fixed a boundary check in a tile replacement procedure (was using a wrong upper boundary).
* Fixed the replacements of several tiles (multiple instances of the internal data were used for each tile; in most cases it was actually just an ill-advised choice).
* Added a workaround to OS memory fragmentation, which could cause out-of-memory errors when switching location on 1 MB RAM machines.
* Refined the location loading so that, upon failure, a second attempt is made after freeing the memory occupied by cached chat data.
* Removed the current snapshot preservation upon snapshot loading (obsolete since quite a while).
* Saved some memory by reducing the variables buffer and tweaking the AMOS Professional Interpreter configuration.
* Modified the double buffering system to allow limiting the graphics refresh rate arbitrarily.
* Limited the graphics refresh rate to 25 fps when the protagonist moves or animates (expanded machines executed at 50 fps, which looked worse).
* Replaced AMCAF's Raster Wait and Y Raster() with more reliable assembly routines (which include also the loops that made use of them).
* Changed the effect the non-player characters phrases are printed with (this one looks better and avoids that partially updated graphics show on underpowered machines).
* Improved the synchronization of some graphics/palette updates.
* Made palette changes faster.
* Made the movement of the pointer smoother when exploring the world area (it was assigned the image on every graphical refresh with Change Mouse and that caused it to stutter).
* Made the protagonist turn towards the destination tile also when his movement is initiated by the program control (i.e. not by the player).
* Made the protagonist turn towards the right direction in a situation where he did not.
* Simplified the time-based events code.
* Added a time-based event that removes the imprints/pits from the sand after some in-game hours.
* Touched up the metal plate graphics.
* Fixed 'I' and ']' of the non-player character texts font.
* Added a sound effect.
* Made other minor changes/optimizations.
* Reprocessed the executable with an improved optimizer tool which optimizes also Colour, Colour(), Exit If ... and While ... Wend.
* Made a few minor changes/additions to the manual.

https://www.retream.com/Ring_around_the_World
https://retream.itch.io/ring-around-the-world

[Diduz]

Bello! Mi sono accorto solo adesso del gioco!
Cercherò di provarlo. :-)
PAL perché ci tieni a usare il 320x256 su Amiga, vero? È stata la prima cosa che mi sono imposto quando ho fatto il mio gioco: quanto mi davano fastidio i giochi 320x200 schiacciati sul PAL, widescreen involontari! Però poi mi sono preoccupato che chi avesse una configurazione NTSC non vedesse tutto lo schermo, così nella versione inglese ho messo un'opzione 200/256. Ma nel mio caso, parlando di un'avventura testuale, adattare il gioco era automatico, con la grafica in-game non sarebbe una passeggiata (e lo so perché ho messo su giusto un paio di cartelli grafici per il mio lavoro e ho dovuto crearli in doppia versione).
Questo è il tuo primo adventure o sbaglio?
Il primo piano della Monocola verde è intrigante.

[saimo]

Bello! Mi sono accorto solo adesso del gioco!
Cercherò di provarlo. :-)

Ti auguro che, se troverai il tempo, non dovrai pentirtene di averlo dedicato a RatW

PAL perché ci tieni a usare il 320x256 su Amiga, vero?

A dire il vero no, non è una questione di "tenerci".
Il motivo principale è che 200 pixel verticali sono troppo pochi, sia in generale, sia per questo gioco specifico (come puoi leggere nella storia inclusa nel manuale, originariamente l'inventario era orizzontale e nella parta bassa dello schermo, per cui l'area di gioco era sacrificata verticalmente: era alquanto irritante muoversi in quella direzione, sia perché la visuale era ristretta, sia perché i movimenti erano troppo spezzettati in piccoli passettini).
Poi ci sono altri motivi generali:
* 60 Hz possono essere troppi, perché, quando i giochi riescono a tenere il passo, la velocità risultante è troppo elevata;
* non ho mai avuto una macchina NTSC, quindi nemmeno mai sviluppato un'abitudine a tale standard;
* la scena demo/videogiochi è principalmente europea, quindi orientata a PAL.

È stata la prima cosa che mi sono imposto quando ho fatto il mio gioco: quanto mi davano fastidio i giochi 320x200 schiacciati sul PAL, widescreen involontari! Però poi mi sono preoccupato che chi avesse una configurazione NTSC non vedesse tutto lo schermo, così nella versione inglese ho messo un'opzione 200/256. Ma nel mio caso, parlando di un'avventura testuale, adattare il gioco era automatico, con la grafica in-game non sarebbe una passeggiata (e lo so perché ho messo su giusto un paio di cartelli grafici per il mio lavoro e ho dovuto crearli in doppia versione).

Esatto: supportare entrambi gli standard è un lavoraccio enorme. E non solo per la grafica, ma, volendo fare bene il lavoro, anche di temporizzazione.

Questo è il tuo primo adventure o sbaglio?

Non sbagli.

Il primo piano della Monocola verde è intrigante.

[saimo]

Tre giorni fa, un amico che stava giocando a Ring around the World (senza che nemmeno lo sapessi), mi ha detto: "Vedo cambiare la palette dei colori e sono quasi sicuro che sia il giorno che passa!" - aveva ragione - il gioco simula il trascorrere del tempo e gestisce diversi eventi collegati ad esso.

Un effetto costante e molto importante è che il protagonista diventa (sempre più) assetato, affamato e assonnato. Un altro effetto constante ed evidente è che l'illuminazione ambientale cambia a seconda dell'ora del giorno. Altri eventi accadono a determinat orari.
1 ora nel gioco corrisponde a 10 minuti di vita reale, ma alcune azioni possono far scorrere il tempo più velocemente.
La durata di 1 giorno è di 24 ore.
Il gioco comincia alle 12:00.

Prima di rilasciare il gioco, avevo fatto un video che mostra, a passo accelerato, alcuni effetti del tempo, ma l'avevo tenuto privato. Per rispondere al mio amico, gli ho mostrato il video, e ora ho pensato di condividerlo con tutti.



Messaggio modificato da saimo il 23 Mar 2023, 11:58

[Diduz]

Strano, il video non si apre.

[saimo]

Avevo sbagliato :p Link corretto.
Grazie della segnalazione.

[Diduz]

Avevo sbagliato :p Link corretto.
Grazie della segnalazione.

Stavo pensando... il cursore è uno sprite hardware proprio per evitare facilmente che risenta di questi cambi di palette?
Cioè, immagino che si potrebbe evitare comunque assegnandogli dei colori non coinvolti in quelle transizioni, però siccome il gioco va a 4 bitplane non avevi molti slot liberi e - immagino - così la cosa è più rapida.
P.S.: Ho solo analizzato tecnicamente quello che ho potuto finora, e sono rimasto affascinato dall'immagine HAM nell'intro. Spesso l'HAM mi dà la sensazione di "spappolare" un po' l'immagine, proprio a causa del suo funzionamento, però in questo caso il soggetto è scelto bene e ha retto benissimo il "trattamento". Pulita poi l'idea di usare gli sprite per i titoli da sovraimporre (mi sa che con l'HAM è proprio la maniera migliore di far comparire qualcosa sulla schermata). Elegante.
Se non vado errato poi le schermate dei dialoghi hanno due palette diverse per primo piano dell'interlocutore e interfaccia in basso, vero?
E per oggi "le avventure di Diduz nel debug di WinUae seguendo intuizioni e curiosità" terminano qui.

Messaggio modificato da Diduz il 23 Mar 2023, 15:12

[saimo]

Stavo pensando... il cursore è uno sprite hardware proprio per evitare facilmente che risenta di questi cambi di palette?

No: il vantaggio principale dello sprite è che non richiede disegno e ripristino nei bitplane, per cui 'impatto in termini di carico di lavoro per la macchina è minimo e il codice richiesto è molto semplice; inoltre, in questo caso specifico, ho sfruttato le routine di movimento del puntatore dell'AMOS (delle routine custom scritte in AMOS stesso sarebbero state più inefficienti). Poi c'è anche il vantaggio che hai notato tu, ma è un effetto secondario che peraltro, nella versione originale del gioco, nemmeno c'era perché la grafica usava tutti e 32 i colori (vedi backstory nel manuale; tra qualche tempo pubblicherò un video che fa vedere le varie versioni).

P.S.: Ho solo analizzato tecnicamente quello che ho potuto finora, e sono rimasto affascinato dall'immagine HAM nell'intro. Spesso l'HAM mi dà la sensazione di "spappolare" un po' l'immagine, proprio a causa del suo funzionamento, però in questo caso il soggetto è scelto bene e ha retto benissimo il "trattamento".

Il risultato è stato ottenuto anche grazie al fatto che il "trattamento" ha incluso ore di ripixellamento manuale

Pulita poi l'idea di usare gli sprite per i titoli da sovraimporre (mi sa che con l'HAM è proprio la maniera migliore di far comparire qualcosa sulla schermata). Elegante.

Non è la maniera migliore è: l'unica. Per avere elementi in movimento e/o con cambio di colori (cose che avvengono nella schermata iniziale) senza causare le tipiche sbavature HAM, è necessario che gli elementi grafici dinamici e quelli che seguono sulla destra utilizzino solo ed esclusivamente i 16 colori di base, ma la scelta di questi va fatta in base alle esigenze dell'intera immagine (in altre parole, non potevo usare come colori di base solo il nero più le varie sfumature di giallo del logo).

Se non vado errato poi le schermate dei dialoghi hanno due palette diverse per primo piano dell'interlocutore e interfaccia in basso, vero?

Sì, ma non è solo una questione di palette: la fascia degli NPC utilizza l'EHB con palette specifica per NPC, la fascia dell'interfaccia usa la palette del gioco (e gli stessi bitplane) delle ore 12:00.

[saimo]

Per chi troverebbe interessante sapere come è nato Ring around the World e come è evoluto, ecco un video che ne mostra alcune fasi dello sviluppo:



La storia completa è nella descrizione del video stesso.