To make things easier on players figuring out what to ASK characters about in my game, I’m considering putting certain phrases in bold so that if someone says “business has been slow down at the docks lately” the player knows they can ASK CHARACTER ABOUT BUSINESS or ASK CHARACTER ABOUT THE DOCKS. I’d be quite happy for these phrases to appear in bold literally every time they’re on screen, even in contexts such as “the docks lie to the west. You can see a police car here” etc. as a clue that somebody somewhere will have something to say about them.
Twine’s Harlowe story format has an (enchant:) macro that would be just about perfect for this. It’ll let you put something like this in a header passage that appears throughout the game:
(enchant: "important thing", (text-style:'bold'))
The effect of this is that every usage of the phrase “important thing” will appear in bold, even producing results like “that’s an unimportant thing you don’t need to worry about.” This is precisely the behaviour I’d like to replicate in Inform, warts and all.
I’ve found this topic which seems to suggest I could set up something like this:
To say important thing:
say "[bold type]important thing[roman type]";
However, that would still mean remembering to enclose “important thing” in square brackets every time, which is the sort of manual effort I’d like to avoid (and probably more work than simply coming up with a “to say” shorthand for [bold type] and [roman type], also suggested in that topic).
Is there any way I can produce an effect more similar to Twine’s (enchant:) macro, actually swapping out every appearance of a specific string with a bold version of that string every time it appears on screen?
It’s theoretically possible in Glulx, by using the “filter” output system to run all text through a function before outputting it to the screen, then watching for certain strings in that function and changing the style if so. But that’s going to be extremely annoying to implement without losing other text styling in the process.
This is good to know, though I’m assuming most people will probably be playing in-browser using Quixe. I might opt for a solution that only worked there, but manually bolding phrases seems as though it would probably be preferable (if maybe more of a chore) even then.
Because I dislike the prolixity of I7/10, every work of mine in inform 7/10 has this default definition:
[taken from example chanel 1]
To say i -- beginning say_i -- running on: (- style underline; -).
To say /i -- ending say_i -- running on: (- style roman; -).
To say b -- beginning say_b -- running on: (- style bold; -).
To say /b -- ending say_b -- running on: (- style roman; -).
As you can easily infer, you can “enchant” your text with, for example,
To say im -- beginning say_im -- running on: (- style bold; -).
To say /im -- ending say_im -- running on: (- style roman; -).
(of course, im here means “important message”, but as the saying, YMMV)
Then, as in my code I use
[i]text in italics[/i] normal text [b]bold text[/b]"
you can use, following my example above:
now you should ask this important [im]question[/im]...
HTH (and that I have correctly understand your question) and
I know this isn’t really a solution, but in every Inform 7 project I’ve simplified text styling so it’s not as cumbersome.
To say i: say "[italic type]".
To say b: say "[bold type]".
to say f: say "[fixed letter spacing]".
to say v: say "[variable letter spacing]".
to say p: say "[paragraph break]".
to say l: say "[line break]".
to say /: say "[roman type]".
After jumping: say "You can insert [b]bold[/] type."
You still have to remember to macro-enclose your keywords, but it’s a little more natural to type. Plus, I’d suspect you want the topics only emphasized in dialogue where you want it, as opposed to everywhere, like in inventory and parser messages.
A little tangential, but why use that and not something like:
to say b: say "[bold type]".
to say i: say "[italic type]".
to say r: say "[roman type]".
to say lb: say "[line break]".
to say pb: say "[paragraph break]".
to say rpo: say "[run paragraph on]".
which is what I use and seems faster and easier to implement and use? I know you’re using HTML-style <command> </command> syntax as Inform supports it (using square brackets).
I think automating general text is tough without something decidedly not natural language with a high skill floor for maintaining. Still, it is at least possible to automate the way nouns are printed in lists and such.
before printing the name of a thing:
say bold type;
after printing the name of a thing:
say roman type.
This will change formatting for parser errors, locale descriptions, and responses that print the name of things. Sadly, it isn’t the catch-all for specific outputs, but it can cover a lot ground.
You can append conditions to this, ie, while listing contents.
You can also use this to bold items that are bracketed in room descriptions:
lab is a room. "A [chest] lies open on the floor.".
chest is scenery in lab.
a ball is in lab.
before printing the name of a thing:
say bold type;
after printing the name of a thing:
say roman type.
(alternatively)
rule for printing the name of a thing (called t):
say "[bold type][the printed name of t][roman type]";
lab
A chest lies open on the floor.
You can see a ball here.
Edit, it occurs to me that other activities could be made for similar rules, but I haven’t ever done that and can’t do much more than imagine it.
You could potentially also use Drew’s solution and limit it to a specific kind that applies.
A convo-topic is a kind of thing.
The signed baseball is in Dugout. Signed baseball is a convo-topic.
before printing the name of a convo-topic:
say bold type;
after printing the name of a convo-topic:
say roman type.
Thanks to both Hanon and Hidnook, later I’ll experiment with the simplified macro syntax, but on my choice of macro I point that [b]...[/b] gives an homogeneity with TADS 3’s <b>...</b>; remember that the first step in my coding is deciding the implementation language on the basis of the story & narrative.
OTOH, Hanon’s improvement to Drew’s solution to Damon’s problem seems to me the best one for said Damon’s problem.
This is an intriguing possibility. Would this work for conversation topics that aren’t actual objects existing in the game world? Currently I’ve got things like:
Understand "time of death" and "time of murder" as "[time of death]".
There isn’t an object named “time of death” and I’d hesitate to add one just to make that phrase appear in bold, but could I make “[time of death]” a convo-topic somehow? (This seems like a long shot, but if it works it would come very close to the behaviour that I want.)
No, this is a solid Plan B. It’s essentially what I meant by “a ‘to say’ shorthand for [bold type] and [roman type]” but having the actual block of code to achieve it is likely to be a help for anyone else stumbling across this looking for such a solution. Thanks!
a convo-topic is a kind of thing. time of death is a convo-topic. It is off-stage.
You can just say time of death is a convo-topic. without giving it a location to put it off-stage by default.
There’s nothing wrong with doing this and it can help with the gamification of conversation. In fact, I wrote a prototype once where every character had an attached container kind called “mind” so I could physically and metaphorically control “thoughts” as objects in character’s heads to keep track of their knowledge and demeanor.
a thought is a kind of thing.
nuclear bomb panic is a thought. The printed name is "anxiety about the bomb".
Understand "anxiety/nuke" and "about the bomb/nuke" as nuclear bomb panic.
If Bob's mind contains nuclear bomb panic: [...]
After reading Bob's mind:
say "Bob is pondering [list of thoughts in Bob's mind]."
Thank you! It sounds as though it could significantly reduce the amount of manual formatting involved and might make for better dialogue overall. I’ll definitely give it a go.
You might also find it helpful to use Aaron Reed’s Keyword Interface, which he used in Blue Lacuna. It allows you to highlight significant words in descriptions using colours and text styles, and to distinguish between direction words, important objects and topics. Default actions are defined for objects and directions (though these can easily be changed). It leaves the user to define actions for topics so that they work with whatever conversation system you’re using.
So in my current WIP, objects that can be interacted with are highlighted in blue (default: examining), direction words in green (default: going to), and topics not related to a tangible object in bold (the specific action ask/tell or whatever, needs to be specified as part of the topic definition.
Ah! This sounds like just what I was looking for. I’ll be sure to check it out - and Blue Lacuna too. (That’s been on my to-do list for a while, actually.)