Ben QUATTRO anni fa avevo proposto a Gianluca Gemelli (scrittore e cultore de I Tre Investigatori) di realizzare un gioco basato sui libri di Leo Edwards che stava traducendo in italiano – libri per ragazzi del anni ’20 del secolo scorso da cui anche Robert Arthur aveva dedicato omaggio nella sua produzione. Gianluca (aka Prof Gemelli) mi aveva proposto un canovaccio con i quattro protagonisti del filone Jerry Tood da adattare. A suo tempo avevo fatto qualche esperimento sia come text-adventure, sia come punta-e-clicca, ma poi, beh, le solite cose e il progetto (per mia sola colpa) si era arenato, dopo che in realtà storia e ambientazione erano stati definiti.
In questo periodo, dopo avere lavorato su The Mystery of Silver Mountain, ho deciso di rispulciare quel materiale e ho provato ad arrivarci in fondo. Il gioco è relativamente corto ma la storia secondo me, è abbastanza fedele alle tematiche dell’autore originale (questo, ovvio, per merito di Gianluca) e credo possa essere divertente da affrontare.

Se siete curiosi, potete provarlo qui o qui (a seconda che preferiate la versione in italiano o quella in inglese). Se poi siete ANCORA più curiosi, qui c’è la pagina GitHub con i “sorgenti” – in formato StoryTllr – delle due versioni.

Ok, è stata lunga (anche se con un “buco” in mezzo), perché il gioco è davvero grande (e i riferimenti da controllare uno a uno). E, sì, va pure aggiunto che StoryTllr è, come engine per avventure testuali, “primitivo” – tenendo conto che il suo punto principale è l’essere minimale per poter girare in poco spazio su un Commodore 64. Comunque sia, il gioco alla fine c’è e pure completo e con un alto numero di zone con grafica originale (61 immagini per 81 location). Questo numero mi ha costretto a realizzare un gioco su due dischi (cosa non già prevista inizialmente, quindi anche in questo caso, cambi al compilatore E al motore) – ma così questa possibilità c’è già eventualmente per il futuro.
Se siete curiosi di giocarci, lo trovate qui su itch.io, ma se siete invece più curiosi di dare un’occhiata ai sorgenti, questi li trovate su github.

(pagina Steam)

Relativamente breve (ma NON breve), poco costoso (in sconto ora è sotto i due euro), divertente, ben fatto e con una grafica e delle animazioni spettacolari – SE chiaramente siete amanti della pixel art – Feria d’Arles è una chicca che ci vede nei panni di Molly, una giovane decisamente intraprendente e impavida, decisa a diventare un grande toreador, partecipando a un importante torneo nella bella città di Arles, nel sud delle Francia.

Tutto è chiaramente MOLTO più complicato di come si aspetta la nostra protagonista, che dovrà girare per le strade di questa cittadina, cercando un modo di superare almeno tre ostacoli: è troppo bassa per fare il torero, non ha l’attrezzatura da torero, e, beh, è una donna – e le donne NON sono ammesse a questa competizione.

Nessuna di queste cose preoccupa troppo Molly, che determinata a perseguire il suo sogno, non avrà problemi a cercare tutte le scappatoie possibili per ottenere quello che desidera.

Il gioco, realizzato con AGS, ha una interfaccia minimale ma abbastanza classica, che renderà immediata l’interazione tra oggetti e elementi nelle scene. L’area di gioco non è enorme, ma anche qui sappiate che le cose con cui è possibile interagire, o le persone con cui è possibile dialogare, sono un buon numero – garantendo così molto di più di un’ora di gioco (io ne ho impiegate un paio per finirlo – e senza sbloccare tutti gli achievements proposti) – durante il quale vi sarà impossibile non ridere (o almeno sorridere) in vari punti, rimanendo anche a bocca aperta per lo stile e i dettagli.

(pagina Steam)

E’ praticamente impossibile, se siete appassionati di pixel-art, che non conosciate Octavi Navarro. Quindi è improbabile che non abbiate mai sentito parlare di Midnight Scenes – una serie di “episodi” di una Twilight Zone trasposta in brevi giochi punta-e-clicca – di cui lui è artefice insieme a Susanna Granell. L’idea dietro a questa iniziativa è davvero bella (e il piano di realizzare qualcosa di simile c’è – sì, intendo proprio, Birds are not Real, a cui purtroppo in quest’anno non sono riuscito a contribuire) e quasi tutti i giochi proposti sono di ottimo livello. E quel “quasi” non vuole dire che ce ne sono alcuni che sono brutti, ma solo che non tutti sono davvero dei giochi giochi. Il titolo di cui vi voglio parlare – A Safe Place – è uno di questi. La storia è molto bella, i dialoghi, i disegni e le animazioni lo sono altrettanto. Solo, la parte di interazione è davvero ridotta all’osso. Siamo ai livelli di una Visual Novel – genere che stimo meno ma verso il quale non ho problemi – più che di una avventura, pur semplice e limitata.

