Understanding by Relation

I’m flat out astounded by the amount of effort and attention that everyone given this. Thank you all so much!

I didn’t get a chance to look at this yesteday, but I’ve started trying to implement these ideas this morning and I got as far as implementing what you suggested all the way up to my previous reply with everything working perfectly.

Beyond that, I got a little bit lost. I understand it’s supposed to achieve, but I wasn’t sure what I needed to replace and what I needed to keep from the previous source. I hate to ask this, since you’ve put in so much work already, but would you mind posting the entire solution that you’ve come up with please? I just got myself confused with all the ammendments, that’s all.

Well, the easiest way to get a programming geek to answer something is to pose an interesting problem. That’s probably doubly true for programming geeks who happen to also enjoy IF puzzles.

Here’s a complete working example adapted to the terms you already introduced in your previous post. It uses fixed pokemon objects rather than the placeholders you’re using, but the same principle should work for both. It includes the flexible possessive apostrophes, but you can just choose to never change that property if you prefer Gyarados's.

It also fixes a couple of minor issues with the prior version; in particular it simplifies how empty pokeballs are handled (and makes it easier to print the name of them), and it prevents “Bulbasaur” alone from referring to the pokeball (which could be a problem if there’s one outside of the ball too, or if you wanted to open the pokeball and look at the pokemon specifically).

Part - Pokémon

A Pokémon is a kind of animal.
A pokémon has a text called possessive name.
The possessive name of a pokémon is usually "[printed name]'s".

Part - Poké Balls

[ Defining Poké Balls ]
A Poké Ball is a kind of container.
A Poké Ball is usually closed and openable.
Understand "pokéball", "poke ball" and "pokeball" as Poké Ball.

[Understanding Poké Balls by who they contain]
To decide which object is the occupant of (ball - Poké Ball):
	if the ball contains a thing (called mon), decide on mon;
	decide on nothing.

A Poké Ball has some text called the name of the pokémon within.
The name of the pokémon within of a Poké Ball is always "[regarding the occupant of the item described][if the prior named object is not nothing][prior named object][otherwise]empty".
A Poké Ball has some text called the possessive of the pokémon within.
The possessive of the pokémon within of a Poké Ball is always "[regarding the occupant of the item described][if the prior named object is not nothing][possessive name of the prior named object]".

Understand the name of the pokémon within property as referring to a Poké Ball.
Understand the possessive of the pokémon within property as referring to a Poké Ball when the occupant of the item described is not nothing.
Understand "containing [something related by containment]" as a Poké Ball.

