Pipes! (Again)

I don’t know what it is about this game, but folks seem to like it enough that they decide to make new art for it  Maybe its because my “programmer art” is so atrocious.  That’s probably it.
http://ozzpot.com/stuff/Snaps/Pipes-Redux.jpg

http://ozzpot.com/stuff/Snaps/Pipes-Redux2.jpg

Above are some links two two new skins for the game.

I have contacted the designer, and have made some steps towards “themifying” the YWE version of Pipes! to use his art.

Here is his site: http://www.ozzdesign.com/

When merging Ozz’s designs with my code, I had a sort of “peanut butter in my chocolate/chocolate in my peanut butter” kind of moment.  My game, which was fun but not very pretty, has really become something more like it should with the new art.

Anyway, we’ll see how things go.

World’s First Sandbox Script “Game”

http://ernestpazera.googlepages.com/SandboxGuessMyNumber.xml

http://ernestpazera.googlepages.com/SandboxScript.rar

Yes, it is spaghetti code.  It doesn’t even make use of my new <call>, <return> or <end> commands.

The nice thing about a scripting language built on top of XML is that the interpreter is super easy to write.  I can use FirstChild and NextSibling much of the time for navigating to the next statement.

I wound up needing a stack to keep track of which block I was in (for <if>/<while>).  As it turns out, <if> and <while> wind up being essentially the same  code-wise.  The only difference is that the node pushed to the block stack is the NextSibling in <if>, and the same node in <while>.

At this point, I have 9 total “commands”, but several of them, <if>, <while>, and <set> are rather complex.  The engine can deal with both text variables and number variables (stored in C#’s decimal type).  In fact, a number variable and a text variable can have the same name, as they are stored in different dictionaries, and escaped differently in text output.  I suppose a third “namespace” would be labels, which can again have duplication.

There are no reserved words.  There are no limitations on the names for things, other than a general prohibition on using # and $ in variable names unless you know the side effects of using them.

So, what is this good for?

At the moment, not much.  Yes, it can run a script file, but that’s about it.  It does text input and output.

However, with a small amount of work (mainly making certain methods visible), an application could conceivably load a script, set some text and number variables, run the script, and then examine some text and number variables.

For a slightly greater amount of work, it could have hooks for input/output and setting variables.

Or, if I never find a use for it, at least I can say I’ve made a general purpose scripting language.

The World’s First Sandbox Script

I have implemented <write>, <read>, <set> and <if> (at least in relation to the text type). <goto> and <label> also are implemented and work, but are not shown in the example.

<script>
<write new-line=”">Type in a word.</write>
<read text-name=”first word”/>
<write new-line=”">Type in another word.</write>
<read text-name=”second word”/>
<if text-name=”first word” comparison=”equals” compare-to=”$second word$”>
<write new-line=”">The strings are equal.</write>
</if>
<if text-name=”first word” comparison=”less” compare-to=”$second word$”>
<write new-line=”">$first word$ comes before $second word$.</write>
</if>
<if text-name=”first word” comparison=”greater” compare-to=”$second word$”>
<write new-line=”">$second word$ comes before $first word$.</write>
</if>
<read text-name=”dummy”/>
</script>

Sandbox Script

I really enjoyed making the IF Player and designing the script that went along with it.

In fact, I liked it so much that I decided to make another XML based scripting language, but this one more general purpose.

Because I like to.

This one, however, will also have the ability to store numbers and strings, as well as boolean flags.

Also decided on a simple scheme to output the values or number variables and strings.

String variables will be escaped between two $, like $name$.

Number variables will be escaped between two #, like #value#.

Flag, I decided, did not need to be able to be escaped.

When output or any sort of string is unescaped, it first unescapes strings, then numbers.

The escaping does not nest, to keep it simple.

Decided also to include a number of different comparisons for <if>.

Also decided to put in a <while> loop.

Also decided to put in <goto> and <label>, and <gosub> and <return>.

Anyway, I think it is fun.

IF Player, Rough Cut

Download

Keep in mind it is rough, even though I have added some error checking robustness code, which nearly doubled the LOC.

Comes with a sample xml file with an incredibly annoying but simple “adventure”. The script does showcase all that the interpreter can do.

Oh, and if you want to make an adventure that ends, have an option with a destination of “end”, or simply a room with no options (although this is not tested).

Interactive Fiction Player

Today, I invented a new scripting language for interactive fiction.

I also wrote a console application in C# to play these scripts.

The script is XML based and has a schema like the following:

<rooms start=”">
<room name=”">
<include name=”"/>
<set flag=”"/>
<clear flag=”"/>
<if flag=”">
</if>
<ifnot flag=”">
</ifnot>
<text></text>
<option destination=”"></option>
</room>
</rooms>

The player is about 150 LOC, does practically no error checking, but implements the full schema.

This was an idea I had some time in the last week.  After reading Atwood’s CYOA post (where he quit his job), I thought about all of the Choose Your Own Adventure books I had as a kid, and similar books which are now referred to as interactive fiction.

And so I came up with a minimal set of functionality I would need to make my own IF language.  I figured I needed:

1. A way to inform the player of his current state.
2. A way for the player to change his current state.
3. The ability to have conditions that can be set, cleared, and tested

So, at the moment, I have a total of nine tags that the player can process.

• rooms: this is the root tag of the document, and contains all of the rooms.
• room: this represents a story node.
• text: the contents of this tag will be displayed to the user
• option: this represents a choice the player can make.
• set: this will set a flag variable
• clear: this will clear a flag variable
• if: this will execute the commands within it if a flag variable is set
• ifnot: this will execute the commands within it if a flag variable is clear
• include: this will execute the commands inside of another room

The “include” tag is not strictly necessary, but I put it in there to ease writing of scripts.

So, basically, I have written an interactive simple preprocessor.

Once I have a demo-able script, I’ll share it.

The “THING” class

As stated previously, I am porting a version of Rogue from 1984 originally written in C for DOS into C#.

Many things wind up easy to port.  Most #defines wind up as const or readonly fields.  Everything winds up a static field or method of a single Program class.

However, the THING “class” was the strangest bit to port thus far.

THING represents either a monster or an item.

It is a union.

Each of the two substructs in the union contain pointers to other THING variables.

So, its a linked list *AND* a union.

Now, I’m attempting to do a “faithful” port, which means it is my goal to get as close to the original as possible (within reason), so I’ve got a kind of ugly re-representation of THING in my code.  It works, anyway.

When porting old code like this, I don’t typically question these things too heavily.  I have to rely on the good faith of the developer twenty four years ago.  He had a perfectly good reason for choosing a union.  I just don’t see what it was.

My Ongoing BF “Work”

I continue to pursue the ability to do “useful programming” with a popular EPL which I abbreviate BF (simply because I don’t want to type the name.. thanks Mueller).

I was thinking about a few of things.

1)  There are only 8 instructions, represented by + – > < . , [ ] and usually stored in a byte array.  This is inefficient.

