Matching happy and sad people: inverse lookup based on properties

I have some code here which allows you a shortcut if you’ve summoned a happy and sad person who become friends, and you say goodbye, and you want to resummon them.

The base case is below–stuff that figures whether they’re friends isn’t relevant to the problem. But the idea is, people with the same matchnum have the potential to become friends.

"Happy and Sad" by Andrew Schultz

an emoter is a kind of person. an emoter can be happy or sad. an emoter has a number called matchnum.

verbsing is an action out of world. understand "verbs" as verbsing.

carry out verbsing:
	repeat with XX running through happy emoters:
		repeat with YY running through sad emoters:
			if matchnum of XX is matchnum of YY, say "You can also say [b]R [matchnum of XX][r] to reunite [xx] and [yy].";

I’m happy enough with this that I can lay it out as an example if anyone wants to steal it. (We could also use relations. But that’d be another topic.) The matchnums are fixed throughout the game. So this example seems adequate.

But I’m also confused why the below doesn’t work:

carry out verbsing:
	repeat with XX running from 1 to 3:
		let hg be a random happy emoter with matchnum of XX;
		let sg be a random sad emoter with matchnum of XX;
		say "You can also say [b]R [XX][r] to reunite [hg] and [sg].";

So I had this question: why doesn’t the “random (x)” code compile, and can it easily be tweaked so it does?


One can’t use ‘with’ for property lookup like that.

what’s the range of matchnums? If it’s small, it’d be feasible to use an enumerated kind of value anonymous property, which automatically double as adjectives…

Match id is a kind of value. The match ids are match_a, match_b, match_c, match_d.

A person has a match id.

Alice is a person. The match id of Alice is match_b.
Bob is a person. The match id of Bob is match_b.
Carol is a person. The match id of Carol is match_c.

when play begins: repeat with i running from 1 to 20 begin;
  say "[a random match_b person]."; 
  say "[a random match_c person].";
end repeat;

You know, you could use a…

never mind.

1 Like

Thanks! The thing about avoiding relations is, they’re nice, but they can be a memory hog if I’m trying to fit a WIP into z-machine. This is one of those cases where my code seems “pretty good, but I think I can do better.”

I like the idea of match IDs as 1, 2 and 3 (there are only three) aren’t terribly descriptive. I suppose here since I want the user to be able to type “R 1” or “R 2” or “R 3” as a shortcut, it might help me code things, but it might not be fully practical for the users. However, I have a lot of ideas for other matchup code where this could be very handy indeed.

How about this? I believe it compiles down to a simple checking routine, no extra RAM consumed.

Number-matching relates a person (called X) to a person (called Y) when the matchnum of X is the matchnum of Y.
The verb to align with means the number-matching relation.
Definition: a person is emotion-paired if they are happy and they align with a sad person.

Now you can check “if there is an emotion-paired person”.

The downside to “Definition:” is it doesn’t let you take other parameters. “Relates…when” exists to fill that gap.


That’s easily done with one of my favorite cheats:

To decide what K is a/an/-- (unknown - a value) cast as a/an/-- (name of kind of value K):
    (- {unknown} -).

[...] let selected-match be the number understood cast as a match id;
1 Like

Of course if you’re abandoning type-safety, you can also just check “the match id understood”, which points to the same bit of memory (parsed_number).

1 Like

Ha! Should’ve thought of that.

Type safety abandoned me.


FYI, I think you can handle this without using relations or creating type safety issues by assigning a verb meaning the property in question:

A person has a number called match num. The verb to match means the match num property.

Alice is a woman. She matches 4.

Bob is a man. He matches 3.

Every turn:
	let P be a random person matching 3;
	say "[P] matches 3."