Di cosa si parla? Beh, il giovane protagonista, in un freddo inverno, non riesce più ad uscire dalla sua stanza. Vive con i genitori e la sorella, ha una amica speciale che abita vicino e con cui riesce a rimanere in contatto grazie al computer, ma la sua mente gli fa pensare che appena oltre la sua porta ci siano in agguato mostri pronti a ghermirlo. E questo è abbastanza per lui per vivere in una sola stanza, senza bagno, mangiando scatolame e quelle poche cose che la sua amica gli porta quando lui la ordina online, facendo in modo che lui possa recuperarla dalla finestra del primo piano.

La claustrofobia della situazione – e il vedere il mondo che va avanti intorno a lui – è resa davvero nel migliore dei modi, e la narrazione, fino al bel finale, tiene incollati allo schermo.

Se il fatto che le scelte di gioco siano minime non vi dispiace troppo, fateci tranquillamente un pensiero.

(pagina su Steam)

Avevo giocato alla demo di questa nuova avventura del gruppo dietro a Dexter Stardust : Adventures in Outer Space appena era stato rilasciato – e mi era piaciuto parecchio. Anche in questo caso l’ambientazione era sci-fi, ma la grafica, invece che a cartone animato, era low-res in pixel-art (cosa che apprezzo). Le meccaniche di gioco scelte era differenti dal primo gioco (non classico punta-e-clicca con personaggio che muovi nelle scene) ma un sistema a scene più o meno statiche, con movimenti direzioni on-screen. Qualcosa di più “vecchio” ancora come stile, ma funzionale, e perfetto per il gioco proposto (nonché davvero bello come colori e scene).

La demo non era cortissima, e dava già modo di scoprire che tipo di avventura avresti affrontato nel gioco completo: a causa di un problema, la tua micro astronave ti catapulta su un pianeta sconosciuto, e nell’atterraggio di fortuna si rompe rendendola inservibile. Il pianeta su cui arrivi ha una atmosfera respirabile e scopri, dopo pochissimo, che ha segni di civilizzazione: ci sono infatti statue e dispositivi, e trovi anche qualche resto umanoide. Fino ad arrivare a una vera e propria città.

Se non fosse per il fatto che la protagonista è da sola (o almeno, circa da sola), il paragone (almeno in certi momenti) con The Dig sarebbe ancora più netto, ma il punto è che la storia prende da una fantascienza classica, e le tante ambientazioni non possono che ricordare questo libro o quel film, in modo assolutamente gradevole. Il gioco, che, lo ammetto, con un po’ di aiutini ho terminato in poco più di cinque ore, merita davvero e sa lasciare a bocca aperta in più di un punto, anche per le tante scene in movimento, molte delle quali direi in rotoscope, e quindi molto cinematografiche.

Cosa non mi è piaciuto? Giusto il fatto che la narrazione è rallentata da tantissimi puzzle, che, anche se perfettamente in gioco, richiedono di segnarsi codici e sequenze, e di provare più volte alcune operazioni parecchio complicate. Tutto questo, che è ulteriormente reso difficile dal fatto che tutto è scritto in lingua aliena (numeri compresi), aiuta a calarsi in questo mondo abbandonato, ma non è troppo nelle mie corde.

Ho invece apprezzato davvero molto gli effetti sonori, la voce principale, e il finale, davvero molto da (buon) romanzo di fantascienza dell’epoca d’oro.

Se usare carta e penna (o il cellulare per scattare foto) mentre giocate non vi disturba troppo, e apprezzate le cose in pixel art, ve lo consiglio senza ulteriori riserve.

demo su Steam

Dopo otto anni dall’uscita di Kathy Rain, a mio parere uno dei migliori giochi punta-e-clicca mai realizzati (almeno nella “nuova era”), ho avuto l’enorme piacere di scoprire che sta per arrivare un seguito, e ne ho potuto apprezzare un pezzetto, grazie a una breve demo pubblicata su Steam.

