• entries
743
1924
• views
582987

# Back to work (sigh)

284 views

Well that was the quickest five days of my life. Back to the joy of sales again with no more time off till Christmas.

Got some good progress on the text adventure language over the last few days though. The vm now supports parsing the input and outputting text in a justified manner.

I'm also quite happy with the for_each construct that the compiler now supports. You can do stuff like this:

for item{    string name;    location at;}new location house;location here=house;new item book : name("a book"),at(here) { }main(){    for_each(item i : i.at==here)        {        out "You can see ",i.name,".",end;        }}

which is obviously quite handy. As below, the byte code that the compiler is spitting out is a bit weighty but this doesn't really matter for a text adventure. Would have to look at optimising it if this was ever going to be used as a scripting language for graphical games but I think that is a bit beyond being feasible anyway.

I'd quite like to develop it so you could compile different translation units into object files then have a linker that produced the final "executable" but that seems to throw up quite a lot of complexity. Global variables would have to be late-linked like functions, and I'm not too sure how declaring items and locations or vocabulary would work like that so perhaps it is not appropriate for this kind of thing.

It would certainly be nice to add support for namespaces for larger text adventure projects, but that would involve a complete rethink of the symbol table. At the moment the symbol table is just a stack of lists which works fine for scopes but a namespace-capable symbol table would have to be implemented as a tree and would add a lot of complexity to the parser so the compiler would probably have to be started from scratch.

Perhaps when this compiler and the vm are finished, I can go back and start a new compiler. The vm instruction set is quite simple really so there is no reason I couldn't have multiple languages that targetted it.

Certainly an interesting subject. It looks as if your for each is going through every item in the entire game, and checking to see if it's 'here'. Wouldn't it be better to keep a list of items that are 'here' in each location?

##### Link to comment
Well, the list of items is sort of "built-in", same as the locations. When you do:

new item x : properties("whatever")
{
}

you add a new item to the items list. Conversely, just

item i=whatever;

just creates a handle to one of the items in the list, although you can access item's properties and so on the same through a handle or directly.

This is quite specifically only an engine for writing text adventures so there will always be a static global list of items and of locations and no real need for support for user-containers. Equally, strings are all static and there is no concept of concatenation except for output, or any concept of a heap.

Keeps it just about simple enough for me to keep it working. The language is fully recursive, in that any expression can be made up of arbirtrarily complex sub-expressions. The general idea is to have a core language then a sort of "standard library" of stuff in the language that expresses the common stuff all text adventures use.

I'm trying to balance generality against simplicity to be honest. While I want it to be as flexible as possible, I have to keep reminding myself that I'm not trying to write a C complier.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account