StoryTllrC64 – your first project (3.1)
10
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.