Homebrew Cash Bounty - Interactive Fiction Interpreter Needed

[Ikz]

The world is in need of an interactive fiction interpreter for the DS.

There is one interpreter available right now that I know of, papafuji's DSFrotz (Google it). It plays Inform games, but it's a buggy mess and quite incompatible. Try the game break-in.z5, if it behaves for you like it did for me it won't start at all. Some games require 77 characters per line or something or the words scroll off the edge of the screen, unable to be read. It's also a pain to use in general, there's something wrong with every input method available.

Now, I think we all agree that the DS is a perfect handheld for this type of game. Words on top, nice big keyboard on the bottom. Right? So I'm offering on behalf of the IF-playing community a very small commission, for the completion of an Inform interpreter, of $50 US.

Obviously there hasn't been enough demand for this YET, but I'm hopeful that on the biggest DS community an experienced coder will pick it up for this price to be a nice guy. I tried getting together all the tools for programming in ARM or whatever, but I'm a visual basic guy. I'm not gonna waste my time, I'll never be able to learn it.

DETAILS:
- $50 will be sent via Paypal, so they'll probably take a chunk out of it if you don't have a premium account or whatever. I think this is fair since we already have an open-source interpreter (papafuji's) that really only needs to be cleaned up by someone who knows how. Others can add to the pot if they want to see this get done.
- There should be DLDI compatibility with any cart that usually offers it, obviously, to get the .z# files on there.
- Should be compatible with like 99% of existing Inform games, excluding badly coded ones or ones that use oddball features.
- Can have JUST querty/azerty touch-keyboard as long as it's effective, I don't care about character recognition entry at all.
- Must be open-source freeware so it can be put over on the official Inform site when it's done. http://www.inform-fiction.org/zmachine/interpreters.html

If you need more information just ask.

The IF community is a huge one and this would be a truly useful homebrew. I'm shocked that all the 40-year-olds who played Zork when it came out haven't gotten this right yet.

EDIT: ADDITIONAL DETAILS:
- No graphics support required, at all, even for the later official Zork games. I think other interpreters can play such games without the graphics with just the text.
- No sound support required, at all.
- Save/load of x number of save files available from a clean menu, by typing save or restore, as in most interpreters.
- Several font sizes / font faces must be available to use (including the smallest pixel font feasible)
- Background color and text color must be changeable using a preset palette or RGB entry.
- Command-line text font and color CAN be interchangeable independently from the story text, but I'm not sure this is possible in an Inform interpreter (I've only seen it done in TADS.)
- The keyboard is the only thing I will be very anal about. It must be optimized for the small screen, meaning every pixel counts. It must not have any extraneous keys or keys not used in interactive fiction gameplay. I will probably put up a sample of what I think is appropriate once someone makes a go at the project.
- Must have a plain, text menu where the z-code files are listed on startup and the user can scroll through and select them with either the D-pad and A button, or with the touch screen.
- The D-pad and ABXYLR buttons may have some functions redundant to the ones that can be typed; Off the top of my head, the most useful thing for players would be: D-pad=select through letters on keyboard. A=type letter. B=backspace one. X=enter command (Enter key). Y=undo last move (undo command). L=open save menu (save command). R=open load menu (restore command).

 

[SoulAnger]

Wow, I love the idea, sadly i dont got time to make another side-homebrew project. Try posting this at development sites like forum.gbadev.org and palib.info. I'm sure someone would consider there.

 

[Ikz]

Thanks for the advice. I'll put the same offer up on the sites you've mentioned and request that replies be funneled into this forum.

Edit: Unfortunately the gbadev forums refuse to send me that annoying confirmation e-mail. I assume the problem will iron itself out eventually and end up in my mailbox or spam box.

In any case, if anyone has friends that might be interested in taking up the task please let them know where to find this topic. Thanks.

 

[Normmatt]

If your going to request something like this, you should provide more details, like are fancy graphics required, what features it should have and what features aren't required. details are very helpful if someone wants to pick this up.

 

[Ikz]

Thanks for reminding me. It's hard to remember the necessary features off the top of my head.

I will edit the original post with these additions:

