I miss the old days where screen resolution is fixed at 320x200x256. I want to add graphic to my work, and the closest I can find is Adventuron. However, that does not even begin to cover the various devices from C64 to mobile to 4K display.
So my question is: Those of you who did graphic IF, what is the resolution of your images? Or do you use vector graphic and resize accordingly?
One of the old creator system allows 1. Full screen. 2. Horizontal divide. 3. Vertical divide. It has no windowing system, obviously. But later IF do have those. I don’t know if there’s any IF with overlapping windows, but I suppose that anything is possible.
How do you handle on-screen keyboard? What works for tablet won’t work for phone. If I design it to work for phones, it will look and feel clumsy on tablet.
So, any advice on the subject? I tried to search the forum, but cannot find anything discrete beyond some generic advice. Inform doesn’t even care. It simply provides a “show picture” command without worrying about the resolution. I suppose with the HTML+CSS, things are different now, but I dont know how different it is, and what would be a good way to serve a variety of platforms without too much graphic duplication.
TIA
PS: When I’m talking mobile phone IF, I keep thinking about Hitchhiker’s Guide to the Galaxy 30th Anniversary edition. It looks to be a good option for tablet, but not for phone.
This is very difficult to answer because of the range of screen formats and resolutions available nowadays. Clearly, the image has to be large enough to show a nice, discernable image, but small enough to still allow a lot of text to be shown on screen.
As a rule of thumb, for a conventional PC with a horizontal screen with an aspect ratio of 4:3 or 16:9, the image should take up no more than half the screen with the other half left for text. However, this does not take account ot the window size. The window can be resized to any size and orientation and the game needs to allow for that.
For a mobile phone or tablet, the screen needs to be viewed in a vertical format so that there is sufficient room for the virtual keyboard. On most mobile phones, this can take up half of the screen. If the graphics also take up half of the screen, then there is no room left for the text and the game becomes unplayable.
The bottom line is that the graphics have to be wide and skinny (in height). Based on my experience with Adventuron games, I have decided to standardise on 320x100 pixels. That’s a 3.2:1 aspect ratio. It works fairly well on a laptop or desktop PC, but doesn’t leave much room for text on a mobile phone.
The reason for the small image size is so that it can be stored in the compiled HTML file. If the graphics are stored on a server somewhere, you can use bigger images, but there’s a download hit every time you enter a new room.
That’s a great answer. I think the difficulties lies in two aspects: 1. Screen real estate and 2. On Screen keyboard.
Unless I plan to do overlay, transparent keyboard, I think my best bet would be to divide the screen by 3 for image, output text, and onscreen keyboard. I’ll try keeping the screen ratio as you say: 3.2:1, and either stack them vertically on the phone, or side-by-side on PC/tablet.
Thank you for your answer. That is the nudge I need to proceed.
Edit: I’m having trouble highlighting the 4th paragraph as the key solution. Ended up copying the whole thing as solution. Maybe problem with my android phone? I’ll see if I can do it again later on my PC or something.
I have had a lot of problems with mobile keyboards, they often don’t pop up when you need then and then hang around when you don’t. Also they take up too much space on a mobile screen, so when the KB is visible, only a small amount of game text is readable.
I am considering developing a mobile “IF” keyboard. Basically, it will be highly cut down, needing perhaps only querty + minimal punctuation. Perhaps that might work well, and also fix the pop-up problem.
Also, looking into the idea of using the same space for text and graphics; what i call “unified canvas”. The idea is fade the picture and overlay text, and when there’s no text, show the picture. The main drive for this is lack of mobile space, but it could work on desktops too.
You probably don’t need to have full screen graphic if you want to have on screen keyboard. Even maniac mansion only have 2/3 graphic.
The ones that is full size are visual novels. Text would be 1/3 or 1/4 of the screen at the bottom. Choices would be at the center, also overlays the picture. No need for on screen keyboard for those.
Myst also don’t use keyboard. For parser games, however, there’s too many words available as to crowd the screen, regardless whether you type by letters, or choose from a scrolling list.
So, full screen graphic is not necessary for parser based games. Okay for cutscenes.
BTW, building your own onscreen keyboard is pretty easy, assuming you have the opcodes for it. I used to do it in BASIC in just a few lines. However, you may have to roll your own development kit as to have raw bare metal capabilities necessary to control the look and feel of the keyboard.
I’ve also been scratching my head around similar questions, I think. When I made the “trombicula” web/javascript-based Scott Adams interpreter, I wanted to add graphics support but I just couldn’t figure out a good way to do it.
I figured that vector graphics would be the way to go, since it’s been used in old games from nearly the beginning, and that it could be adapted with modern web technologies like SVG.
In some of the old games you had to (sort of) explicitly switch between the graphics and part of the text field, which was a pain and I didn’t want to do that. Alternatively, on a phone/tablet you could let the graphics and the virtual keyboard use up the same space on the screen and switch between graphics and virtual keyboard, but that seemed like a pain to implement. I just don’t know what a good way to do this is. Has this been solved by someone else in a clever way?
I don’t know about being clever, but my approach to the situation would be to use the pre-existing picture opcode #, and put it as a string, just like the text messages, where you have msg#, and that correspondingto the string array. This string will then be executed by Javascript to show a picture. I think this will be a multiline deal, especially with SVG ops, which I approve. However, that’s not the standard way to do it. So if it’s done that way, it has to be treated as expanded edition.
Edit:
Alternatively, you can just force the image to be 8 bit 320x100 or 320x96 in GIF format. The specification allows multiple pictures in GIF (as in GIF Anim), so no problem there. Then the interpreter will translate pic# opcode as Display Gif Picture # from the picture file.
So, I think that’s an easier approach. You still keep the standard while optionally provide 1 extra GIF picture.
I don’t know other picture file format that stores multiple images in one file, but maybe you can use that for a more modern higher resolution images.
And please make sure that the width of text is no more than 40 characters. In fact, maybe 32 characters is good, too. Too many games nowadays have 80 characters or more, and that just make reading the text extremely painful.
Adventuron does actually span all the way from 8 bit to 4K displays, but your graphics have to be in this aspect ratio in order to re-use the graphics. If you drop 8-bit as a target, there is a lot more freedom you afford yourself.
My advice for all the jams I’ve been running is if you want a graphic for modern + retro platforms, then 256 x 80 or 320 x 96 work well.
Personally I prefer EITHER 8-bit style graphics (drawn well or not well), or modern graphics (drawn exceptionally well), or photographs (at full res). What I don’t like is some awful approximation of what people think 8-bit graphics were, which is essentially a photograph converted and smudged into 8-bit palettes and resolution.
If you are going to target a particular 8-bit platform, draw the graphics by hand, and do not downscale. Downscaled graphics (from photos or otherwise) overwhelmingly look awful.
As far as fitting the keyboard on screen, Adventuron forces games into portrait mode on mobile because landscape is basically unusable once the software keyboard is factored in. Displaying a graphic plus a lot of text is a challenge, so writing a game without lengthy location prose is an advantage to make the experience fun on mobile.
To end on a good note, my feeling is that with the text adventures on mobile can be very fun but you need to design for the platform, as not all games will feel equally as good.
One thing I’d like to mention about playing parser games on mobile is that they would be nearly unplayable to me without my phone’s autocorrect. Just typing that sentence, I think my phone corrected about 3/4 of my words.
Autocorrect lets me type quickly by only having to click on the general area of the letter I want and the keyboard app guesses the word from the possible matches in its dictionary. The dictionary is constantly learning and adjusting based on my typing and words I’ve selected out of the suggestions list. Without autocorrect, typing even just “x table” becomes a pain because I have to precisely tap each letter. On this phone each key is about half the surface size of the tip of my index finger, so that sucks.
I mention all this because it’s been discussed in this thread that creating a keyboard overlay would aid mobile users, but I think it’d actually make it more difficult to play because it wouldn’t autocorrect.
I agree with the autocorrect/completion issue, but with a built-in virtual keyboard, it could “learn” the words from the text output. This produces better results than the mobile built-in autocorrect.
Regarding multiple images in one, consider APNG over GIF.
The virtual keyboard can encompass the whole screen. It’s not like you have to avoid picture or text area just to type. Just do a semi transparent overlay or something. Will that work?
That’s an excellent response. 320x96 image resolution is great because it turns out that you can fit 32 (4×8) images into a single 1280x768 image. All you have to do then is crop/clip the image appropriately. Great for ScottKit / SAGA implementation, IMHO. I hope the interpreter writer will be willing to code pic# opcode, at least for those graphical systems.
Maybe put in special case where pic0 and pic1 is combined to show intro/splash screen in the beginning.
If you want to do GIF animation, then you need separate images, obviously. Doing it in browsers gives automatic animation capability.
If you want something sprite based, then you either go multi thread (SCUMM) or do fine grained input as opposed to line based input. INKEY$ or Event(key).
VN has limited animation, mostly on facial expression changes. So, a sentence followed by change in picture, then another sentence followed by another change in picture. Depending on the parser system, this may be easily done.
For SA, it’s impossible without custom made interpreter that expands the capability. With Inform, that can take function that outputs strings, the command that changes the picture can be easily incorporated into the system.