2) A while back, I had some good success with C style macros and BF code.  I’ve since had a few ideas that involve something similar, but with XML.

So, I’ve come up with a bytecode that is useful for making BF programs run faster.

At first, I decided to pack the value 0-7 into the upper three bits of a byte to represent the BF command.  The remaining 5 bits would be a repeat count, so I could shorten the length of the instructions by a factor of 31 (potentially).

But then I realized that while repeat counts make sense for  + – < > they don’t make as much sense for [ ] , . as these operators rarely repeat.

Also a repeat count of 0 is meaningless and would never be used.

Fortunately, this left me with four operations that could use repeat counts and four that didn’t need them, but could use the 0 repeat counts for the other operators.

So, here’s the bytecode map:

0×00: .

0×01 – 0×3f: + (from 1 to 63)

0×40: ,

0×41 – 0×7f: – (from 1 to 63)

0×80: [

0x81 - 0xBF: > (from 1 to 63)

0xC0: ]

0xC1 – 0xFF: < (from 1 to 63)

Yes, these could wind up moved around, but it winds up basically the same.

So, we wind up using ever value from 0×00 to 0xFF,  with repeat counts of up to 63 for those operations that are most likely to use them.

This enhancement should easily speed up an interpreter.

Rogue Port

So what if I don’t have focus?

Along side other things, I am doing a port of Rogue into C#.  In particular, I’m doing a port of the Epyx version 1.48 for DOS.

The method of porting is very similar to the method I use to port old BASIC games into C#.  First, I move all of the code into C# file with every line commented.  Then I go and slowly replace the commented lines with equivalent C# code.

Rogue, however, is rather unlike the BASIC games I have ported.  In BASIC, there was typically only a single listing/file to port.  Rogue has dozens of C files.

So I decided to abuse the “partial class” feature of C#.  Each of the C files went into a CS file with the same name.  There is a namespace around the code, and the code exists within “partial class Program”.  Yes, I have a Program class that spans nearly 40 files.

I can hear the C# people cringe.

But it just goes to show… a language like C# doesn’t force anybody into object oriented programming.

Space Trader for XNA is GO!

Space Trader is a game for Palm, and it is my desire to port it to XNA.

Of course, it has periodically been my desire to port it to the Yahoo! Widget Engine, JavaScript, and plain C#. I have taken up the project a number of times, and failed at it. I’ve got lots of stray code to show for it.

The original was written in C, and is heavily forms based (as one might expect for a Palm app). Fortunately, all of the resources for the UI, strings, alerts, bitmaps, etc were recoverable using the PalmOne tools (they extract them into a nice XML file).

It is also GPL, which means I don’t even need to talk to the author to do this port. And I haven’t.

There is already a C# port for windows, but it has some differences in it that I don’t like, including the “put all of the screens on one window” thing that I don’t care for.

The screens are all 160×160, which really can’t give too much information at a time. Currently, I’m working on it in 800×600.

One of the first things I did was to make a utility app to scan in the resource xml files. I did this mainly for the large number of string and alert resources. The forms I just have to duplicate by hand, since they need to grow in size anyway.

Which brings me to control issues. The Palm version used (duh) the stylus, for which the windows equivalent would be the mouse. However, in XNA the target controller should be the 360 controller and the keyboard (the two controllers that both windows and the 360 support) but more importantly, everything should be doable from a game pad. It’ll be interesting to see what I can come up with for equivalent controls.