[ Disambiguation of Poké Balls when it's unclear or when carried by the player ]
Before printing the name of a Poké Ball while asking which do you mean: say "[name of the pokémon within] ".
Before printing the name of a Poké Ball while taking inventory: say "[name of the pokémon within] ".

[ Group Poké Balls in a room listing ]
Before listing contents of a room: group Poké Balls together.
Rule for grouping together a Poké Ball (called target):
	let source be the holder of the target;
	say "[number of Poké Balls held by the source in words] Poké Ball[s]".

Part - Testing

Bulbasaur is a pokémon.  Geodude is a pokémon.
Gyarados is a pokémon.  The possessive name is "Gyarados[']".

Field is a room.

There is a Poké Ball in the field.  It contains Bulbasaur.
There is a Poké Ball in the field.  It contains Gyarados.
There is a Poké Ball in the field.
There is a Poké Ball carried by the player.  It contains Geodude.

test me with "get pokeball / get gyarados['] pokeball / i / l".

There are a few things that I might do differently, if it were me writing this (that doesn’t mean the way that you’re doing it is wrong, it’s mostly just a matter of preference) – for example, grouping the pokeballs in the room listing without showing their contents makes it unavoidable that you have to examine or disambiguate to find out who’s inside – if you made the pokeballs transparent then they’d automatically become Poké Ball (containing Bulbasaur) for example, or there are other ways to tweak that text.

Also there’s probably no need to have them openable unless you want the player to be able to type open bulbasaur's pokeball. If you stick with the more traditional methods of just throwing pokeballs to both capture and release then that isn’t really necessary – the rules don’t have to follow the limits applying to the player.

2 Likes

Thnks so much Gavin, that’s really helpful.

I’m definitely in favour of Gyarados' , so I’ll definitely keep that clause in. I wouldn’t have made you do all of this if I wasn’t, as everything was working pretty nicely otherwise.

I’m not quite decided about whether players should be able to refer to a pokeball as just Bulbasaur or not. I haven’t got around to building the battle system yet, and I’m not sure what I want to happen when the player is trying to switch between pokemon and what they have to type at that point. I imagine if I want that to behave differently though, I could probably make that functionality conditional (per scene perhaps and have a Battle scene and an Everything Else scene?).

I’m grouping the pokeballs in room descriptions largely for the starter selection situation. I want the player to have to examine the balls there to find out what their options are, as you did in the real games. Again, I’m not sure if this is what I want to do everywhere, and I might just change my mind entirely. I’m actually wondering about maybe having a contents known truth state on each ball so that if the player has examined it previously, then they know what’s in it forever after that.

I don’t particularly have a need for the player to be able to open a pokeball, but at the same time, I don’t want them not to be able to. It’s definitely something I’d try at least. You’re right in that it doesn’t need to be openable as far as Inform is concerned. I may just write some flavour text for opening it without throwing it, and then redirect it to the send out pokemon command.

Well, if you want Bulbasaur to refer to the pokeball again always, simply swap in this line instead:

Understand the name of the pokémon within property as describing a Poké Ball.

If both Bulbasaur and Bulbasaur’s pokeball are in scope (eg. if the pokeball is open) then you can disambiguate between them other ways, such as with:

Does the player mean doing something to a Pokémon: it is likely.
Does the player mean doing something to a Poké Ball: it is possible.

(Or you can use more specific rules for certain actions that only make sense for one or the other.)

Now any ambiguity between a pokeball and a pokemon will decide in favour of the pokemon, but it will still be possible to refer to the pokeball only with the pokemon’s name if the pokemon themselves isn’t directly in view.

Or you could use some when clauses to make it only conditionally understood.

You would need to do something, though, as otherwise it wouldn’t be possible to refer to Bulbasaur itself if any of its pokeballs are around, because all its names are strict subsets of the names used for the pokeball, so the default disambiguation wouldn’t work.

1 Like

Yeah, I was always planning on using those it is likely rules to disambiguate between Pokemon and Pokeballs. I just hadn’t got that far yet.

Just a little update, some housekeeping, and another quick couple of question:

I’ve implemented this solution in its entirety now and everything works wonderfully. I can’t thank you enough for all the effort you’ve put in.

As I was going through and comparing line by line the code I already had against yours, I realised that at some point I made the change from this:

Before printing the name of a Poké Ball while asking which do you mean: say "[name of the pokémon within] ".
Before printing the name of a Poké Ball while taking inventory: say "[name of the pokémon within] ".

to this:

Before printing the name of a pokéball carried by the player: say "[possessive of the pokémon within] ".
Before printing the name of a pokéball (called ball) while asking which do you mean:
	if the ball is carried by the player, say "";
	otherwise say "[possessive of the pokémon within] ";

This is because I discovered that the way I first had it caused the following output when performing an action on one of multiple pokeballs that the player is carrying:

Which do you mean, the Squirtle’s Squirtle’s pokéball, the Charmander’s Charmander’s pokéball or the Bulbasaur’s Bulbasaur’s pokéball?

Obviously not ideal. The change I’ve made seems to have solved the issue just fine.

Finally, the questions: I’m not a big fan of each ball being described as the Bulbasaur's pokéball. Rather any ball that contains a Pokemon should drop the the. I figure I could achieve this by making pokeballs proper-named, but then an empty pokeball appears as pokéball instead of the pokéball. Thinking I had a handle on it, I did this:

To decide if (ball - a pokéball) is proper-named:
	if the ball contains a thing, decide yes;
	decide no;

Unfortunately, this didn’t appear to work. Obviously I’m doing something wrong here, I’m just not sure what.

Also, I’ve noticed that empty pokeballs have a double space before their name:

You are carrying:
  a  pokéball (closed)
  a Bulbasaur's pokéball (closed)
  a Charmander's pokéball (closed)
  a Squirtle's pokéball (closed)

This is obviously comeing from the Before printing... lines. Should I just expand those out to have a condition inside each of them:

if the occupant of the ball is not nothing:

Or is there a cleaner way of doing that?

I noticed the double name printing too, that’s why I changed it to check for listing inventory rather than carried by the player as you originally had it – that fixed it for me. Which command were you using that still ran into it?

Regarding the names of empty pokeballs, that’s why I was printing name of the pokémon within rather than using the possessive, because the former will print empty explicitly for that case. If you want to use the possessive instead then you’ll need to add similar [otherwise]empty text into that.

Though it’s still not quite perfect, as the inventory listing would print a empty Poké Ball.

1 Like

Oh! I didn’t notice that you changed it to taking inventory. I just reached that line of code and thought “Oh, that’s the bit I changed yesterday to fix the double name issue”, and moved past it. Your listing inventory solution is much more elegant than the one I came up with.

I did realise that you’ve used name rather than possessive to eliminate empty, but when I ran your solution in full in a brand new project, I noticed that it also had the effect of dropping all the possessives entirely:

.>[3] i
You are carrying:
a Gyarados Poké Ball (closed)
a Geodude Poké Ball (closed)

I have added an [otherwise]empty to the end of the possessive string, and that’s worked well to eliminate the extra space. I’m not getting a empty pokéball though. It’s printing an empty pokéball just fine for me. No doubt this is due to some minor difference somewhere.

I think at some point that I’m probably going to split the player’s pokémon out from their inventory and have a new x party command or something for listing them. At that point, I’ll probably work towards getting having pokéballs listed just as a pokéball rather than an empty pokéball.