top expert

What is Marbles, D, and the Sinister Spotlight made of?

update.

It’s been so long since my last post! That’s because I have been trying to get Marbles, D, and the Sinister Spotlight ready for beta testing. It’s turned out to be a big job. The game is far more complex than anything I’ve done before, and for a while I wondered if I could ever get it into shape.

It looks like I’ve done it! I posted a call for testers last night. Since we’ve talked a lot about testing, I’ll share my post as an example of how I do things:

Hi everyone! I am working on a very short, dense game with a cat protagonist and could use some testing and feedback. It’s in Inform.

• • It is a thing meant for reading, with some long passages.
  • Ten unique cat actions, with many unique responses.
  • A tutorial system (WIP)
  • Inspired by the Zork CYOA books for young adults.
  • Hints that are only revealed once relevant.
  • For all ages.
  • For persons who want to read the story rather than play it, there is a story mode. I could use feedback on that, too!

I think the game can be completed in twenty minutes, but ideally players will spend some more time to experiment with various cat actions. There is just a lot for Marbles to do!

Very happy to reciprocate either now or in the future! If I haven’t updated this request, I’m still looking.

Thanks in advance.

I’ll let you know how things go.

back at it.

I hope you enjoyed the action processing refresher last time! Let’s continue the relations conversation.

In MDSS, there is a character named D. He occasionally talks about whatever thing happens to interest him at the time.

In Inform, I need a way to identify what interests D. If you’ve been keeping up, you’re probably thinking “this sounds like a relation!” It’s true, it certainly does. Still, there are other, familiar ways of doing things. We could easily come up with a kind. Kinds are like overarching categories. We could have a kind of vase, for instance, or a kind of value, like colors, sizes. In the latter case, we can really use anything that would be helpful or us to use to distinguish the contents of the world.

alternative to relations.

We could have a kind of thing called a curiosity. That would be a good start for a system that tracks and names things that D is interested in.

curiosity is a kind of thing.

Now that our kind is set up, we can declare which items are curiosities.

ball is a curiosity in lab.

or

ball is in lab.
ball is a curiosity.

A kind is a rather abstract thing, though, and we rarely act upon them directly. Instead, they get assigned to or associated with something. A variable, perhaps:

The hue is a color that varies.

or

a ball has a color called hue.

In our example, we might say

a person has a curiosity called the interest.

As a best practice, it is usually good to declare a default.

the interest of a person is usually ball.

We can add a definition to allow for readable phrases:

definition: a thing is fascinating if it is the interest of D.

OK! Working up a little more code…

instead of jumping:
	let L be a list of curiosities;
	say a random fascinating thing in the location;
	say line break;
	say the interest of D;
	say line break;
	repeat with t running through fascinating things:
		say t;
	say line break;
	if the ball is fascinating:
		say "yes.";
	now the interest of D is hat;
	say "now the interest of D is [interest of D].";
	repeat with C running through curiosities:
		add C to L;
	say "[L].";

gets us

>jump
ball
ball
ball
yes.
now the interest of D is hat.
ball, cat and hat.

There’s a lot we can do with this approach, and on the surface, this doesn’t seem so different from our relations example from last time. So why bother?

why bother.

As always, a good answer is “this option makes sense to me and does what I need it to do.” Some key differences:

The contents of a kind are static and have to be set when the project compiles. Relations, on the other hand, are more flexible. To recreate the static conditions of our kind, we could say something like:

interest relates one curiosity to one person.

We don’t have to do this, though.

interest relates one thing to one person.

perhaps a person has varied interests:

curiosity relates things to a person.

One answer, then, is flexibility and dynamism.

The other is answer is readability. Which is more readable to you, the author?

With definitions, we can do this either way:

if the ball is fascinating:

The relation allows us to say things like:

if the ball fascinates D:
---
if the interest of D is:

We have a way of dealing with these things with a kind (only one at a time, of course):

to decide if (fascinator - a thing) interests (fascinated - a thing):
	if fascinator is the interest of fascinated:
		decide yes.

But this is beginning to bring us back to a key point: relations are often more efficiently established and, out of the box, have readability advantages.

But “readability” is down to personal style, cognitive practices, and so forth. I can’t dictate to you what is most readable. Only you know what is best for you. So experiment!

I would like to go further, but it’s hard to say what I’m up to with relations in Marbles, D, and the Sinister Spotlight without first getting into scenes.

i’ve gone on so long, there’s little time left for scenes today.

Like relations, a lot of what they do could be done with variables. Why use them at all? They offer a standard way of doing things, which is useful when reading documentation or sample source code. Scene changes occur outside of action processing, and, although that takes a bit of getting used to, it can have advantages.

What are scenes? They are a way for an Inform project to create temporal spaces. We can refer to those spaces in our action processing rules, or even use them as conditions in out texts. For one to exist, we only need to say it is so:

lunchtime is a scene.

We can’t do anything with it, though, because we haven’t said when it starts.

lunchtime begins when the player is in the diner booth.

There is no way to say something like

carry out entering the diner booth:
	now lunchtime is happening.

Scene changes happen between action-specific rules (called action-processing rules) and Every Turn rules. It’s useful to think of scene change as a follow up to player action.

This is different from what we are probably used to, right? If we changed a variable during a check rule, we could use it right away in the carry out rule that followed.

Philosophically, this is because scenes are largely a design molded by action rather than one triggered by action. This makes sense in our luchtime scene:

lunchtime ends when nothing is on the plate.

But this is all rather airy, isn’t it? I haven’t shown any practical uses for scenes, let alone explained how they might be used with a relation. Let’s try that next time!

Here’s a link to my scratch pad for today’s post.

next.

More on scenes and relations.