So Roodylib has that LinesFromTop routine that allows games to write text from the top of the screen. Personally, I prefer that top-justified look. The downside to using it is that it won't work with games that use PicturesInText (the routine for drawing graphics in the text window) and it can cause bad behavior in DOS interpreters. Since some of those DOS interpreters are not "minimal" ports, there's really no easy way to check for it.
Authors who doesn't really care about whether their text is top or bottom justified should just have the LinesFromTop routine return display.windowlines. Personally, I consider DOS archaic enough that I'd possibly release DOS versions of games just so most people get the "nice experience."
(That said, we'll probably have some online Hugo games in the near future through the use of a web DOSbox instance, so they would definitely have to use DOS-friendly code.)
Thursday, March 5, 2015
Wednesday, March 4, 2015
Weird Parser Tricks
Originally, this was going to be like a 4 part post detailing different approaches to trying to accomplish a certain goal, but man, the problem is really obscure and I don't even feel entirely comfortable treating it like it's a real problem.
The history is, ok, so one of Hugo's early adopters (who disappeared years ago) thought it was important to be able to have a dynamic vocabulary. He thought it was too much of a clue to be able to see what words the game understood. I never thought this behavior was exactly worth the effort involved in creating the illusion, but I thought it seemed like an interesting coding challenge.
More recently, a friend of mine has been playing "The Lurking Horror" for the first time. It got me thinking about whether "uhlersoth" (the password for the pc) was even in the game's dictionary table. It isn't, and I thought about ways to do a similar thing in Hugo.
My first approach involved using ParseError (well, Roodylib's PreParseError, to be precise) to fake understood responses and then checked parse$ letter by letter to see if it matched "uhlersoth." This worked, but the problem with doing important stuff in ParseError is that it doesn't count as an actual turn so if the player types >UNDO, it's likely that the game is UNDOing a turn they don't expect.
To get around this, I even wrote some code that I called a "fake undo" so the game, in those instances, would just give a regular UNDO response without actually doing anything.
Eventually, I decided it was altogether better to have PreParse code that forces a "hey I didn't understand that" message when your password is used outside of the password prompt. If you really don't want the password to be in the game's dictionary table, you could also write it to the dictionary after the game has started (using dict). The way I feel, there isn't an easily available dictionary script to use on Hugo games, and if someone goes to the trouble of writing their own, more power to them. It's not the same IF scene that it was 15 years ago when we worried about these things (treating our games like some secret treasure).
If, at any point, anyone wants example code on how to do any of these things, I'd be happy to share. I just don't want to include it right now since, really, this kind of stuff isn't really important to you guys writing your games out there.
The one thing I decided is worth sharing now is actually the "fake undo" since that PreParseError trick is sometimes used for things like calling people with phones, where you want it to seem like the game understands more answers to >CALL <BLANK> than it actually does (and after doing so, you'd like the game to pretend it's UNDOing the right thing).
Although, to be honest, I'm not entirely certain of this approach so it's still possible it could cause some headaches.
Anyhow, the next goal for me is to finally get the next version of Roodylib out. Hopefully soon!
The history is, ok, so one of Hugo's early adopters (who disappeared years ago) thought it was important to be able to have a dynamic vocabulary. He thought it was too much of a clue to be able to see what words the game understood. I never thought this behavior was exactly worth the effort involved in creating the illusion, but I thought it seemed like an interesting coding challenge.
More recently, a friend of mine has been playing "The Lurking Horror" for the first time. It got me thinking about whether "uhlersoth" (the password for the pc) was even in the game's dictionary table. It isn't, and I thought about ways to do a similar thing in Hugo.
My first approach involved using ParseError (well, Roodylib's PreParseError, to be precise) to fake understood responses and then checked parse$ letter by letter to see if it matched "uhlersoth." This worked, but the problem with doing important stuff in ParseError is that it doesn't count as an actual turn so if the player types >UNDO, it's likely that the game is UNDOing a turn they don't expect.
To get around this, I even wrote some code that I called a "fake undo" so the game, in those instances, would just give a regular UNDO response without actually doing anything.
Eventually, I decided it was altogether better to have PreParse code that forces a "hey I didn't understand that" message when your password is used outside of the password prompt. If you really don't want the password to be in the game's dictionary table, you could also write it to the dictionary after the game has started (using dict). The way I feel, there isn't an easily available dictionary script to use on Hugo games, and if someone goes to the trouble of writing their own, more power to them. It's not the same IF scene that it was 15 years ago when we worried about these things (treating our games like some secret treasure).
If, at any point, anyone wants example code on how to do any of these things, I'd be happy to share. I just don't want to include it right now since, really, this kind of stuff isn't really important to you guys writing your games out there.
The one thing I decided is worth sharing now is actually the "fake undo" since that PreParseError trick is sometimes used for things like calling people with phones, where you want it to seem like the game understands more answers to >CALL <BLANK> than it actually does (and after doing so, you'd like the game to pretend it's UNDOing the right thing).
Although, to be honest, I'm not entirely certain of this approach so it's still possible it could cause some headaches.
Anyhow, the next goal for me is to finally get the next version of Roodylib out. Hopefully soon!
Subscribe to:
Posts (Atom)