Kathy Rain, la protagonista, è passata da essere una ribelle studente di giornalismo (che nel primo gioco si trova ad affrontare un mistero nella sua nativa Conwell Springs, dove ritorna per la morte del nonno) a una ribelle investigatrice privata – a pochi giorni da uno sfratto se non riuscirà a raccimolare i soldi che le servono per non dormire per strada. E i soldi in questione potrebbero arrivare dalla taglia che il sindaco di Kassidy ha promesso a chi catturerà un fantomatico serial killer che, giorni prima, ha ucciso una notissima scrittrice locale.

La risoluzione è passata da 320×240 ad almeno il doppio. Ma già – tra il gioco originale

e il director’s cut forse c’era stato qualche ritocco.

La grafica aggiornata – con più animazioni e più effetti anche nelle scene di passaggio (con lei in moto, quando ci si sposta tra una location e l’altra) – è godibile, ma lo è molto di più il fatto che abbiano mantenuto la stessa voice actress e lo stesso tono del gioco precedente. Kathy Rain, per dare una idea a chi non ho giocato al primo gioco, qui è una sorta di Veronica Mars – lei contro il mondo, con un mistero da risolvere e relazioni da costruire. Tantissime descrizioni da leggere e, già in questa breve parte, tante interazioni tra inventario e scene E tra inventario, diario, scene e personaggi, con dialoghi da costuire usando diario e telefono.

Molto promettente e, per chi come me ha adorato il primo, un acquisto sicuro appena uscirà.

https://marcogiorgini.itch.io/nesterin-trail
(full game will be available in February)

After almost six months after the demo’s release, I’ve finally finished the full game, of course using the StoryTll64 engine.

Or better, I should say that I’ve finished the full game AND I’ve changed the engine enough so to be able to have a game like that based on that engine.

Most of the engine changes are technical (I’ve switched from cc65 to oscar64 as compiler – and that required me some time but helped me to reduce player code footprint, I’ve improved several time the text compression algorithm, I’ve improved a bit also the image compression one, but mostly I’ve changed the way it works so to have a minimal decompression temp area) but some are related to the script too – for things I simply missed during the first implementation (and there still are others I should add) or for things I didn’t implement in the “best” way – even for such a simple tool.

I hope to find time to update the git release (even if in that case I must also update the demo games), but I also hope to find time to write more about it, in the unlikely case someone else wants to try to use it for his/her own game.

But for today, I simply want to say that it’s been a really long and hard journey, to go from Nesterin Trail initial idea to this full game, but the challenge has also been really rewarding. Yes, the first thing I should have learned (and I’ve not) is that trying to create a long game, with strict limits (I’ve also had problems with DISK space!) with a young engine, used just for minimal projects, is really a bad idea.

I’ve fought more against the code than against the story development and at the end I’ve cut a lot of things because I could not bypass (my) C64 memory issues (surely not without slowing down MORE the development time). I’ve spent nights debugging asm code with VICE because something didn’t work – and it was a problem related to memory overrun that happened because things were getting huge and I wasn’t exactly aware of where certain data overlapped others.

It was hard – to reach almost a crying point while trying to keep eyes opened.

But – uh – it was also FUN. I wasn’t ready or good enough for this kind of work when in the 80s I was a kid with a real C64 at home trying to create games to store on an unreliable tape. But maybe I’m now, ready to fight, even if probably still not good enough.

Anyway – I really lived in Nesterin this month – even if a Nesterin that was a fantasy setting, with a nerd technical feeling – and I really hope someone else could live there too and share this world with me, for the few hours of gameplay.

I’ll discover that soon – game’s ready but I’ve still a week to way before its release – and for a nice reason.

Ok, time to finish this small sample project. We won’t do anything too complex, but we’ll add something that the player would need to understand to solve at least one puzzle.

Let’s start adding a new room – the outside.

and then let’s add a south direction to go there from the living room – but with a difference, compared to the other movements.

Something that will show this thing:

Yes, we’re “trapped” in our own apartment!

To handle that we just need to use a variable, that needs to be set to a certain value to let us out.

A locked door means we need to find a key – that will add to normalobj – but stating that’s not “normal” – because it starts without attributes – and that means we won’t be able to see, or take it, even if we put it in the bedroom. It’s more or less a hidden object.

How should the player take it, if it’s not visible? Well, we’ll add a description for the bedside table, telling that it’s got a drawer. And then, if we check the drawer, we’ll let the player find the key – changing the object attributes.

That way, after examining the drawer, the key would be handled by our default take verb.

With that in our inventory, we just need to add handling for unlock

And here we go.

Then we can leave our home, and finish the game (actually, the game won’t stop – but there’s nothing more to do, if not moving back and read some other descriptions)

