One of the aspects of FyreVM that always frustrated me was the hard-coded nature of the channel layout. The engine, up until now, had a hard-coded enumeration of named channels. There wasn’t really any reason for this, other than it makes consuming FyreVM easier to understand. This was a feature that was nice to have, but now that I’m working on three different sets of source, it’s becoming a royal pain. I also have a better understanding of ways in which FyreVM will be used and ported and removing the tightly-coupled nature of the channel layout from the engine seems like a natural course to pursue.
The current engine also had an output filtering system for the different types of clients we were developing. I removed this from the engine as well. A separate project will be created to offer basic output filtering mechanisms for Silverlight, WinForms (RichTextEdit controls), and HTML. This is a simple layer that takes the contents of each specified channel and replaces standardized markup or characters with the specified output. For instance, if you were doing HTML, you’d replace double carriage returns with a wrapping <p> tag for paragraph. A single carriage return would get a </br> tag. Character styling, including bold, italics, underline, double-strike, subscript, superscript, and fonts, if supported by your output system, can also be implemented through the filtering layer. If a particular game had a very specialized output, the layout engine may be built into a special client that understands the layout markup. So if the game marked up all nouns, the client may know what to do with these words outside of just marking them up. It’s possible they’re links to other data or links to commands to be returned to the game engine. Maybe the UI shows a tooltip for such marked up nouns. This would be considered a non-standard layout engine.
There are a set of channels required for every game and they include Main, Prompt, Location, Score, Time, and Death. Main has to be the first channel.
The engine will now automatically allocate buckets for channel data. Since it uses a hashtable and text named channels, this leaves room for any number of channels a person might want. It also removes any need for ordering the channels. — updated 2:24pm
I plan to have a standard set of channels for public consumption, but the expectation is that the author or publisher can modify the channel list for their own purposes. My assumption going forward is that each game will have its own list of channels. The standard is really just a jumping off point.
The output filtering will also require a set of standard extensions, which will be titled something like FyreVM for HTML or FyreVM for Silverlight or FyreVM for WinForms RichText. This will offer the author easy ways to markup their output so that the client can filter it appropriately.
The client will require a second class library that takes the channel layout and the filtering rules and returns the channel data in the expected form.
The channel layout and filtering rules will probably be XML as the default standard, but I may decide plain text is easier to read and edit.
The output filtering requires character by character reading/writing because of begin and end tags in many cases.
I know this is meaningless to nearly everyone, but eventually the benefits will become obvious.