Dave McKay

Linux and programming geek; freelance technology journalist and data protection and privacy consultant. Not afraid of a side-hustle.

New TAF Metrics - More Progress

TAF will now collect information on every command entered by the players throught the duration of a game..

This includes:

  • The number of the command (1 .. X, where X is the last command).
  • The command string, as entered by the user.
  • The time when the command was entered (relative to the start time of the game).
  • The amount of time between this command and the previous command (the "thinking" time between the commands).
  • Whether the command was successful or not.

TAF can export this information out to a CSV format text file, for subsequent processing in a spreadsheet.

As a happy side effect, it also the development of a command history fuinction within TAF, allowing the review of commands used so far, and the replay of any previoously used command.

So, silver linings and happy days.

New TAF Metrics - Some Progress

My thinking about the new metrics is that I can record the number of seconds since the start of the game as a timestamp for when each command is entered. I'll also record the time since the last command was entered.

This gives me a time-line of when each command was entered and a ready-made log of the intervals between the commands.

These are both recorded in the trace window preceded by a token/label. These can be easily pulled out of the log file of a game using the Linux grep command and, with some suitable scripting, be converted into a useful format, perhaps CSV.

I also need to work out a way of recording successful commands an unsuccessful commands. There might be a lot of places to try to capture those. The command interpreter passes off most of the actual command parsing and checking to other functions.

We shall see.

Bye Bye Atom, Hello Sublime Text

There's very little that starts heated arguments in the Linux communities quite like a discussion about text editors. For a comparatively unexciting application such as an editor-it lets you type text, right?-the passion and energy that people bring to the defence of their favourite editor is really something to behold.

Perhaps even more surprising though, is the sheer amount of vitriol and vocal hate they'll dump on their most detested editors. And if that happens to be an editor you like and use, well, then you're not much better than the idiots who coded it in the first place.

I have certain expectations when it comes to editors. I write code. I want tabbed windows, advanced multi-file search and replace with regexes, syntax highlighting, bracket matching, code-folding, macros, and a means to compile the code form within the editor. And it must be cross-platform.

But I don't want an IDE. An interactive development environment suits some people, but not me.

I don't want to have any files in my project directories that the IDE needed to create so that it can manage a project. All I want in my project directories are the files I created-or decide for specific reasons to copy in from elsewhere. But all of those files are integral components of the project itself. Not a collection of config files for the IDE.

On Linux I create a makefile. I run the make command to build the project into an application. All I need my editor to do is make it easy to write code, and to run make. That way I have a fast workflow without any superfluous overheads from the editor or IDE. It halps keep my git repositories clean too.

I used to use Atom. It's a fantastic editor for programming, if a little slow to load. But it was free and open-source, so it ticked all the boxes for me and I could put up with the slightly tardy start-up times.

But Atom is a project owned by GitHub. And GitHub is owned by Microsoft. Microsoft has a vested interest in promoting its own IDE, so no surprises that Atom is being abandoned at the end of 2022. Not wanting to wait until then, I've decided to find a replacement and migrate to it now.

It took me all of thirty minutes to pick my new editor.

Atom was, let's say, heavily influenced by a proprietary editor called Sublime Text. It more or less looked like it, felt like it, and functioned like it. Because of that, I knew that Sublime Text could do everything I needed and more. But it isn't open-source, it is proprietary. And it isn't free. It costs £82 for a three-year license. For that you can install it on all of your computers, as long as you're the only person using it on those computers.

It does everything I need right out of the gate. However, the customisation you can do is just awesome-should you need to. I don't think I'll have to do any. Everything I need is already there. A quick ctrl-B calls make and my project is rebuilt.

And, because I insist that my editor doesn't pollute my project directories with config and project files, I sidestep all of the compatibility issues you hit trying to move from one editor or IDE to another. The new one isn't going to read the project files from the old editor, so you end up having losing so much time trying to claw your way back to working build sequences, and so on.

Sublime Text can work with its own internal methodology for projects if you want. But it's equally happy not to. So there was nothing it needed to read an understand that was the legacy of the previous editor, and it won't leave anything like that behind itself, either.

I've tried all of the other editors out there, and the common IDEs. Sublime Text is the closest thing left to my ideal editor. I coughed up the money, and bought a license key.

And it loads in a flash too.

A Meaningful Metric?

I'm toying with the idea of making the score at the end of the game more meaningful.

Currently it gives you a figure based on the completion of puzzles, the places within the game that have been visited, and so on. It's all to do with the things that you've done in the game.

I'm thinking whether there is a way to take the way you've played into account. How many wrong guesses, how long you paused between moves, and so on. Perhaps something that can take into account the hesitancy with which a game is played.

I've got some research to do :)

A Test Drive In More Ways Than One - Part Two

The test drive of TAF with a captive audience of family members didn't go according to plan. In fact, it didn't go to any plan. It didn't happen at all.

