Dannii wrote:
The problem with using character input is that you'll be emulating what interpreters do naturally, and you'll never be able to emulate it perfectly. There'll be some situation when it doesn't work as people expect, maybe you won't be able to select text, or move the cursor or copy a command. Using the Glk 0.7.1 features lets you use real line input while also intercepting it.
Line input has a couple of big wins - I like that the player could be continuing to type while in the background I'm doing some processing on what the last glimpse of the input line was. That feels smoother.
But I'm not sure how to best handle big changes between the old input line and the new, after a new "snapshot" is taken - particularly in handling the space-bar-to-accept-suggestions. What if they've deleted several characters and then pressed space? If I have to rerun the parser over the new input data it'll be harder to optimise so probably slower; it might lead to the game making invisible suggestions because they're only computed, and then written in, *after* the player has pressed the space key.
At the moment, I'm looking at using character input, and allowing command processing to be interrupted by the user pressing an additional key. Looking at it this way, it's a real shame that glk_select_poll can't recognise character input, as that would let me say "The user's pressed something, get on with handling that" but without having the pause the gameflow to do that. (I can do something similar using a 1 millisecond timer and a normal glk_select call, but I can't help feeling that introducing a deliberate delay is a weird way to speed things up.)
I'll probably get the current version stabilised and out there, and then look at a line input rewrite and see how it goes. If checking for changes in the input line is really fast, then potentially I could use it as a glorified character input anyway...
_________________
inkle: interactive stories
http://www.inklestudios.com
Login
Register
FAQ
Search
Members
