I don’t understand how much polish people do expect from a “text description/user input” loop. I’m much too glad already current interpreters use polished antialiased fonts and look like an actual book instead of some retro phosphor-on-black . Aside from true AI helping better parser and event narration, I don’t think it can get much better an interface in this medium, unless you want to dumb it down going the CYOA or point’n’click interface.
Certainly. I’m actually thinking of the ebooks model aforementioned: a clean interface listing categories for browsing content and after that they’re in your bookshelf. You then just choose one, click and read. Or, in the case of simply browsing a web page formatted for mobile, having the interpreter automatically register and handle downloads of the given file type.
Seriously, IF is severely misrepresented in the mobile world. You search for IF in the app store and is submitted to lots of lame CYOA…
Zoom already browses the IFDB though (from what I hear – I don’t use Zoom ). An ifdb/mobile is a good idea, you could split that off into its own thread.
However to contribute my own OTness to this, the IFDB is already an excellent IF portal on the desktop, as its plugins allow you to play games with one click. I think you could write a similar plugin for the mobile browser you use depending on the browser. This also seems like a separate issue from selling games in an App store though.
I wouldn’t worry about App stores pushing out small developers, in fact it seems like it has quite the opposite effect. Marketing for those small developers is a whole other story though. There was a very interesting post on this subject here, tinmangames.com.au/?p=1149
Gargoyle seems like a reasonable choice to me for this purpose (but then, it would.) As Eric says, it’s a native OS X app. It doesn’t fully conform to the Human Interface Guidelines but it does implement enough of the common menu items to not look like a clumsy port at first glance.
The most awkward thing about it is the bifurcated nature of the application. One process handles UI events and screen updates, and a separate process (one per game) executes the interpreter and consumes the application-directed events. This results in a lot of IPC chatter and some embarrassing inefficiencies. All screen updates, however small, result in sending a full bitmap over Distributed Objects to the launcher process, which duly renders it in an OpenGL view.
But that awkwardness is a result of needing to support multiple simultaneous game sessions across a lot of standalone interpreters. With a modest effort, you could par down the Glk library to be linked with only a single interpreter, have it automatically launch a designated story, and simply ignore any pesky Apple Events wanting you to launch a second instance. I know this is possible because for a long time this is all the functionality I had.
It does need some UI improvements - an actual help file rather than a stub menu item; a native preferences dialog; save and restore commands - but these are easier to build in the case of a standalone game.
I don’t own an iPhone or an iPad but I’ve thought about porting a more minimal, single-game version of Gargoyle’s Glk implementation to iOS. zarf’s effort is likely to make that unnecessary, which makes a standalone desktop version even more of a niche product. I haven’t pursued it because there doesn’t seem to be much enthusiasm for desktop IF among active authors, and it doesn’t scratch any particular itch for me at the moment.
I managed to miss this whole thread today, although I talked with Jmac a little bit about the subject last night.
My take on the App Store is that it doesn’t change things for IF on the Mac, very much, by itself. If I wanted to offer a particular IF game for Mac users to play (and of course I may want to do that very thing within the next year) then I would absolutely make a stand-alone Mac app. The App Store is a question of distribution, not design. (I’d be comparing that with Steam, really.)
UI polish for a desktop IF game is mostly a matter of making sure there’s a clean set of menu options, and good access to help documents. Maybe integrated note-taking, although that’s even less critical on desktop machines than it is on modern mobile OSes.
Creating a good IFDB browser and game-playing tool is a completely different problem. Absolutely don’t try to tie them together in player’s minds.
). An ifdb/mobile is a good idea, you could split that off into its own thread.