What do you think about that? Things are quite straightforward – even if of course that doesn’t mean you won’t find some difficulty, at least at the start, because of the syntax and/or because this starts to be “linear” only after some tests.

But the point is – yes – with this tool, it all but impossible to build a graphic text adventure for C64.

I’ll add (and possibly change) something here and there, trying to simplify things and improve the whole system, but if you’re curious / interested, consider saving a bookmark for this blog, for my github page, or for my itch.io page.

(the whole project is available here)

Before finishing this small sample adventure there’s a thing that may not be clear, and that I’ve decided to explain and handle better (I mean, changing the script compiler).

The point is: we defined an object (i.e. our bike), then we added a name property (“your bike“).

Doing that, we’ve told our engine not only to be aware of the existence of an object in our game but also how this object must be called when asked. Is that all? Nope. We’ve also implicitly told our engine how that object can be referenced by the user in the game. “take bike” can be handled, because bike is both the object name for the game engine AND the object name for the player.

I guess this can’t be immediately clear – so, to explain what I’m saying, let’s say we want to localize our little game, adding an Italian version. Of course, I could clone the whole script file, and localize everything in Italian (changing bike to bici, for instance). BUT I may want to have the same script, able to handle BOTH languages at the same time, just because I could want to improve/bugfix it in the future, without having to worry about syncing the two scripts.

To do so, I can split the object name, used by the engine, from the object name used by the player, adding a way to express a synonym property.

Doing so I can have ONE object name for the script part (bike – but I could have called it obj01 for what is worth) and a set of name, description AND synonyms for each language I want to handle.

bike will be used in the script to reference the object INSIDE the game script, while localized synonyms will handle user input.

Then, I just need to add a configuration property to state WHICH one I currently want to compile into our C64 program to have the resulting game. (No, I don’t want to have multilanguage selectable runtime – we’ve got really few kb of memory and I prefer using them for the game. I mean, we can distribute TWO different versions, simply doing two builds)

The last thing I still needed to do was to add also the ability to localize even the msg command. After that, we’re ready to go.

And now we can have this

or this

Simply changing the config parameter

A note: this new feature is NOT mandatory. If we DON’T specify a two-letter language before name, desc, msg or synonym we’ll simply got them used like before

Even in this now-bilingual sample I still have a not localized msg that’ll work in the same way as compiling the Italian or the English version of the game.

Before going on, as already anticipated, we’re going to remove the specific global verb handling and simply include the standard library.

That way we’re getting all the default behaviors – including the messages for unknown verbs.

Then let’s add an image for each room, just so that they look cooler.

But even if now these two locations look cooler, they’re still not good enough. Why so? Because, being this a graphical-text-adventure, we don’t want only (or mainly) graphics, but also text. We want to be able to interact, to explore the game locations, using verbs. So we need descriptions at least for some of the objects we mention (or that they’re supposed to be there).

To do that we need to add objects in the game script. But what kind of objects do we really need?

If you don’t even get the question, it’s fine. In the real world, objects are simply straight objects.

But in a game, some objects are more real than others.

The ones that are important for the game can probably be taken and moved around, while the ones that are just there to enrich a room perception, well, they are scenery. They just need a description. Or a few specific verb handling.

In the stdlib.hjt you’ll find some object classes. They can be changed or added, but they are just different for the attributes they’re assigning to their objects.

In our library scenery are the objects that are there, that you can check or interact with, but that you won’t see in the room objects list. sceneryobj are instead automatically “visible” in the room description in a special way. The normalobj have also a takeable flag that’s used by the get/take verb to know if it’s possible to put them inside your inventory.

Let’s add something to our rooms, so that’s easier to understand the differences between these three kinds of elements.

And let’s also add a “real” object – your cellphone – not tied to a specific room, even if starting in one specifically.

If we’ve something like that in the stdlib…

…entering in the living room we’ll get 1) the room description and 2) a list of listable objects – in this case our bike.

We can’t get it (so we’ll get the default message for this verb) but we can examine it. And we can of course examine also all the other local objects, even if they’re not so important for the game that we want them listed when you check the room.

The last thing I want to underline is the normal object – that’s to say our cellphone. A visible, listable, and takeable “global” object that we decide to put in the bedroom from the start.

So entering the bedroom we can see it, but we can also take it, and have it in our inventory.

And, well, if we want to do so, we can also drop it in the living room, adding this object to the listable ones there.

The game so far is minimal – but it starts to feel like a game, doesn’t it?

The only missing thing is at least a puzzle to solve. Something we need to figure out, to reach a goal.