- No graphics support required, at all, even for the later official Zork games. I think other interpreters can play such games without the graphics with just the text.
- No sound support required, at all.
- Save/load of x number of save files available from a clean menu, by typing save or restore, as in most interpreters.
- Several font sizes / font faces must be available to use (including the smallest pixel font feasible)
- Background color and text color must be changeable using a preset palette or RGB entry.
- Command-line text font and color CAN be interchangeable independently from the story text, but I'm not sure this is possible in an Inform interpreter (I've only seen it done in TADS.)
- The keyboard is the only thing I will be very anal about. It must be optimized for the small screen, meaning every pixel counts. It must not have any extraneous keys or keys not used in interactive fiction gameplay. I will probably put up a sample of what I think is appropriate once someone makes a go at the project.
- Must have a plain, text menu where the z-code files are listed on startup and the user can scroll through and select them with either the D-pad and A button, or with the touch screen.
- The D-pad and ABXYLR buttons may have some functions redundant to the ones that can be typed; Off the top of my head, the most useful thing for players would be: D-pad=select through letters on keyboard. A=type letter. B=backspace one. X=enter command (Enter key). Y=undo last move (undo command). L=open save menu (save command). R=open load menu (restore command).

 

[DanTheManMS]

Thanks for the advice. I'll put the same offer up on the sites you've mentioned and request that replies be funneled into this forum.

Edit: Unfortunately the gbadev forums refuse to send me that annoying confirmation e-mail. I assume the problem will iron itself out eventually and end up in my mailbox or spam box.

Even if you got the confirmation email, posting a link to a GBAtemp thread on GBAdev would not be a good idea. They've got a fairly strict policy against linking to sites that contain piracy information, even if the sites themselves don't offer any roms at all.

 

[Ikz]

You called it, they just erased all the links to this topic.

I guess I'll just have to watch that topic too. At least they were smart enough not to erase the whole thing.

 

[Trukkle]

This is what I've been wishing for for a while now and I'd be willing to add to the pot.
If it can play allroads, delusns, slouch and photopia, I'll be a happy chap.

Customisable quick buttons would add a lot to the experience. Tap an unassigned button once to set it, tap again any time after that to add it's contents to the input line (not replace what's already there, add to it), touch and hold to modify it's contents. Possibly a similar arrangement for the shoulder buttons, I know of a few games where you have to talk to someone or something to save, rather than having a save command.

 

[Ikz]

Well, I got someone to make the perfect ergonomic keyboard for the bottom screen. Cross one thing off the list of things a coder needs to do for the project.

I'm looking into pixel fonts and menu designs now.

Still no takers?

 

[OneMichael]

I stumbled upon (and subsequently lost) a sub-pixel font that would fit 80 characters in a line, but beyond that you've got a maximum of 64 characters with a 3x5 font. I'd be happy to send you my TrueType Font file. I've made all the characters, and you can even use the font in most Windows applications (and probably other OSes, as well), but I think you'd have to get someone to save a map of it to use it on the DS. I know DSReader can directly use the TTF file, so maybe that's something to look into.
The only character I'm really not happy with is the '#' character, but that's hard to do on a 3x5 grid. Everything on a standard keyboard, including []\!@#$%^&*()_+,./? and more.

 

[Ikz]

I stumbled upon (and subsequently lost) a sub-pixel font that would fit 80 characters in a line, but beyond that you've got a maximum of 64 characters with a 3x5 font. I'd be happy to send you my TrueType Font file. I've made all the characters, and you can even use the font in most Windows applications (and probably other OSes, as well), but I think you'd have to get someone to save a map of it to use it on the DS. I know DSReader can directly use the TTF file, so maybe that's something to look into.
The only character I'm really not happy with is the '#' character, but that's hard to do on a 3x5 grid. Everything on a standard keyboard, including []\!@#$%^&*()_+,./? and more.

That sounds like it would be helpful. 77 characters a line might only be a necessity for a rare case anyway, that case being z-code translation infocom invisiclues files. I'm not sure yet though. 64 sounds about as good as I was going to get too, since I started to look for 3-pixel width fonts.

And yeah, most likely the characters won't be used straight from the font file, but it should be trivial converting them into sprites. Or whatever they'd get converted to.

 

