The basic grammar parser is pretty much finished. I've been having some thoughts about terminals and non-terminals. Terminals could be functions so I could have something like:
[wall] -> "StartDrawingWall()" [walltiles] "FinishDrawingWall()"
[walltiles] -> "DrawATile" "MoveToNewSelectedTile" [walltiles]
[walltiles] -> "DrawATile"
The only worry with this, is that I'm overcomplicating things. But this way I could have the computer know which tiles make up a wall and therefore base other decisions off it. The real thing I want to do is have a grammar that given some area of tiled space - will create a building in it. I'm pretty sure it's not hard just to make a box building but I'd like the buildings each to have idiosyncrasies (acloves, ruins rooms, enterance ways, patios etc (this wouldn't be hard to put into the grammar)). Saying that I don't want the grammar reliant on too much of my C# code.
The one possible avenue of attack for this is to have the alpha part (first part of the rule) of the production describe areas larger than one tile.
[grasstile] [grasstile] [grasstile] [grasstile] [wall_tile] [grasstile]
[grasstile] [grasstile] [grasstile] -> [grasstile] [wall_tile] [grasstile]
[grasstile] [grasstile] [grasstile] [grasstile] [wall_tile] [grasstile]
This would really benefit from a more graphical interface. It's also even now for me hard to predict what would happen. I think an endless loop? Of course you'd have a cut off point. The other thing that is important though is when building a room or a house - the computer must know it's a room or a house. That way the grammar can add chairs and people and everything necessary.
Maybe I should just start simple for now it's not an easy problem. The wonderful thing about grammars is that it's very easy to add diversity by only adding a few more rules.
No comments:
Post a Comment