Technical

Synchronisation

Something I would really like to implement is the ability to synchronise with Zoom running on a Mac, so when you plug your iPhone in, all your latest saved games are copied between the two applications, and any story files that you’ve selected get copied onto the phone.

Synchronising over wifi is possible, I suppose, but it would be nicer to have iTunes do it for you when you plug your phone in.

Obtaining games

I haven’t decided on the methods for obtaining stories yet. I think that this should be reasonably easy: provide an interface to the IFDB that works when the phone has a wifi connection. Synchronisation would be nice, but it can’t be the only way that stories are put onto the phone, because PC users would be left out in the cold.

Auto-save

Interpreters running on the iPhone are really going to need this. I doubt users would appreciate a ‘are you sure’ dialog when you hit the home button and losing game state just because a phone call has arrived is really poor form.

Zoom supports this, so this should be easy for Z-Code. glulx doesn’t, though: I’ll have a look at hacking this into the interpreter, but it really needs to be a part of the specification for any IF interpreter (even on the desktop)

Licensing

CocoaGlk is currently licensed under the LGPL and distributed as a framework. This isn’t appropriate for the iPhone, as there’s no such thing as a framework and the LGPL requires things that are statically linked to be under the LGPL as well. That means almost no interpreters as many are under incompatible licenses.

The solution is to change the license to one that is less restrictive: probably the MIT or modified BSD license.

A more serious issue is that Apple’s SDK license prohibits downloading code to interpret: this means that it would be impossible to load any games that were not bundled with the interpreter. I think this is probably a fatal problem: it seems doubtful that many IF authors will be willing to pay the $99 required to get their work onto the iPhone – plus it would mean no Zork, ever.

User Interface

I haven’t really decided on how the UI should work. The basic functionality should be pretty simple, but there are a few issues new to running on a small display:

Complex graphics

Games like moments out of time use a complex window layout that won’t work too well if we use a large enough font to be legible when everything is on screen. So, it would seem sensible to have a Safari-like ability to zoom in and out.

However, games with a more traditional layout won’t really benefit from this, so we’re going to need to be clever and detect when we need to have a zooming display and when a simple, more legible, display is useful – some experimentation is required! The initial version will go for the ‘big but simple’ approach, which should work with the majority of IF games that are out there, but I’m not going to be satisfied until games like City of Secrets and Moments Out of Time run and look good.

Text entry

This is pretty crucial to get right. The iPhone keyboard isn’t ideal for typing lots of stuff in, so CocoaGlk is going to need to help out. Luckily, I can borrow ideas liberally from the Palm interpreters that already exist:

• Tapping on a word in a text window should insert it as input (with an animation + a quick way of undoing accidental taps)
• Tap + hold on the center of the display should pop up a compass rose. Dragging in a direction will enter that direction as a command.
• If possible, I’d like any words the game prints that don’t exist in the autocompletion dictionary to be added, at least for as long as CocoaGlk is running: that should make typing those made up magic words a lot easier.
• There also needs to be a way of getting a list of common verbs. I’m thinking that if a tap+hold on the center brings up a compass, one on the right side of the screen should bring up the verb list – drag to select a verb (the verb under where the user taps would be blank to avoid accidental input)
• Possibly the tap+hold gestures should be duplicated in a toolbar along the bottom of the screen (or only done that way if it works better)

There’s a tap+hold gesture on the left hand side that’s not being used in this scheme, so if someone thinks of some other useful shortcut, that could go there. The reason for using a tap+hold to bring up shortcuts is that dragging is more sensibly used to scroll around the game output.

Even so, I plan to port CocoaGlk as soon as I get my hands on it, at least assuming the requirements for distributing free software aren’t too onerous. $99 for a key doesn’t sound too bad to me, anyway.

I’m not entirely sure what to expect; I haven’t played around with jailbreaking my iPhone, so I’ll be going in blind. What I think is likely, however, is that half of CocoaGlk will port just fine: that is, the GlkClient framework that interfaces with the interpreters. What is less certain is how well the UI half will port: that is, GlkView. If NSTextView is ported, and the typesetter behaves the same way, then it’s going to be really easy to get the UI working in some manner, and probably not that hard to support all the features of blorb.

