Up to Main Index Up to Journal for February, 2016 JOURNAL FOR FRIDAY 19TH FEBRUARY, 2016 ______________________________________________________________________________ SUBJECT: Parsing, Narratives, Messages and Interaction updates DATE: Fri 19 Feb 21:36:09 GMT 2016 I have just updated the public dev branch with more changes. One of which is unusual in that it adds a feature not in the Java version. In all of the previous Java versions input was pretty basic. Assume you have a bag with an apple in it. Now say you wanted to remove the apple. In the Java version, due to a quirk in the parsing, you have to do it backwards: get bag apple Not good, but it worked. In the current WolfMUD things improved as you could now specify things the logical way around: take apple bag The latest update takes this a little further. You can now do things like: take the apple out of the bag The processing to do this is quite trivial and uses stop words[1]. First we pick a list of words to filter out of the input. At the moment the list being used is quite limited and consists of: a, an, from, in, into, of, out, some, the Normally we break the player's input into words and then process them. Processing with stop words adds one more step. After breaking the input into words we remove any stop words. Then we process the remaining words as normal: input: "take the apple out of the bag" words: "take", "the", "apple", "out", "of", "the", "bag" stopwords: ^^^ ^^^ ^^ ^^^ remaining: "take" "apple" "bag" Very simple, but also very effective. There are times when I look at the WolfMUD code and while it works, some parts of it just don't feel right. Case in point: Narratives. The idea behind narratives is that you can describe something and then players can interact with it. For example, consider this description from the tavern: You are in the corner of a common room in the Dragon's Breath tavern. There is a fire burning away merrily in an ornate fireplace giving comfort to weary travellers. Shadows flicker around the room, changing light to darkness and back again. There is a small plaque above the fireplace. To the south the common room extends and east the common room leads to the tavern entrance. Some players may read that and just carry on. Others may find the ornate fireplace intriguing and want to examine it a bit more: You examine an ornate fireplace. This is a very ornate fireplace carved from marble. Either side a dragon curls downward until the head is below the fire looking upward, giving the impression that they are breathing fire. Narratives can be a lot more than simple window dressing. There could be a hidden compartment in the fireplace above. Players could then find and take things from it. Or there could be some writing on it giving a clue of some sort. Some players like the attention to detail and will examine everything they can. Narratives were implemented as a special type of inventory. The idea being to separate narrative objects into a narrative inventory and have normal objects in a normal inventory. That way you didn't need to keep processing narratives all the time. That was the theory anyway - it didn't work. Well it did work, but you ended up processing all of the normal objects and then processing all of the narrative objects anyway, all the time, for nearly every command. So I sat down to sort this problem out once and for all - I had already tried several times before and failed. First of all what is special about narratives? Two things: You cannot pick them up or take them and they are not shown to you or listed like other items in a location. Apart from these two things they behave like normal objects. The solution? Narratives are no longer kept in a special narrative inventory. The Narrative attribute simply marks or tags something as being a narrative. Inventories have been modified to ignore them when listing items at a location and the GET and TAKE commands have been updated so that you cannot take narratives. All of the duplicated narrative handling code has now gone - simplifying the code for commands a lot. Programming is not just about bashing out code. Sometime you just need to step back, have a fresh mug of coffee to sip and have a good think about what you are doing :) Another change of note in this update is the unifying of messages. When commands are processed messages are sent to the participant and observers of the action via the command state messenger. However, messages to the actor were filtered back through the parser to the client and then sent to the player. Now all message handling is unified and handled only by the command state messenger. The special case of handling messages for the actor are gone resulting in more code simplification. Last change of note: Commands are more interactive. If you do something other players can see you doing it. If you get, drop or examine something other players in the same location will see you get, drop or examine something. -- Diddymus [1] Wikipedia stop words entry: https://en.wikipedia.org/wiki/Stop_words Up to Main Index Up to Journal for February, 2016