[Iceclaw]

Oooh..a keyboard. That'd rock! Especially because the Scott Adam's games I've found were only using handwriting recognition...that doesn't work well for me.

I'm pretty sure there aren't an Z-interpreter versions of his games..but it'd be nice to have some of my other favorite adventures on my DS.

 

[DanTheManMS]

I stumbled upon (and subsequently lost) a sub-pixel font that would fit 80 characters in a line

http://gbax.gp2x.de/entries/gbax2005/subPixelFont.rar perhaps?

 

[Ikz]

Bounty canceled. DSLinux solved most of the problems.

 

[flap]

Hello,

A few days ago, I had contacted the creator of DS frotz to help him to continue his project. We might work (though he has some work to do first). It is true that there are a lot tiny bugs. (I must have listed 30 of them), but overall most games are quite playable.

However you could try GLKpogo. It is quite good. (though break_in.z5 does not work either there. But it this game is not so brilliant with Gargoyle too...).

About Fancy Keyboard, no english IF player need those special keys such as accent. And bureaucracy for example uses some special keys.

But I am interested. What do you use with DSLinux ? How does it works ?

 

[Trukkle]

Bounty canceled. DSLinux solved most of the problems.

Please don't keep the info to yourself

 

[Ikz]

Hello,

A few days ago, I had contacted the creator of DS frotz to help him to continue his project. We might work (though he has some work to do first). It is true that there are a lot tiny bugs. (I must have listed 30 of them), but overall most games are quite playable.

However you could try GLKpogo. It is quite good. (though break_in.z5 does not work either there. But it this game is not so brilliant with Gargoyle too...).

About Fancy Keyboard, no english IF player need those special keys such as accent. And bureaucracy for example uses some special keys.

But I am interested. What do you use with DSLinux ? How does it works ?

Any DSLinux install comes prepackaged with Frotz. It's just normal Linux Frotz recompiled with the ARM processor in mind. Since I'm such a nice guy I'll give you the details before anyone wastes their time, because it could be quite wasted:

-You need a RAM expansion pak or no games will run on Frotz. You can run Frotz, but at the DS's default 4MB RAM, the operating system and Frotz are all it can run, not the operating system, Frotz, and a story file. It will crash on no added RAM. I'm not sure why, story files are really small. This means official Nintendo Opera (8MB) 2nd-slot pak or one of the old 2nd-slot RAM-added cards (up to 32MB) is required (lame)

-Keyboard on DSLinux is just as small as DSFrotz (lame)

-Command line interface to do anything useful in DSLinux (lame)

-100% compatibility with all z-code .z5 and .dat games I tried, even break-in! (awesome)

So there you have it. The extra RAM is the big problem for most people but I'm glad all my games work. Some still have a 77-character runoff problem but I guess that's just the small screen, can't fix it.

If you're working on DSFrotz then this is your big competition. But it's not perfect either, seeing as most homebrew users probably don't have extra RAM.

 

[flap]

Yep, Actually I had figured that out yesterday.

I'll definitelly stick to DSFrotz 2. That extra Ram requirement is a problem for most DS user. And when plugged that extra equipment decreases a lot the autonomy of the DS. DS linux is also much longuer to load.

The last version worked very well with 95% of the games I tried. Though I reckon that the parameters initially given with DSfrotz is not optimal. There is still a bit of work to do on the documentation and package...

 

[sonny_jim]

I'm slightly annoyed that DSLinux didn't get the bounty. Why offer it in the first place if you were not going to pay up? I'd be more than willing to code a special version of DSLinux especially for playing Frotz that wouldn't need a Slot-2 RAM extension.

 

[DanTheManMS]

I'm slightly annoyed that DSLinux didn't get the bounty. Why offer it in the first place if you were not going to pay up? I'd be more than willing to code a special version of DSLinux especially for playing Frotz that wouldn't need a Slot-2 RAM extension.

I think that's the reason though. He was willing to pay for a custom-made program that met his specifications. While he found an already-existing app that met most of the specs, it wasn't created for him and thus he doesn't feel the need to pay the bounty. At least that's how I'm interpreting the situation.