IFComp 2014 – Reviews – And yet it moves

Next up is “And yet it moves” by Orion.  Again, be aware that I may have spoilers in this post, so read at your own risk.

This is the first parser game I’ve played out of this years batch and as I typically gravitate towards those, I was excited to see what this would bring.  When I start a new parser game, I usually do a few things right off that can quickly give me a feel for the quality and depth of the game.  They are simple things that while not universally true, in my experience, there tends to be some validity to them.  First I checked the credits looking for testers.   This game had two, which I’m glad it had some, but they were listed as “my Dad and my Brother”.  Ok…perhaps Orion’s dad and brother are good testers, but whenever I’ve had a family member test my game, I usually don’t get the best of feedback.  It’s family, it’s tough to be truthful with a family member, when you need to be tough…..but who am I to judge the quality of their testing this early on.

Next I tend to try out some simple commands, just to see if they respond with the standard responses or if some effort went into customizing them a bit to add to the atmosphere of the game.  I try “xyzzy” which in this case led to a standard response (no big deal, a lot of good games have gotten away from providing a response, but I like to try anyways).  Then I try going in a direction that is not valid…again standard response (this is just a great opportunity to add to story and atmosphere, instead of thinking, “well why can’t I go north” and the parser responds, “because I said so”)…OK, not a deal breaker, but would have been nice.  At this point I just dive into the game and see what I get.

Well right from the first sentence describing the starting location, I see a small error that sometimes I can overlook.  The first letter of the sentence was not capitalized.  The problem was, it was the very first sentence you see in the very first location you are in.  Something that during testing and development, was probably seen thousands of times.  I’m surprised no one before myself had seen that.  The second problem is that it wasn’t an isolated incident.  This happens throughout the game.

The other big grammatical issue that was everywhere, was improper capitalization of items.  For example, when listing the contents of a location, the game often lists the items with capital letter when it is not a proper-named item.  For example, when in the kitchen:

You can see Virginia, Kitchen Table, benches (on which are geese and vegetables), a cupboard (empty) and ramp here.

That is just awkwardly worded and can be fixed quite easily in code.

I also had a problem with lack of synonyms.  One example is when you are in the Chamber in the initial house, there is some Holy water (again odd capitalization)

Here is a list of commands that I tried:

>drink water
There's nothing suitable to drink here.

>x water
the bottle reads:

Holy water
Bottled in Venice by Holius Waterus Inc.

>open bottle
You can't see any such thing.

>take bottle
You can't see any such thing.

>take water

It’s described as a bottle, I should be able to use bottle as a synonym. I never did find a usage for the holy water, so perhaps it was just some scenery that wasn’t that important so didn’t get the attention that other critical items might have received.

What about the story?

Well enough nit-picking on the technical issues, let me talk about the story a bit.  I actually found the premise, at least in the beginning, somewhat intriguing.  Here we are playing a contemporary of Galileo, trying to help him get his book published without the church finding out.  Some rich historical context here to use and this could have been great.  In fact, the first and second scene were actually decently done (despite the above mentioned technical issues).  There were some minor puzzles that needed solved, nothing too difficult, but I felt like perhaps I was being eased into it.

However, once you get past that, the game devolves into a simple, talk to someone, they tell you to go somewhere else, where you have to talk to someone else or pick up an object (pretty much in plain sight) and then take that to someone else.  A simple A to B to C type of linear game.  In fact at the end of I think Scene 4, it had me gather up different food stuffs for a journey which the journey was entirely in a cut scene, but when I got to the end of my long journey….all those food-stuffs were still in my inventory….I guess I wasn’t so hungry after all.

The final scene was not much more than move a location or two.  Give someone something and watch a cut scene.  So the ending was a bit of a let down and had a rushed feel to it….almost as if time was running out and the author just wanted to get it down in time.

Now, perhaps this review sounds overly negative, so I want to point out some positives. The story and setting has a lot of potential.  I think with a bit of work this author could turn this, perhaps in a  post-comp release, into something much better.  I think it could use some more testing and some attention to little details as there were plenty of areas where the little things were bothersome while playing.  The author tackled some more advanced things, it multiple numbers of similar items, a money system and multiple scenes, that may seem easy, but can throw a lot of gotchas at you if you’re not careful.

