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.

Ok, let’s see how to go from one starting location with no interaction possible to something, still minimal, but playable.

Let’s start adding two rooms, a bedroom (with the game starts) and a living room.

For those two locations, we need to have at least a description, so let’s add it, this way:

• Please note that we can put the part after the : or inline or as text under the same node. In this case, we prefer to have a description, that’s longer, as text on the right, while we keep the name directly visible on the tree structure.
• And please note also that we don’t have msg: command in the description because that’s an attribute, and not “code”.

Let’s go on. Now we change the $start onfirst code so that after a simple initial message we’ll set the game starting point to the bedroom.

• as you can see there are two new commands: waitkey and goto:
• here we’ve used references to the config part (we already had name, now we’re going to add the other two elements)

With these changes we’ll get that:

And, after pressing a key, we’ll go there

That’s not what you expected, is it? why don’t we see any description – and we still have the previous text?

Because my engine doesn’t assume you want something in a specific way. It’s built to be as extendible as I thought it was wise (for a very small one, being designed to run on a 8bit computer)

So, we need to tell it what we want.

And that means that we need (and want) libraries of standard behaviors.

Instead of adding each behavior inside the game script, we can create a stdlibj.hjt (read that as “standard library.hjt”) and “include” it, of course knowing that we can change everything we want if we need it.

Ah, of course a standard “standard library” is provided on GitHub, so you don’t need to understand everything and build your own (for now).

But, let’s fix this thing in our sample game, before including that, so that you can understand better what’s under the hood.

To do so we need to add a verb section and define what we want to achieve for onfirst and onenter events.

We want to have the screen cleared (clear) we want to read the room description and if there are visible, listable objects in the room, we want to read their list.

Added that, we’ll see this:

That’s surely better, isn’t it?

But 1) we still can’t do anything and 2) you may ask: hey, but now we have TWO onfirst, why’s that?

About the 2) – yes, we got two of them. BUT, and this is quite important, we have TWO main level for everything. One is the global level (something that must exist or happen everywhere, with specific limits) and one is the local level (the room we’re in). So we can have a generic, global, verb handling, and an override, in a specific room.

And so, to move from one room to the other, we can choose the second level, and add a specific verb handling in each room, like that:

This way we can move from one room to the other.

BUT if I ask to move east from the living room, nothing happens, not even a message. And that’s why we need to add a global handling for movements – that simply say that we CANNOT move that way.

To do so we can add each verb where we put onfirst with a message, but my engine can do a bit better than that.

We can define classes – we can add a behavior – we can associate verbs to that class.

Like that:

And added that we’ll get this:

(Actually we get this after a small change – if we call a synonym set e|east we must refer everywhere else to that set using (only) the FIRST element. So we need to change the reference in bedroom and living room accordingly)

But, after that, we can move to and from the two rooms without problems. Still not a great game, but now we can interact.

As you probably DON’T know, I’m currently building a graphic-text-adventure engine for C64 – that’s called StoryTllrC64. The project (I mean, source code and staff) is under MIT license, and is currently on GitHub. I’ve already built and distributed two little games using it (Cloak of Darkness and Accuse) based on known, open-license games.

So, even if it’s still under development, it’s time to share some basic info about how to use it, in case someone may be interested in using it, once it’s completed (enough) to be used for a real game.

We are starting from a really minimal sample project.

Let’s start creating a folder for this sample.

We need to add some subfolders:

• bin, where the C64 game will be found after compiling
• png / img folders (for images, png and native)
• tmp, needed for temporary files during builds

And a couple of files:

• our main script file (let’s call it sample)
• a batch file, to speed up buildings