Getting games onto the phone is also a bit of a challenge. I think that taking some of Zoom’s existing inventory management and connecting to IFDB might be a good idea.

I’ll post a beta when I get things working: I imagine a glulx or frotz-based interpreter is likely to be released first. I’ve been thinking about doing something with LLVM to JIT games; something that would be a curiosity on the fast machines that CocoaGlk runs on at the moment, but which could be vital to running games on the much slower iPhone.

Read on for the complete list of changes.

Changes in this version:

• Bug fixes
  • Opening a file that doesn’t exist for random access will now create the file (something that’s required by the glk specification but probably isn’t a good idea in practice)
  • Fixed a memory leak in the More view
  • Fixed a potential infinite loop when cancelling sessions
  • Fixed an issue that could cause the layout engine to run past the end of the text in a view
  • Fixed a memory leak in the GlkPreferences object
  • Fixed a crash that could occur if the glk window was closed before the startup image had finished fading out
  • gestalt_Unicode now returns the right value
  • Buffered put character events are no longer concatenated into put string events if they have a value less than 32 (this could cause file corruption in some circumstances due to the way OS X handles these in NSString objects)
  • putBuffer: events sent to windows now send strings via the automation system – this ensures that broken interpreters that use these instead of putString: events will work with things like skeins, text to speech, etc.
• The GlkView delegate has been updated to make it possible to customize how files are prompted for.
• Added cocoaglk_set_immediate_style_hint(), cocoaglk_clear_immediate_style_hint() and cocoaglk_set_custom_text_attributes() functions to make it possible to implement more complicated font/styling models than the standard glk model.
• Added cocoaglk_get_stream_for_key() to make it possible to pass in extra streams to a client beyond just the main input stream (this is intended for use with clients that can restore a saved game as well as loading an actual game)
• When file streams belonging to the server process are opened for reading in the client, they are now buffered to increase performance for small reads.

When you build an executable and link in the GlkClient library, you might see this while trying to run it:

ahunter:.../build/Development % ./tads-3                   [ Rhyolite ]  2:04PM
dyld: Library not loaded: @executable_path/../../../
../Frameworks/GlkClient.framework/Versions/A/GlkClient
  Referenced from: ./build/Development/./tads-3
  Reason: image not found
zsh: trace trap  ./tads-3

The problem is that OS X isn’t looking in the right place. You need to override the DYLD_FRAMEWORK_PATH in order to tell OS X where to find the client library.

The easiest thing to do is to copy it to the place where your executable is: the build directory if you’re using XCode or the directory you’re running the executable from if you’re using the terminal. Once you’ve done this, set the DYLD_FRAMEWORK_PATH environment variable to ‘.’. In XCode, you can do this by selecting your executables under the ‘Executables’ section of the project and looking at the ‘Arguments’ tab of the Info window.

GlkTerm uses the CocoaGlk library to provide a client interface for developing Glk applications. This allows you to develop a Glk application using XCode or the command line and run it immediately.

I’m going to write some more about developing glk applications for CocoaGlk, but to get started, you’ll need to link to GlkClient framework (included in the download). You will also need to modify your glk source code a bit, and write a main function.

Instead of just including glk.h, you should include the glk.h file for CocoaGlk using:

{[.include-glk /enzymes/chili-cplusplus.php]}

You might also add a glk.h file to your project including just that line if you don’t want to edit your sources. This is required because of the way frameworks work on OS X.

CocoaGlk doesn’t provide a main function, as it is not possible to have a main function in a shared library in OS X, so you’ll need to add this yourself. Unless you’re doing something really unusual, this will always be the same:

{[.glk-main /enzymes/chili-cplusplus.php]}

If you just want to play with GlkTerm, the version of glulxe included with Zoom may be a good starting point. Use the Finder to display the contents of the Zoom package, then navigate to the Glulxe plugin, and display the contents of that to find the client executable. The easiest way to get it to run is to launch GlkTerm and then drag the glulxe-client file to a terminal window.

There is also an updated manual for this version of Zoom.