My mother-in-law tested positive with COVID-19 on Monday. We'd already spent Saturday and Sunday in her company. It wasn't long before we all fell like flies. My wife, myself, my sister-in-law, brother-in-law, their son, etc. etc. We all contracted COVID-19.

Instead of a pleasant week on the beautiful Island of Lewis and Harris, we self-isolated in a hotel room. And that was even less fun than it sounds.

At least in your own home you can move from room to room, and you have all of your facilities and possessions around you. Five hundred miles from home in a comfortable but quickly boring hotel room, feeling under the weather is a no-fun pastime.

One thing we did manage to do before we had to go into isolation, was to visit the Clach an Trushal stone, Scotland's tallest standing stone.

Clach an Trushal stone

That almost makes up for everything.

A Test Drive In More Ways Than One - Part One

After a long haul from North Wales to an overnight stop in Perth, then onward travel to Ullapool and a two and a half hour ferry crossing we're finally here: back on the Isle of Lewis and Harris, to see family.

It was a test drive for the new (to me) car, a 12-month old Kia Rio 2 ISG, navigating by means of Waze on my phone linked via Android Auto to the 7" head unit in the car. The car was perfect, Waze was amazing.

Also astonishing was the drive from Perth to Aviemore. Once we cleared Perth's gravitational field there was no other vehicle in front of us or behind us all the way to Aviemore.

Final part of the test drive triumvirate is going to be an inaugural flight of TAF with some family members while we're here.

Why Virtual Escape Rooms Are Better

There's a whole bunch of reasons that virtual escape rooms are a better team building exercise than physical escape rooms.

  1. They're moderator-led sessions, so you get feedback on the team's interactions and a transcript of the team's game play.
  2. Because a virtual escape room can involve activities that you can't do in real life, the team really needs to think outside of the box.
  3. They're the most cost-effective way to conduct enough sessions to put all of your staff through a session.
  4. We come to you, so there's no dead time spent in travelling.
  5. Our game play can take place outside, in the virtual landscape. You're not limited to the classic escape room setting of a single room, with a secret adjoining room.
  6. Players can be do dangerous things that you couldn't allow in real life. For example:

    a) Mix powder and water to make a powerful acid, and then drip it into a lock.
    b) Use fire to boil water, or burn through a wall, or send a smoke signal ...
    c) Run along the roof of a train!
    d) Climb a rope into an attic room.
    e) Shoot an arrow trailing a cord and then zip wire between two buildings.
    f) Swim through flooded tunnels.
    g) I could go on all day ...

  7. Do impossible things like travel by teleportation, kill zombies, use invisibility cloaks...

All of this makes our interactive fiction sessions engaging, compelling, and genuinely immersive.

And all accomplished through the power of the written word.

TAF-Specific Web Page on dpocompliance.co.uk

I added a page to the dpocompliance.co.uk website dedicated to the text adventure framework, TAF.

More accurately, i added a web page talking about how using TAF for team building exercises could benefit businesses.

For example, because they'd be person-led, moderated sessions and TAF can produce a transcript of an entire session, I can give feedback that isn't available in other team building exercises.

Lean, Mean, Gaming Machine

I compiled TAF today without any of the debug information. Basically that just means removing the -g option from the CFLAGS line of the makefile:

CFLAGS = -Wall -g `pkg-config --cflags gtk+-3.0`

TAF compiled to an executable binary of just 130 KB!

Yes, that's kilobytes. Sometimes I amaze myself :)

Actually, sometimes the gcc compiler amazes me. Even after all these years.

TAF is on the Main DPO Compliance Website

I updated the website for my business today, and added two brief references to TAF, as a service that I can provide to businesses.

What I'm offering is in-person moderated virtual escape rooms and other interactive fiction-based team building sessions.

To do: I need to improve carousel banner image of TAF, and add a more detailed blog post.

Mutable Set Dressings

I was play-testing a game today and realised there was a need for some more functionality in the TAF program.

Set Dressings are items within a game that don't really affect the game play in the way that problems and objects do.

Instead, set dressings provide texture and atmosphere to a game, and add layers of detail to locations. They may hold clues or information that let the player deduce something, but's as far as they go in terms of game play. Their main purpose is to provide background detail and colour to a location.

Because a set dressing has an associated detailed description the player can ask for more information about a set dresing item, just like they can for a problem, a location, or an object. When the play uses the describe or examine commands on a set dressing, they are shown the detailed description.

What occurred to me today is that a set dressing isn't immutable. It could be modified or altered in some way when a problem is solved. A problem has an unsolved and a solved description. There may be an unsolved and a solved image too. It's perfectly feasible that a set dressing may be changed in some way that means a single detailed description isn't sufficient - there must be an unsolved and a solved detailed description for set dressings too.

