I wonder what we can do about output without actually having a way to play the game …

In a text game, such as I’m sort of imagining here, when you are in a given place (room), you can do various things. You can try to move in a direction; you may be able to take things; you may be able to interact in other ways with the room and its contents. You may type general commands that apply anywhere. And so on.

In a text game, the game reads your inputs as strings, and produces strings as output. In principle, that could be done at a simple terminal command prompt, or in a scrolling text window, or whatever. You could even imagine a version of the program that, instead of displaying text, or in addition to the text, showed a display of what is going on. Could there be some abstract way to represent the game’s behavior so that it could be readily converted to a typical dungeon crawl kind of visible display?

Well, I don’t know, and I’m happy to stick with text for now, but if we can somehow think of ways to accommodate other media, that would be quite interesting. For now, text, but we’ll try to hold on to some semantic information.

One Idea …

What if it worked like this: the Game object takes commands, and changes the internal state of the game accordingly. And it either returns a result, or places a result in a well-known place, so that a game view kind of thing could display the text or otherwise react.

I believe that I’ll start pretty simple: that should not surprise you. But I’ll quickly move beyond a simple text return to at least some object wrapping the response. After all, there are several aspects to a response that we might include:

  • A long description of the place;
  • A short description of the place;
  • A list of the objects in the place;
  • A list of the other entities in the place;
  • …

The response might also include indicators like whether you’ve been here before, to allow the game view to decide between the long or short description. The entities might interact with you: they might throw an axe, or steal something from you. These things might need to be indicated somehow beyond simple text.

We might also have a description of the path to the place. Moving from the woods to the clearing, the message might be “You wander southward for a while”, followed by “You are in a large clearing near a pond. You can hear ducks quacking nearby.”

I don’t know, I’m just making this up. Point is, if you came to the clearing via xyzzy it might instead say “You are carried away by a tornado of dust. Your eyes slowly clear” and then “You are in a large clearing …” and so on.

Since that might get boring, the motion message itself might have various versions, the carried by dust one and a shorter one like “Swoosh!”.

So … still blue-skying here … the Response may have some named sections, location, transition, items, entities, and so on, and those sections might even include an indication of whether their long form had been seen, ever … or recently. Maybe every few times you use the magic word, you get the long message, and otherwise the short one. Who knows what users will find amusing and what game designers will want? There’s always something …

Let’s start by associating a description with a room, with two forms, a long and a short.

I think I’ll write a room test for this, just because we need them. But we may want to drive it from the DSL. We’ll see.

class RoomTest {
    @Test
    fun description() {
        val room = Room("somewhere")
        room.desc("You are somewhere", "You are somewhere very mysterious with a kind of spooky feeling:")
    }
}

And desc:

class Room(val name: String) {
    val moves = mutableListOf<Pair<String,String>>()
    var shortDesc = ""
    var longDesc = ""
    ...

    fun desc(short: String, long: String) {
        shortDesc = short
        longDesc = long
    }

Let’s add some assertions just for drill.

class RoomTest {
    @Test
    fun description() {
        val room = Room("somewhere")
        room.desc("You are somewhere", "You are somewhere very mysterious with a kind of spooky feeling:")
        assertThat(room.shortDesc).isEqualTo("You are somewhere")
    }

And test. Green. Commit: Room.desc can provide short and long description of room.

I don’t know whether we can use these in a DSL statement, but I think we probably can. Let’s do a GameTest.

    @Test
    fun roomDescriptions() {
        val long = "You're somewhere with a long descriptions"
        val world = world {
            room("somewhere") {
                desc("You're somewhere.", long)
            }
        }
        val room = world.roomNamedOrDefault("somewhere", Room("xxxx"))
        assertThat(room.longDesc).isEqualTo(long)
    }

The test runs perfectly. Commit: desc works in the DSL.

That’ll do for now, it’s nearly time for a quick bite and some reading. Rigging up a Response should be easy. Maybe it’s nothing but a cover for the Room … I don’t know.

See you next time!