G'Day....

So after rebuilding the project I think I have condensed things into a much easier format for me to move through. Basically I split some classes, and removed a lot of the jumping around. So once data is "sent" to a class, it just stays there. My old system I was passing variables all over the place and was having a hard time tracking where everything was going when I ran into an issue. Now all the code for any giving thing is basically contained in that one .cs file.

I think I could improve on this even more by building a "interface" for the DataReader. As all the data reading stuff is nearly identical, apart form some method logic, so reading the actual data text file is the same for Areas or Items or w/e, but how that data is used is different. I think this is exactly what interfaces are for, but I played a little bit with interfaces and inheritance and felt it would be a lot easier to just move on with how I already know to do things. I got an interface working, but it felt a little confusing to me. I was just sure that I was not fully grasping what was going on here. I really should have completed my basics stuff before trying this project.. but I just wanted to get started! So I chose to have a DataReader class that each individual "reader" class can call. It basically works out kinda the same. I split all the readers into there own classes but the data reading itself is all handled by a single function externally, so modding that will update all the readers.

This basically brings me back to where I was on Monday's Blog Post before chose to rebuild the project form scratch. The player can exist in a level, inside an Area, that contains items.

The Project Now Has

• A functioning game loop that can take user input string.
• A full functioning Tokenizer and Stemmer to process that string for feeding into the Command Processes
• A full functioning DataImport system for reading formatted text files.
• Fledgling Data File formats for Areas and Items and stuff which the readers process.
  • An entire area including it's items and other objects are all added in a single command to add that area to the LevelMap. [ Layout[0, 0] = ReadData.ImportAreaData("TestArea"); ]
    • The Area DataFile contains a list of item names. These names are read and in turn fed into the itemData processer to construct the items and add them to the Area.
  • These DataFiles will most likely have more data added to it as the project continues, if needed. It is a simple matter now with the DataImporter and various DataReaders separated it is fairly dynamic and should allow easy changing of the kind of data I pull form the files. As I go through the Command Processing changes may need to be made in these files and the final objects they represent.
• A Smattering of other Text Utilities and Buffer stuff and Print Functions to handle the console. (I'll not list all these but 2 of interest may be)
  • Printing to console large text streams with proper word wrap.
  • Printing in a visual way (like a type writer one letter at a time) and space to instantly display final string.

Ok... So... How exactly do I make a Command Processor?

Idea 1 - Dynamic Action / Command Lists

This is the next big stage of the project. I now have an easy way to "build" a scene. Basically my original short term goal was to get the project into a state where I can experiment and build the command processor, which I hope will be the main focus and most interesting part of this project. Basically I now need to work out how to "kick ball" and "move north" and all that. With my main project goals of having it accept much more complex commands than hard coded two word inputs.

The problem here is that I do not really know how to do this. I have some ideas I want to try, but the skeleton system took a lot longer than I thought as I screwed around making the DataReaders, rather than just building some dummy data to work on inside the project. I really should have done it that way, as when I have the command processor, it would be a simple matter of converting the dummy datafiles to actual data files.

Still... it seems to me that I need only two things worked out for the command processor to function.

• A single command input string needs to be boiled down into 2 things. (conjunction inputs with multiple commands can be dealt with after all this is working.)
  • Object - The object the player wants to interact with.
  • Action - What the player wants to do with that object.
• Synonyms : Each Object and Action requires a list of synonyms so the player gets a false sense of the application having an organic understanding  of things.
  • Fetch, Pick Up, Take, Grab, Steal, Pickpocket etc etc ... all boil down to a single Command : "get". It is the command "Get" that the processor recognises.

Now obviously I don't want to have gigantic dictionaries and connected synonym lists for every word in the English Language. I can limit the list of active words by building a word list of actions and objects at the moment the player enters a given area. So if I do not put a chair in the room, a command that says "get chair" can report back a standard error message like "There is no {object} in sight" or w/e. What this means is that specific Actions which are unique to any given object can be part of the Item itself. So as the player enters the room, it builds an action list, and one or more of those actions are added by scanning the area for action and object keywords. So if I have a ball item, then suddenly the processor understands the word "kick" and the word "ball". (as an example)

Still, there are also needs to be a set of global actions that the player should be able to attempt at any point in the game on any object, regardless of the scene. Things like "move", "get", "look", or whatever. Even "kick". (I know I used that example before) These can be attached permanently to the player.

So... on entering a area these things happen.

• A list of Actions keywords that are always available to the player is appended with any actions keywords specific to that area, or items in that area or w/e.
• A list of Objects keywords specific to that area or items in that area or w/e is also created.

Now.. the processor distils the user input command by finding Actions and Objects in that input string. If found, it dose something. If not it returns an error type.

Will this even work? I dunno. But going to try it.

This is the basic idea for how I plan to handle command inputs. My biggest concern is that I am not 100% sure how to handle NOT finding keywords. I am pretty certain I can find keywords and then action upon them... but the player will be producing a lot of commands that are wrong in the context of the game but I want the application to take those failed commands and produce meaningful results. Basically at its core this idea is a "white list"... but some how I need to now work out how to handle all the failures. If there is no ball in the scene how do I handle Get Ball... or if there is a ball in the scene how do I handle and recognise invalid actions. Like say "kiss ball". Something possible but is still technically an error.

For now though. I plan to get the input distillation and keyword list creation and matching functionality. Assuming it even works.

See 'ya Next Time!