This required creating a new GDL attribute called .prob_affects. This attribue is used to create an affects structure that defines a relationship between a set dressing and a problem. When the problem is solved it checks the list of affects structures and looks for set dressings that are affected by the solving of that problem. If it finds any, it sets a boolean bChanged flag in the associated set dressing structure to true.

If the player uses the describe or examine commands on a set dressing it checks the bChanged flag to see whether it should display the unsolved or solved version of the detailed description.

It's a neat way of adding more realism to games.

Let's say there was a problem that had a large balloon full of paint hanging on a string. The player must burst the balloon to get to a hidden key. Obviously, bursting the balloon releases the paint. If the paint falls on a rug below, and the rug is a set dressing, there needs to be a before and after version of the detailed description of that rug.

The Numeric Keypad

The numeric keypad acts as a controller for a subset of the commands. It makes entering movement commands and some other common commands very simple.

Key Command
/ Carrying
* Peek
- Close Trace window
+ Open Trace window
8 North
2 South
4 West
6 East
7 Northwest
9 Northeast
1 Southwest
3 Southeast
5 Up
0 Down
. .time



You'll find that these map onto the numeric keypad in such a way that the number keys 'point' in the direction of the movement command they're mapped to.

It becomes a bit more obvious when you have a numeric keypad in front of you.

Key Pad Function Map
NmLck Carrying Peek Close Trace
NW N NE Open Trace
W Up E Open Trace
SW S SE Enter
Down Down .time Enter

Mindmap of the Main TAF Game Elements

This is a mindmap of the major elements of a TAF game. It was created with the free and open source minder application.

TAF GDL cheat sheet

User Interface - The Three Windows

TAF uses a very simple user interface. It doesn't require anything overly-complicated. Anything too sophisticated will get in the way of the intended look, feel , and atmosphere I'm trying to achieve.

Main Window

The main action takes place in one window. The aesthetic is a throw-back or homage to the era of green screen visual display units that were in vogue when the first text-based adventure games were created.

TAF Main Window

The text is coloured as close as possible to the actual shade of green that was used in the early cathode-ray tube VDUs. The colour is #33F33F, or 51,243,63 in RGB notation.

A text entry field is located at the bottom of the window.

Trace Window

The diagnostic trace window displays information that is only of interest to the developers of the software. It is not intended for player consumption. In normal game-playing circumstances the trace window is hidden.

TAF Trace Window

The text colour is an arbitrary shade of yellow.

Timer Window

This is a digital clock that counts down to zero. The starting value is either a default value of 60 minutes, or a value defined within the current game. The game author can set whatever time limit for the game that they choose.

TAF Timer Window

Having the timer window visible lets the players know exactly how much time they've got left. If they don;t want the aded tension of seeing time tick away the timer window can be hidden. It keeps time whether it is visible or not.

Game Files and the GDL

Games are defined using the Game Definition Language, GDL. Each game is held in a plain text file.

The "keywords" of the GDL language are called attributes. There are over 50 different attributes. They either define something within the game, or define a characteristic of something that has already been defined.

There are ten groups of attributes:

  1. General Game Details Attributes
  2. Place Attributes
  3. Object Attributes
  4. Problem Attributes
  5. Alias Attributes
  6. Clue Attributes
  7. Set Dressing Attributes
  8. Detailed Description Attributes
  9. Sound Effect Attributes
  10. Image Attributes

Game Architecture

TAF is developed in, and runs on, Linux. It is programmed in C, and is compiled with the gcc compiler. It is a lean, fast program. The compiled binary is under 200 KB in size!

TAF is a GTK+ application, making use of the GTK toolkit for its windowing capabilities.

The colours and fonts for the program windows are defined in a CSS file called themes.css.

/* set the font and colour for the text view in the main window */
#game_view {
  font: 24px "DejaVu Sans Mono";
  color: #33F33F;
}

/* set the font and colour for the text view in the trace window */
#trace_view {
  font: 18px "Andale Mono";
  color: #FFFF00;
}

/* set the font and colour for the text entry field */
#text_entry {
  font: 20px "DejaVu Sans";
  color: #33F3FF;
}

/* set the font and colour for the digital countdown timer */
#timer_label {
   font: 140px "Deja Vu Sans Mono";
   color: #33F3FF;
   background-color: #000000;
}

/* set the background colour for text to black */
text {
  background-color: #000000;
}

Other settings are contained within the taf.conf file. This contains a hashed value that acts as a key to allow TAF to run on an approved computer. The other settings define the sound effects files that should be played for three different game events.

  • When a timed event is triggered.
  • When the timer is decremented because the player has received a clue.
  • If the game duration time has expired but the player has not completed the game. This is the "times up" sound.
# hash
.hash_value be933f64

# timed event triggered
.timed_event simple-game-countdown.wav

# decrement timer - clue given out
.decrement_timer arcade-retro-game-over.wav

# run out of game time
.timed_out timer-reached-zero.wav

## end ##