The web version of AGILE (https://agi.sierra.games)

[doomlazer]

Out of curiosity, is it working any better in Safari 16 at the moment? (now that I've got rid of the postMessage mechanism for syncing the UI thread and web worker; it is using an entry in a SharedArrayBuffer now. It wouldn't surprise me actually if it is now running worse on Safari 16 given this change, but I think I needed to address the animation pauses within Firefox as a priority over Safari 16. Still, it would be interesting to know if it had any impact on Safari 16 either way, for the better or worse.

Safari 16 seems the same, by which I mean very inconsistent. Still no noticeable issues in Safari 17!

Edit: quoted wrong post

[pmkelly]

@pmkelly, what are your thoughts regarding the web version of AGILE? Have you had a chance to try it out yet?

Could you DM me the password?

[lance.ewing]

Could you DM me the password?

In theory, I already have, on the 4th April. I will resend it again now. Let me know if you receive it.

[pmkelly]

Could you DM me the password?

In theory, I already have, on the 4th April. I will resend it again now. Let me know if you receive it.

My mistake - I wasn't paying attention and missed your earlier DM when you sent me the password, sorry about that.

I've spent a little bit of time having a look at it and first of all I have to say it's impressive seeing this running on the web! I like the ability to upload files as a way to avoid legal problems, as well as the fact you have a large collection of fan-made games. Perhaps you can work something out with Microsoft who now own the licenses regarding allowing the full versions online, similar to what sarien.net did.

I tried it both on mac (firefox & chrome) and on iPad. On the former, with both firefox and chrome, I noticed that the behaviour of the keyboard appearance is a bit weird. When the window is narrow, the keyboard appears below the picture; when it is wide enough the keyboard is not visible at all. But between these widths it appears overlaid on top of the picture, which for desktop doesn't seem to make sense - I think better to avoid the keyboard overlay altogether for the desktop. See:

https://www.pmkelly.net/temp/keyboard-narrow.png
https://www.pmkelly.net/temp/keyboard-medium.png
https://www.pmkelly.net/temp/keyboard-wide.png

On iPad (with Safari), I found that the keyboard didn't work very well at all when trying to navigate the menus and type in commands. I made a short video of me trying to play KQ4 which should make the problems clear:

https://www.pmkelly.net/temp/kq4ipad1.mov

This is as far as I've looked into it so far; I will do some more testing later on and give you some more feedback.

[Collector]

Perhaps you can work something out with Microsoft who now own the licenses regarding allowing the full versions online, similar to what sarien.net did.

But not Larry nor DDPG.

[lance.ewing]

I've spent a little bit of time having a look at it and first of all I have to say it's impressive seeing this running on the web! I like the ability to upload files as a way to avoid legal problems, as well as the fact you have a large collection of fan-made games. Perhaps you can work something out with Microsoft who now own the licenses regarding allowing the full versions online, similar to what sarien.net did.

Thanks for giving it a try Peter. I really appreciate the feedback.

Yeah, I was thinking along the same lines regarding Microsoft. I was intending to contact the author of sarien.net to see if he has a contact I could use for that purpose. I guess that this scenario is a little different from the sarien.net one though. In that case, it is a conversion of the game into a different form, whereas I would actually need to host the original game files free of charge. They might be less open to that scenario, particularly given that exactly the same set of files are still being sold online, on sites like gog.com. Having said that, they're all on archive.org, although not sure what Microsoft thinks about that.

I tried it both on mac (firefox & chrome) and on iPad. On the former, with both firefox and chrome, I noticed that the behaviour of the keyboard appearance is a bit weird. When the window is narrow, the keyboard appears below the picture; when it is wide enough the keyboard is not visible at all. But between these widths it appears overlaid on top of the picture, which for desktop doesn't seem to make sense - I think better to avoid the keyboard overlay altogether for the desktop. See:

https://www.pmkelly.net/temp/keyboard-narrow.png
https://www.pmkelly.net/temp/keyboard-medium.png
https://www.pmkelly.net/temp/keyboard-wide.png

Yeah, that is due to it reacting to orientation and resize changes, and is currently deliberate, but is primarily to support mobile devices, where you can't usually alter screen size other than to rotate between portrait and landscape. It deliberately makes the virtual keyboard always available for portrait, assuming there would be space, but hidden for landscape, with an icon added to make the keyboard appear. That felt like the best approach to me when I was testing on my mobile. I felt like having the keyboard icon in portrait on a mobile device was wasting space. That grey area between the two, where the width to height ratio is not one of these cleaner cases, is a bit difficult to decide what to do. For example, at what point is it considered portrait vs landscape? This is where you get the virtual keyboard being shown on top of the screen but with no way to hide it.

I did have a debate with myself a few weeks back about whether to retain the virtual keyboard for the desktop web version, to avoid the kind of cases you've shown. In most cases, I assume people on desktop would have a more standard landscape width to height ratio, but if the window size is adjusted, then it does lead to those kinds of scenarios. Attempting to detect whether it is running on a desktop browser vs mobile browser isn't straight forward though. There are some old ways of doing it that are not recommended anymore. I guess I could go with one of those, but web developers are being strongly encouraged to test for features these days rather than platforms, browsers, device, etc., with the old ways of testing platform/device being on the cards to be deprecated by browsers. I saw a discussion online about using the presence of a touch device as one way, but that doesn't work for my Microsoft Surface tablet, in that I'd prefer that to be seen as a desktop rather than mobile, but due to it having a touch screen, it would be classed as mobile. I think there are many desktop type devices with touch screens these days, so it probably isn't the way to go if the question being asked is whether it is desktop or not. I wondered about trying to detect the presence of a physical keyboard but apparently browsers are deliberately making that kind of thing difficult to detect.

Hmmm, maybe I can just go with the old way of detecting platform, even though it is not recommended anymore, which can at least tell whether it is Windows or Mac, vs something else. I think Linux is difficult, as some mobile devices might report that they're Linux. Devices that report themselves as Android, iPad or iPhone can probably be relied on as well though. So there might be a small group of less common devices in the middle that it wouldn't be 100% accurate for. That is probably fine.

Or I could simply provide the virtual keyboard for all touch devices, regardless of whether they are desktop or not. I certainly wouldn't mind having it on my Windows tablet. I'll have a think about it. I agree that it needs some kind of change, to avoid the kind of thing that you're seeing. So the decision will be between using platform/useragent vs. presence of a touch screen. I would be keen to know your thoughts on which of those two approaches sounds the best. I guess I could also use a hybrid approach between the two.

On iPad (with Safari), I found that the keyboard didn't work very well at all when trying to navigate the menus and type in commands. I made a short video of me trying to play KQ4 which should make the problems clear:

https://www.pmkelly.net/temp/kq4ipad1.mov

This is as far as I've looked into it so far; I will do some more testing later on and give you some more feedback.

Thanks for that. Looking forward to the additional feedback. - Yeah, that is definitely weird alright. What version of Safari is that? @doomlazer reported issues on Safari 16 but what you're showing looks like something different. @doomlazer, is this what you see on Safari 16? Do you see anything like that on Safari 17?

I'll have a think now about what might be causing this.

@pmkelly, does it all work fine on your iPad when using Chrome?

[lance.ewing]

Perhaps you can work something out with Microsoft who now own the licenses regarding allowing the full versions online, similar to what sarien.net did.

But not Larry nor DDPG.

Nor Gold Rush!, right? I think the MacNeill brothers own that now.

Actually, this is a good follow up question: For the 14 AGI games, who currently owns each of them? Am I correct in assuming that Microsoft own: KQ1-4, SQ1-2, PQ, MUMG, and MH1-2 ?

What is the situation with BC?

[doomlazer]

Thanks for that. Looking forward to the additional feedback. - Yeah, that is definitely weird alright. What version of Safari is that? @doomlazer reported issues on Safari 16 but what you're showing looks like something different. @doomlazer, is this what you see on Safari 16? Do you see anything like that on Safari 17?

It seems like the problem in the video isn't specific to Safari. I think it's that when the keyboard is overlaid on the game screen the clicks/touches are registering on first the game screen, then the virtual keyboard and both actions are happening. I get this in both Safari and a Chromium browser, so I assume it's happening for all devices/browsers.

In the fan game I tested, Bob the Farmboy, clicks to the game screen will "execute" any text on the input line, so if you type LOOK while the virtual keyboard is covering the game screen you get:

L - nothing on input line, click/touch registered by game screen does nothing; click registered by VK types L.
O - click on game screen executes the input line text "L", generating a message and clearing input line; click registered by VK adds O to input line.
O - click on game screen dismissed "unknown word" message; click registered by VK adds 2nd O to input line.
K - click on game screen executes input line text "OO" generating a message and clearing input line; click registered by VK adds K to input line.

That's the long way of saying you probably just need to ignore clicks to the game screen where it is overlaid by virtual keys.

[lance.ewing]

Oh... this might be a side effect of a feature I added a couple of weeks ago that I thought was a nice addition. In summary, it sends an ENTER key if the screen is clicked, the idea being that clicking the screen can be used to close text windows. Seems I didn't think it through enough, so will go back to the drawing board on that one, maybe even remove it if I can't get it to work cleanly. But yes, maybe it will be as simple as not calling the handler for game screen clicks when it also is on the virtual keyboard. Will think through whether there are any other gotchas with sending through an ENTER like that. Maybe it needs to be ignored if the menu is open as well.

[lance.ewing]

Oh... this might be a side effect of a feature I added a couple of weeks ago that I thought was a nice addition. In summary, it sends an ENTER key if the screen is clicked, the idea being that clicking the screen can be used to close text windows. Seems I didn't think it through enough, so will go back to the drawing board on that one, maybe even remove it if I can't get it to work cleanly. But yes, maybe it will be as simple as not calling the handler for game screen clicks when it also is on the virtual keyboard. Will think through whether there are any other gotchas with sending through an ENTER like that. Maybe it needs to be ignored if the menu is open as well.

I have removed this behaviour for now. If you both try again, then it should work a lot better when the keyboard is overlaying the screen.

I do like the idea of being able to click the game screen to close an AGI text window, but will need to think through a better approach. I can think of one way, but it would involve changing the code of the interpreter itself, which I try to avoid most of the time. Maybe I can still use something similar to what I was doing, but detect when a standard text window is open so that it only does it in that scenario.

(Only 15 days left until the KQ anniversary date...)

[doomlazer]

It works correctly for me in both browsers now, though I did have to reset the browser history to get the new changes; reloading wasn't enough.

[Collector]

Yeah, the MacNeill brothers have the Gold Rush! IP. I should have remembered that since when I did that package for Sunlight Games I had to have the MacNeill brothers approve everything I did for the final package.

As for BC, isn't that Disney? All of the Disney IPs is probably whole other kettle of fish. Don't know how zealous they will be of such ancient games being played online. Even if you get permission from MS, you may still have to have the same proof of ownership system you are using now for the Disney games.

Does Codemasters still have the Larry IP or did that German company that did the Wet Dreams games get it?

[pmkelly]

Regarding the keyboard: I was initially thinking that having the toggle button for showing/hiding the keyboard visible at all times would be a good approach, then the user can choose. Then I had another idea which I think would be even better for mobile - what about an SCI-style approach where the input window is visible only when you want to enter a command? For devices with a keyboard (desktop or ipad with bluetooth keyboard) this would be triggered by pressing any letter (which would appear as the first character of the command). The user can also click/touch the input line (still visible, or with a "click to type" text or similar) to bring up the text input window.

If you use the browser's native text input mechanism (by temporarily creating a form on the page with a text input field), this would then allow the user to use the keyboard built-in to the OS, which may be easier to use than the custom one in AGILE. I'm not sure how difficult this is given the way the web-based version of the engine works though.

Will get back to you later on the Safari version (wife is currently using the iPad).

[lance.ewing]

Regarding the keyboard: I was initially thinking that having the toggle button for showing/hiding the keyboard visible at all times would be a good approach, then the user can choose.

Yeah, perhaps I should go down this route. I think it might be the best approach. Just need to work out where it would make sense to add the keyboard icon when in portrait mode, as it starts to look a bit cluttered with four icons at the bottom of the screen. I'll play around with putting it in different spots to see what feels best. I didn't feel like I could sacrifice any of the other three icons when in portrait mode. Full screen, joystick, and back icons all felt like they were needed. Some fan made games are not trivial to exit out of, which was why I added that Back icon. It made it really simple to get back to the game selection screen.

Then I had another idea which I think would be even better for mobile - what about an SCI-style approach where the input window is visible only when you want to enter a command? For devices with a keyboard (desktop or ipad with bluetooth keyboard) this would be triggered by pressing any letter (which would appear as the first character of the command). The user can also click/touch the input line (still visible, or with a "click to type" text or similar) to bring up the text input window.

There are some fan-made AGI interpreters that do something like that, i.e. a SCI-like text entry. I think that AGI Player has a mode like that (https://github.com/huguesv/AgiPlayer). And I did consider it for AGILE, but in the end I wanted to keep it as AGI-like as possible. If a game happens to have a hack that makes use of such text entry, then I'd make sure it supports that hack, but not so sure about applying it to all.

One thing I'm certain should be avoided is the way in which SCI pauses the game while the text input window is open. Part of the nature of AGI is how you can type a command while things are also happening on screen.

If you use the browser's native text input mechanism (by temporarily creating a form on the page with a text input field), this would then allow the user to use the keyboard built-in to the OS, which may be easier to use than the custom one in AGILE. I'm not sure how difficult this is given the way the web-based version of the engine works though.

I don't think it would work to use the browser's native text input. Well, it might work in most cases, but it would reduce the overall AGI compatibility. It would be possible to write a game, may even be a few out there already, for which this approach wouldn't be compatible with. The problem is that every key press should go through the AGI key event queue as it happens, even when typing a command. I believe there is a way to bring up the OS's built-in virtual keyboard programmatically from a web app, but there was a reason why I dismissed that. Struggling to remember now what it was, but I didn't feel like it would be an option that would consistently work. After contemplating that for a few days, I decided to go with building my own virtual keyboard mechanism, so that it would be consistent for everyone. I could be certain that all possible keys and key combinations that could be understood by the AGI interpreter were covered off. That was probably the main reason now that I think about it. These modern virtual popup keyboards may not necessarily be able to cover off all possible key codes and key combinations that the AGI interpreter understood.

Will get back to you later on the Safari version (wife is currently using the iPad).

Thanks again. Looking forward to hearing back on that.

[Charles]

One thing I'm certain should be avoided is the way in which SCI pauses the game while the text input window is open. Part of the nature of AGI is how you can type a command while things are also happening on screen.

I agree that typing without pausing sure gives me the AGI feels while playing, but it's important to note that the original interpreter did pause (at least some versions of it). My recollection is specifically the dos herc.mono version.  No clue why it did that... I always assumed it was because of some limitation of the hardware.

For what it's worth, ScummVM has also implemented this feature across all graphic modes as an optional toggle... not that ScummVM should be your model of reference.