Final thoughts

Final thoughts on this….it’s not ready for prime-time yet.  Needs more testing, more polish on the little things which give a richer and fuller feel to the world.  I feel that the story could be expanded on and especially in the later scenes more attention to the puzzles.  While I won’t be scoring this real high in it’s current state, I would look forward to a post-comp release as I did enjoy the historical minded story and would enjoy seeing this expanded and fixed.

Inform 7 Gems – Pathfinding – 1.1

My last post on pathfinding in Inform 7, showed a simple beginning to the power of pathfinding in Inform 7.   I thought I’d expand on this slightly to show a little NPC movement that is a bit smarter than simply following the player around, as I was playing with the code, I found a bug in the code, that I thought I’d like to share the fix first before moving into new territory.

Bug fix from last post

When I fixed the code to be able to move through only open doors, I actually broke it so that if there was not a door between rooms, that the NPC would fail to follow.  So building upon the code from the previous post, we change our every turn rule to be:

Every turn:
	let course be the best route from location of the kitten to the location of the player through kitten-friendly rooms, using doors;
	if course is a direction:
		let the target be the room-or-door course from the location of the kitten;
		if target is not a door:
			try kitten going course;
			 repeat with doorway running through visible doors:
				 if the other side of doorway from the location of the kitten is room course from the location of the kitten:
					if doorway is open:
						try kitten going course;
						say "You hear a scratching from the other side of the door.";
		if location of kitten is the location of the player:
			say "The kitten sits and looks up at you expectantly";
			say "The kitten tried to enter [the location], but thought better of it."

Here we simply add a check to see if the target of the direction the kitten is attempting to move, is a door or room.  If it’s not a door, then the kitten can simple head in that direction.  If the target is a door, then we drop into our normal code from last time where we check for the open / closed door.  The important section of code above is this:

		let the target be the room-or-door course from the location of the kitten;
		if target is not a door:
			try kitten going course;


With that fixed, I do believe the code should work as described from last time.   Now I’ll move on to exploring pathfinding to try and make this all a bit smarter.


I should also note that there are some extensions out there that will wrap a lot of this code up for you.  A few that I’ve looked at before include Patrollers and Planner.  And there is a newer one Problem-Solving Characters, that I want to look at a bit deeper.

So other than perhaps some simple situations we can use those instead.  I like to dig deeper into the code and know how things work, even if I use an extension….so I’ll continue to these subjects…well….because I think it’s fun!

Inform 7 – Paragraph Breaks in Text Substitutions

I’m a bit of a stickler when it comes to formatting of my text.  Not that I get it correct all the time…but it does bother me when I see something out of whack.  As I am continuing to practice my Inform 7 skills and increase my knowledge of the language constructs, I found myself being tripped up with one aspect of paragraph breaks repeatedly….hence this post to try and help me remember this.