As you can see, the main script file has an odd extension (hjt) – that’s a TreepadLite file (and TreepadLite is a not-currently-supported-anymore program to create tree-like files). I’ll show you things using THIS program – but everything will be supported also using yaml files (text files with a specific indentation, to give you more or less the same tree-like features you can get with TreepadLite (anyway, this program, that was the free version of a commercial one, is still available around, so if you want you can still give it a try)

Anyway, what do we need a script file for? Well, to define the elements of our game and their interaction.

StoryTllrC64 uses at the moment only FOUR kinds of elements:

• verbs (they handle the game logic – you need verbs to make actions in your game)
• objects (based on characteristics they can be quite different, even actors are considered objects)
• rooms (places). A room is also the $inventory but also $nowhere or $everywhere
• variables (something that can be used to keep status, if it’s not related to objects)

To create a minimal game you must create at least ONE room – the one called $start – that usually is the “home page” of your game. The point from which you make the player go to your first real location, to enter the action.

But let’s start. After creating an empty sample.hjt if you double-click it you’ll see something like that.

Write “main” and add two sections – config (where your game info must be put) and room (the folder for your locations).

You don’t really have to create a configuration too – because defaults will be used otherwise – but it’s the place where you can define your adventure name, put your author name and specify other things (some important, some not). We won’t talk about that now.

We’ll simply add a name, and the $start place

Then we’ll add three other things:

• image, a reference to a 320×96 png that will be added to the game and shown in that location. We’ll used a shared one for this sample, but you can try with your own.
• onfirst, an event handler that will be called the FIRST time you enter that place during the game (there’s also an onenter handler, that’s called every time, but the first if you added also the onfirst)
• the FIRST “code” of your game – a sequence of messages that will be shown in the game

Once you’ve saved, you can run it and show the game inside your favorite emulator.

How can you run it? Using the batch file that will do a sequence of operations:

del *.h
del advcartridge
del make.bat
....\script_compiler\bin\script_compiler.exe sample.hjt
call make
bin\sampleadventure.d64

That’s to say:

• cleaning any previous generated file (*.h or advcartridge depending on the kind of build) including the batch file with the C64 disk creation using c1541 program, which will be created by the script_compiler, after it finished to compile your script, generating a binary file (or .h headers)
• running the script_compiler
• running the new generated make file to create the C64 disk
• running the C64 disk with your game

That’s what you will get:

In case you’re curious, in your folder now you’ll see some generated files:

You’ll see more in tmp and img folders (but you don’t need to care for them). In your bin folder there’s the only file relevant for you, that’s the one with your C64 game (the one launched by the batch file)

A note: the direct creation of a d64 file (based on the already-built engine provided on GitHub with also the script_compiler) is ONE of the choices you have – because (if your game has not too many images) you can also create a version of your game able to run on a tape (single file). But to do that you’ll need to rebuild the engine with CC65 (a C compiler for 8bit) including new header files generated by the compiler. This is surely more tricky – even if it’s the best way to redist your game (if it’s small enough).

a point’n’click adventure game developed for AdvJam2022

by Marco Giorgini (@marcogiorgini)
with Paco Diago’s music (@pacodiago)

https://marcogiorgini.itch.io/the-mysterious-gear-chest

Even if solving puzzles is of course the biggest part of the fun while playing adventure games, sometimes a little help is useful. If you think that too, this post may be for you. I’ve written down some basic information and then a list of question/answer covering all the topics you’ll find in the game (the main one at least).  If it’s not clear – yes – this post is FULL of spoilers. So read it only if you’re ok with that.

In this game you’ll be able to play as three different characters – Marco, Sara, and Andrea  (FYI: Andrea is a male character)- switching from one to the other when you want.

Even if there are three characters the main one is Marco, and so he’s the one you’ll be playing most of the time.

Considering that he’s the one who’ll do most of the legwork first advice – an important one – is to let him take a city center map (he’s in the used books library, and it’s free) because using it you can move jumping from a place to another without “walking” – and that saves a lot of time.

But where do we start?

Well, Marco is waiting for a photographer to attend (as a journalist) the Gear Chest event at Museums Palace.

Sara is at home, showing her house to a new guest – her distant cousin Enrica.

Andrea is in the Conference Room (at the Public Library) finishing a writing course lesson, and ready to enjoy a book presentation by one of his favorite authors.

What can go wrong?

First – Marco can’t enter the Gear Chest event because he has not the required Press Pass.

Second – Sara’s cousin seems not only rude but able to do some tricks. She locked her room using an amber rock (that now has the door handle INSIDE it).

Third – nobody seems to come to the book presentation – so Andrea would be locked there for a while. But this is not too bad after all, considering he can talk to Navarro.

** SPOILERS **

** How can Marco get a Press Pass? **

Press Pass has been sent to ‘KULT Underground’ (the web magazine Marco’s working for) without any address – nor Marco’s name – so the situation seems desperate

As Nic suggests, Marco can check his house and see if he can at least LOOK LIKE a KULT Underground journalist

Once he does that (and the operation involves finding a badge, asking someone to print a KULT logo, putting everything together) just go in the open and wait for something to happen.

That’s odd, isn’t it? Well, there’s something weird going on – indeed.

** How can he get a decent picture for his article? **

Both staff members seem lazy, but one is more serious than the other. Getting rid of the more rigorous one is a good starting point.

** What about the presence register? **

Let’s sign it – even if it’s weird that the Museum wants a list of people – after sending specific invitations. Maybe there are TWO reasons for it.

** How can Marco write his article? **

Well, not with his tablet. Marco can go to Sara – who’s better with the computer (and with writing, by the way, and with a lot of other things)

** What is Sara is not ready to let Marco in? **

She has to handle her guest, before letting Marco in. Do that (or better, make her do that)

** How can Sara unlock the ambered-door? **

She can’t – she has to wait that Enrica returns and frees the door. That won’t be soon.

** Who’s the odd Gothic girl that’s standing in front of the guard in the Museums Palace hall? **

She may be Sara’s cousin. She’s cool – but she’s also able to move people at will – using something called Medusa’s eyes (as Nic told). 

Her power seems related to eyes. Maybe that’s why she’s not so good with sunglassed guard. Marco cannot find sunglasses too – but Marco can search for something useful to not fall under her spell – something heard in legends

** What about the General Raimondi invitation? **

If Marco got it, go there. He’s shady, but he has something powerful too – and more info about what’s going on.

** What about Andrea? Can’t he do anything but wait for people not to arrive at a presentation? **

Well, he can talk to his mentor – so you can get some of his background story – and he can share with Sara his latest work

** How can Sara be helpful – while waiting for Enrica to unlock her door? **

She can check her phone. She should find Andrea’s chapters and Nic’s single picture for Marco’s article. Do they seem similar? If so, why? Better ask Andrea, in person. Better send Marco to ask Andrea, I mean

** Ok, there’s a really odd similarity between Andrea’s drawings and Gear Chest inscriptions **

And that’s even odder considering that Andrea’s drawings come from a statue that hadn’t them on it BEFORE a single unlucky hit – with a crow involved

Isn’t there anything ELSE that seems connected? No. Are you sure? Don’t you have found something from Marco’s relative? Check it. Three things CAN’T be a coincidence – and the fact that we’re talking about ancient Gods can’t be good

** How can the gang know more about a forgotten God? **

You can ask an expert about it – and find his lost book – that contains a reference to another older one – that has a whole missing chapter – exactly the one related to the God you’re looking for. Good, isn’t it?

You can follow that lead – and find a person that won’t deny knowing a lot more – even if he’s not willing at the moment to share

** How about push-away-Enrica? **

As I said Marco can do some tricks too. Ok, he can do that – with a mirror

** What can Enrica do once she’s cooperative? **

She can unlock her room – and let Sara have access to her computer, for once. And – uh – let you find her precious possessions (other than the amber rock): a scroll (in Greek) and a wand.

Sara can read the scroll – and find what Enrica still needs (a crow feather – but BLUE)

** What about crows in the game? **

Well, it will be a long story – but you can find at least one near home. Some food in a specific spot and you’ll be able to grab one. Almost. Anyway, you’ll find a feather – even if regular, and I mean black.

** How can Marco change the color of birds’ parts? **

Marco may try some new powerful color product – you’ll find it in the Public Library – in a room that’s now a small laboratory for a specific public event

** What can Marco do with a blue feather? **

Marco can activate Enrica’s wand – one that’s supposed to open the Gear Chest. A little spoiler: it doesn’t. But it’s helpful so you need it

** How can you get rid of the dumber staff member protecting the Gear Chest – considering he’s annoying and not letting Marco do experiments? **

Marco can offer him free drinks. With Nic’s help.

** How can Marco get the mold of the Gear Chest key?  **

Not in the way you expect. Keyhole is blocked – and even when you won’t be – you can’t get a mold that way. But you can check the Gear Chest. Maybe there’s another part that can be useful to make a key from the amber rock.

** Once you have an amber key – how can Marco make it golden without letting the General have it? **

With a little help from his friends. Marco can ask the social-smarter friend (Sara – if you were in doubt) to distract the General. How, without her out from her house, you may ask. Uh – we’re not in the 80s. There are mobiles!

With the General distracted you can also check another thing if you’re curious

** How can Marco use the golden key – the key Marco should use to open the Chest – if the keyhole is locked? **

Marco can’t. Marco first needs to unblock the keyhole. Yes, I mean Marco should solve the 1600 years old gears puzzle. Can Marco do that? Nope. But, again, Sara could. If you let her have a better look at the inscriptions.

** Once Marco has unblocked the keyhole and used the golden key – what next? **

Marco can see if the liquefying wand works – and yes, it does.

** What does Marco have to do now that there’s the Chest opened, and the amber layer removed? **

Marco can try to free the Chaos God (no, really, Marco can’t) or try to fix the crack and close everything again.

** How can Marco fix the crack? **

He needs a glue

** Marco doesn’t have glue **

Marco doesn’t but there’s a special glue where he found the coloring thing.

** Walt doesn’t let Marco have it! **

Marco should tell him that he needs it for a very important reason. Check him to understand what he may think his top priority

** Really? A glue to fix a crack? **

Yes. A special one. Able to stick forever or almost forever. BUT you can’t close a crack just with glue. You need some material to use to fill the crack, which then you will glue.

** What material? **

Wood. The inner chest is made of wood even if after more than a millennia it seems like a rock. And somewhere there’s some special wood.

** Marco can’t have it. It’s from Jerusalem so I’m sure it’s that. But the priest won’t let him have it **

He must give him something else in return. Something little, and precious. And not his, by the way, even if it’s in his possession.

** Ok. Crack fixed. How can Marco close the chest? **

Ask someone who knows everything. No, not Nic.

** What now? The chest is close, but the gang still has the problem of the statuette in space **

You should ask a friend – who’ll ask a friend – who’ll ask a friend – who’ll ask a friend.

Hey, it’s an ITALIAN game, after all

The enjoy the ending epilogue

Come accennato questo è un periodo un po’ complesso e non sto praticamente riuscendo a fare nulla. Ma questo per fortuna non vuole dire che non posso comunque mostrare ai curiosi qualcosa ancora abbozzato – come l’esterno e l’interno della casa di Cap Tinkertop,

Vedremo quanto mi ci vorrà per riprendere eventualmente anche solo proseguendo a creare le varie ambientazioni, basandomi sulle immagini che Gianluca mi ha fornito.

Last but absolutely not least, there’s another adventure game project called Jerry Todd and The Killer Bulbs (Jerry Todd e i bulbi assassini in Italian) – a project I’m really happy about because I’ll have the pleasure to work with Gianluca Gemelli, a writer I’ve met on-line years ago, thanks to our shared passion about The Three Investigators, and that I’ve followed ever since. In these last few years, he did a lot of translation/adaptation of Leo Edwards books and I simply loved them. So I’ve asked him to create an original story with the same setting, to be used as a plot for a computer game, and in just one day he wrote the short story we’re now going to adapt to be a point-and-click AND/OR a graphic text adventure (I’m still thinking about that).

BUT while I’m thinking about that, this is what I’ve done and, uh, so far I’m really happy about it :-)

This is the sketch of the game map – with Gianluca’s images

The second project I’m working on is still a C64 game, but this time is an arcade game – a platformer, even if quite different compared to Santa’s Rats Issue. It will be a zombie game – with a multiscreen map (of an underground laboratory) full of danger AND, yup, also with a light problem .-)
This image is just my first study about this kind of effect – that anyway may change in the real game.

This project won’t be a solo one – and my partner-in-crime is Andrea Capitani – with whom I’ve worked a lot of times for mobile games.

For this project, I still don’t have an exact time plan.