One thing I run into enough is just the simple paragraph breaks that follow after hard stops at the end of some text.  (http://inform7.com/learn/man/doc79.html).   This seems easy enough and works the way I expected it too most of the time.

The clock tower is scenery in the town-square.  
The description of the clock tower is "You look up at the clock tower and see the time is [time of day]."

This produces the following results as expected.

>x tower
You look up at the clock tower and see the time is 11:10 pm.


Where I tend to run into trouble is when my description becomes a bit more complicated, where I may have nested logic in there so I’ll have to break it out into a new phrase. BTW: examples are really nonsensical for illustration purposes only…better ways to do things like this I’m sure.

The description of the clock tower is "[clock-tower-description]".

To say clock-tower-description:
	if turn count is 2:
		say "You look up at the clock tower and see the time is [time of day].";
		if turn count is 3:
			say "You really want to see the time again?";
			say "You've looked at this  before."

That produces the following output

town square
You can see a clock tower here.

>x clock tower
You look up at the clock tower and see the time is 9:01 am.

>x clock tower
You really want to see the time again?

>x clock tower
You've looked at this  before.


You’ll notice the extra spacing. between the printed text and the next prompt. To fix that problem is a really easy fix, but wasn’t obvious to me at first.

The description of the clock tower is "[clock-tower-description][run paragraph on]"

Adding the [run paragraph on] phrase is letting the substituted text handle all line and paragraph breaks without the printing of the description adding it’s own.

I’m guessing that even this isn’t the best way to do things, but it is working for me for now.

Creating Interactive Fiction with Inform 7 by Aaron Reed – A Review.

When I got back into the IF world and wanted to start authoring my ownnote-1 I voraciously scoured the internet in search of all the information I could find….and there is quite a bit between the forums, some of the leaders in the field and having many games released with source code. Having spent a few days reading all I could, I stumbled upon Aaron Reed and his blog. Not only did I see he was an accomplished IF authornote-2, but also was one of the leaders in educating others in developing with Inform 7, but also in using interactive fiction as a tool to educate on other subjects. So of course when I noticed he wrote a book, Creating Interactive Fiction with Inform 7, I had to order it right away.

514a8837j6L._SL160_This book is a great introduction to creating interactive fiction in Inform 7. Aaron does a fine job of easing you into creating things by introducing us to interactive fiction, familiarizing ourselves with the Inform 7 application, and begin development of a sample game that we build upon throughout the entire book.

Aaron covers most of the important areas of Inform 7 that you will use in almost every game. From the basic creation of rooms, creating things and placing them in locations and creating custom kinds and properties to making things happen with rules and actions. He also covers some more advanced logic, scenes, conversation models and character interaction. He covers things in just enough detail to understand, often presents areas where we could improve or expand on what he has shown, and gives exercises to show off what we’ve learned by customizing his central game. Again, not everything is covered, or some topics aren’t covered in great detail, but the technical side of the book gives us more than enough to get started and often leads us to learn more.

In addition to the technical side of the book, Aaron often covers aspects of story design and authoring. Everything from creating good descriptions and creating atmospheric text, to story pacing and good conversation and character interaction. Often a book or article will cover either the technical side well or the artistic side well, but rarely both. Aaron does a fine job on both and blends them together nicely.

Regardless your level of expertise with Inform 7 or with interactive fiction creation, I believe Aaron’s book gives great insights for both novices and experts alike. I still refer to it at times when I’m looking for some specific aspect I recall being covered that I’m not remembering or for inspiration on a story element. Price is reasonable and there is a Kindle version available. Well worth the cost. I hope to see more works like this from Aaron or others.

1 – Back around 2002, I played with Inform 6 and created the stereotypical first game, a layout of my house, but real life got in the way and I never went much further. Jump to 2013 and I look to see what has been going on over the last few years and I discover Inform 7. It was a natural choice for me as I was already somewhat familiar and the natural language syntax intrigued me as a programmer.
2 – See Blue Lacuna, billed as the largest work of IF ever written…but the source code is available as well. Great learning available here.

Large interactive objects that act like a backdrop (sort of) – Inform 7

I ran across an interesting problem in my WIP that to solve I went through a couple different solutions before getting something simple to work.

Note:  This may not be the best way to handle the problem and I’m always open to suggestions for improvements.

In my current WIP (one of them anyway), I have a situation where I had a large object that was visible from many rooms.  Let’s say a large tree in my front yard and the rooms are areas around the yard.  There is also one room inside my house that I can see the tree out a window.  My first inclination was to make it a backdrop so it could be seen from those rooms.  Let’s assume that the entire map of the game is those outside locations and that one room in the house.

The shade tree is a backdrop. The shade tree is everywhere.
The description of shade tree is "A great big tree."

Worked great, until i wanted to the tree to be a supporter.  I tried adding the supporter tag to the tree “The shade tree is a backdrop and a supporter.”  This gave me the error: “… as a backdrop and a supporter are incompatible…”  I really needed the tree to be a supporter as it was critical to be able to put something on the tree.  So out came the backdrop and making the tree a supporter worked great.

However, it wasn’t very realistic.  It made no sense that I could go to a different part of the yard and if I tried to look at the tree I would get the message: “You can’t see any such thing.”  Well what’s the best way to be able to interact with an object that is not in the current location?  Put it in scope.

after deciding the scope of the player:
    place the tree in scope;

This worked fine, now I could examine the tree from anywhere.  And if I tried to do anything to the tree away from the actual location where the tree is, I get a message saying “I can’t reach into Under-the-tree” (which is where the tree is located).  Well that’s not a very good message so I need to change the rule for reaching inside a room (which is what you’re doing if you are trying to interact with an object, in scope, that is located in another room.)

Rule for reaching inside a room:
    if the location is up-the-tree:
        if the noun is the shade tree:
            allow access;
            say "You can only look at [the noun] from a distance.";
            deny access;
        say "You can only look at [the noun] from a distance.";
        deny access.

Let’s look at a few things with this last section of code.

  1. We are replacing the rule for reaching inside a room from the standard library so we can run some of our own checks.
  2. We first check to be in the location up-the-tree.  I hadn’t mentioned this before, but I let the player climb the tree and it puts you in a location up-the-tree.  Since the tree is not in that room, but is in-scope (because of our scope rule) without this rule we would have gotten the “Can’t reach into” message.  Which is silly since of course I can “touch the tree” since I’m in it.
  3. So if we are in the tree and the noun is the tree (meaning we are trying to do something to the tree while up the tree) then we allow access, which lets the appropriate rules and actions trigger.
  4. The otherwise’s tell us we are either not up the tree (say in the house) or we are trying to interact with something other than the tree.  In those cases, just display a generic (but more friendly) message.

So now if we try touching the tree for example and we are either under the tree or in the tree, both locations we should be able to touch the tree from we can do this.

instead of touching the tree:
    say "You affectionately touch the tree."

Like I mentioned, I went a couple different directions with this, trying to do more with overriding some standard library rules and going down the path of trying to find a way to create some sort of backdrop / supporter.  (Something I didn’t try that seems kind of obvious now that I’ve typed all this up is making a separate supporter part of a backdrop and then working with it that way, I suspect that may work, but haven’t tried it)

I haven’t tested this code completely, so there may be some flaws or unintended consequences that I’ve not run across yet.  But perhaps this will be useful to someone.

Please feel free to tell me why this is wrong or show me a better way

Edited (9/29/13) to format code a little better

Easy transcription notes in Inform 7

This may not be very clever and I am sure I stole this from somewhere (don’t really even remember to be honest), but here’s a nice little line of Inform 7 code that will allow for easy and clean comments in a game transcription.

Understand "* [text]" as a mistake ("Noted.").

Simply put, this allows you to type in:

>* whatever notes you want to enter

and the parser simply says “Noted.” instead of the usual “That’s not a verb I recognize.” or some similar message.

This makes looking at transcriptions a little easier and also helps separate the notes from the true error messages that you may want to see so you can check what verbiage the user is having trouble with.

If this is your code that I don’t recall snagging it from, let me know and accept my apologies for not remembering.

Update:  I found where I got this from, straight from the manual….LOL (http://inform7.com/learn/man/doc279.html)

Reporting the location of wandering NPCs

I was recently having a discussion with Marshal Tenner Winter on the forums about having your PC standing on a high point where they would be able to peruse the landscape around them and see other NPCs in other locations.  The goal was to print out the locations of each NPC in a friendly way.

Here is some code I came up with that seemed to the trick and only really needs some tweaks to look more grammatically correct or visual appealing.

every turn when player is in cliff:
   say "From here you can see that [run paragraph on]";
   repeat with someone running through persons who is not the player: 
      if someone is in the exterior:
         say "[The someone] is in [location of someone][run paragraph on], ";
   say "[paragraph break]".

I could seem some tweaks and enhancements to this that would need to be made:

    1. Need to check if the location is actual visible from the high vantage point, this code does do that to a certain degree (by region, in this case the region exterior, assuming ALL of exterior is visible from this vantage) and that may be enough. But let’s say your vantage was up a high tree and not only could you see those locations outside, but perhaps also inside just a few rooms in a house that you’re peeping into.
    2. Grammatically, the code above produces some awkward sentences, tweaks would need to be made to conjunctions, location printed names, things like that.

I can see quite a few uses for this and is a nice little piece of code that I’ll keep around.