Messages

Cool initiative!
I'll probably use it if it's as convenient as imgur.
One concern, though, that if you run it on your server and it blows up or something, you'll need to take care of running backups. Did you consider hosting it in the cloud so you won't need to worry about this?

Also, a free and open source alternative to Chevereto that you might want to check out: Pictshare.

And I'd argue against Jack Sparrow being quite as iconic of a character as ones from the 80s and 90s. Is anyone over 10 in any way excited about the newer Pirates movies? Do people still quote lines from any of the movies?

"this will be the day you almost caught Jack Sparrow!"
And people still dress up like him in halloween.
Also, I think we might be a little biased due to our age, as the new movies are the not the ones we grew up with, and additionally it might make time for new movies to live in public culture long enough to become iconic.
Anyway, here's a good link for reference: https://www.empireonline.com/movies/features/100-greatest-movie-characters/
Yep, Elsa is not there, but there are a few characters from the last decade which did not come from Marvel movies or books.

But then you face the problem I mentioned before the "or"- If your only options when you click the piano is LOOK and MOVE, it becomes a bit spoilery, no? I realise two-click systems have the same issue, but it somehow seems worse with context sensitive verbs, because it actually lists it all out.

Right, it's spoilery, which is a problem, but all interfaces except the text parser are spoilery. Verb-lists are spoilery too (only with added frustration because some of the verbs are useless, but players will click those anyway).

I had just imagined 4 (or so) empty verb slots at the bottom of the screen, and when you mouse over something, they fill up with the possible actions you can take. Clicking on an interactable on screen would solidify those options, so then you can click one of them.

Right, so you'll have dead space here (the empty slots)- which is why I thought of maybe just having icons without a background, but it might look ok, I guess. Though, the way I look at it, it's not really a verb-list interface anymore but a hybrid between verb-coin and verb-list (because you reversed the actions from verb -> hotspot to hotspot -> verb, making it behave like a verb-coin).

The positions of the buttons relative to each other is always the same, but the position of all of them together relative to where the user clicked is not. As I said, currently it's just a fixed GUI, not a radial/arc menu.

Ah, ok, so why can't you do the same with a radial or arc menu? Just offset all of it when you're near the edges.

I also write it directly in code, but you can also check out Ink and Twine as possible solutions.

I'm not sure I'd be a fan of dynamic context lists of verbs (... or be required to provide loads of filler outlandish actions)

Exactly the opposite. Because it's dynamic, you can just have a "look" for the windows if you want to, whereas with the static verb-coin you HAVE to have filler actions for interact and talk even if you have no meaningful action to provide (or do the annoying "can't do that" default action).

but is that really something exclusive to verbcoins? You could have a LucasArts style verblist that fills up with context sensitive verbs (up to 15 if you go by Maniac Mansion).

Hmmm, maybe, but how would it work in practice, though?
First, you'll need to reverse the clicking order, making it act basically like a verb coin (i.e click on hotspot and then verb instead of verb and then hotspot). And if you haven't selected a hotspot yet, there will be a ton of dead empty space (because you don't know which verbs will be available to you).
Of course, you can solve the dead space by just drawing the icons without any background, but then it's basically a verb coin only with the verbs layed out in the bottom instead of next to the hotspot.

Finally, your point about using arcs, I'm not sure I understand, could you please explain? The way I looked at it, lets say for simplicity, we have a total of 3 interactions (LOOK, USE, TALK), clicking something on screen would pop up a radial menu around that point, with those actions. If there's something near the upper right corner to interact with, however, those 3 actions would have to be either squeezed together in the lower left (and even for just 3 buttons on a radial menu, of half the size I have them now (16px instead of 32), that's a tight squeeze depending on how far in the corner the item is- and probably not work for 320x200. Or the buttons would have to be moved further away from the interactable, again making behaviour inconsistent.

I meant that there will not be a radial menu, that the menu will always be in arc form and auto adjust based on the number of verbs and placement. And yeah, it won't be consistent, especially near the edges, but I think it can work regardless. Is it consistent around the edges in your current design?

Is the verbcoin a useless or substandard UI if it doesn't have context-sensitive verbs?

I wouldn't say useless, but less efficient than a static verb-list imo. It can still be justified though if you need the extra screen space, I guess.

but people keep telling me that there's this hypothetical verbcoin that is really the best UI ever.
...

• Interactions are LOOK, USE, TALK and OPEN INVENTORY

I mentioned it in the original thread, but I'll repeat it here, that in my eyes, the hypothetical verbcoin that has the potential to be the best UI ever will have a dynamic context based verb list.
So always having the same verbs kind of misses the point. The concept, as I see it, should be to allow defining a list of verbs (or interactions) per hotspot.
You can either do verbs which map to icons, OR you can do fully blown descriptions which will just be textual.
So, for example, in your scene, using the icons scheme you'll have "look", "knock" and "lick" on the windows, but with the text scheme you can have "examine the material of the windows", "look at the big shining star", "knock and scream for help", and "lick the window, yeah, let's get weird".

I had initially thought to use radial menus, because apparently they're the best, but ran into issues with screen edges. Along the edge, I'd have to rearrange the button positions, and depending on the number and size of the buttons, and whether the click is near the corner, the buttons would not fit. So currently, it's just a GUI with 4 buttons in fixed positions relative to each other. Does someone have a suggestion that would make radial menus viable, or is it fine as is?

You can use an arc. The arc can be adjusted when on the edge, so if you're in the top the arc will be below the hotspot and horizontal and if you're in the right the arc will be to the left of the hotspot and vertical, etc.

I still don't get, and never will, how people seems to think that putting a sentence in their language and hit "translate" on a button will give them a good usable translation.

Eventually I suspect that hitting a "translate" on a button will give a perfectly good usable translation, maybe even in the next decade (the technology will just get better and better until it's good enough, and then it will get better and better still).

The end result is that the language as a whole loses massively.

Why?
Language is a means to an end: it's a protocol to convey information, and if it evolves to allow conveying information between more people across the world then that's a good thing. This reminds me of this quote from Samuel Rogers:
"The now fashionable pronunciation of several words is to me at least very offensive: Contemplate is bad enough; but Balcony makes me sick"
From this great talk: https://www.ted.com/talks/anne_curzan_what_makes_a_word_real

My point is that if english is your second language and you need help in translation, then simply ask.

I agree.

Yes, it's a cool feature that should in theory encourage contributions. I already have it for MonoAGS docs website, still waiting for the first contributor.

Wow , how did you figure out that was the problem?

Right, getting a version of the plugin compiled with dotnet 4.0 is probably the best solution.
However, working with the old version might also be possible by setting "useLegacyV2RuntimeActivationPolicy" in the editor's config file (see here: https://stackoverflow.com/questions/6425707/mixed-mode-assembly-is-built-against-version-v2-0-50727-of-the-runtime).
It seems that the editor's config file is not part of the release zip though (I think it should be), but I think (not sure) you can just create an "AGSEditor.exe.config" file and it will be picked up.
So you can try creating that file and putting this inside and see if it works:

Code: ags

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true"><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup></configuration>

Try checking if the file is blocked, see this: https://stackoverflow.com/questions/18016315/an-attempt-was-made-to-load-an-assembly-from-a-network-location-which-would-have

If you'd check out new MonoAGS tzachs is currently working on, it also has a distinction between Objects and Characters.
The "inefficiency" with objects in AGS is that you cannot move them around the game or reference from another room, but that's implementation issue that could be resolved.

Right, just to be clear, in MonoAGS this is already "resolved", you can move objects between rooms and reference them globally just like characters.
Also, characters are just an extension of objects with more skills, so you won't see quirky syntax differences like in AGS (for example: Character.x vs Object.X) and you can pass in a character to any function that accepts an object (GUI controls are also just extension of objects btw, so same rules apply to them as well).

Thanks guys!

And also have a happy one Gurok!

[find]

The discussion started out when people (seemingly, _a lot_ of people) didn't even find the verbcoin: The act of holding down the mouse button was so counter-intuitive to them that it wasn't something they would even try out.

That's a matter of custom.

True to an extent, but that doesn't make the 2 options equal. People who expect to hold down the mouse button will still figure out clicking, but people who expect to click will not necessarily figure out holding the button. That makes the clicking verb-coin superior in my view.

As for the verb-coin itself, I think verb-coin offers some advantages over other multi-verb interfaces. You don't need to move the mouse all over to the bottom of the screen like the lucas arts 9-verb, or to the top of the screen like sierra (or right click a billion times). And verb-coin can contextually disable some of the options, so I won't have "push" or "pull" enabled for the apple core, so it can actually reduce the number of interactions you write, compared to the standard 9-verbs (or, realistically, reducing the number of clicks the player tries, as the developer probably just uses a lot of default responses in 9-verbs).
That's of course, presuming you do have a lot of verbs.
However, if you only have 3 verbs like in the picture above, then it makes a whole lot of sense to just merge talk and interact together and have the 2-click interface, which is simpler and reduces the number of clicks the player needs to make.

I think where verb-coin can truly shine, theoretically at least, is if the actions are completely contextual and dynamic. Meaning that if you have a bible in your inventory and then use the bible on the priest you'll be offered a menu with "give bible to priest", "ask priest about favorite character from the bible", and "knock over priest with bible". This gives you true expressiveness, equal in power only to the text parser, but without needing to guess what was the designer thinking.
I say theoretically, though, because I don't recall seeing any adventure game that actually has a fully dynamic context menu.

People don't even understand a two-click interface any more. I swear some people played through The Fowl Fleet without right clicking on anything (even though it tells you how to do it), and then complained that the puzzles didn't make sense.

Kids today!

It's even worse. I've seen youtubers playing "9 Months In" and not right clicking (and missing vital hints). Youtubers! Those people have played their share of games yet still it didn't even cross their minds that this was an option.
That's why when I wrote "That Damn Dog" I added a timer and if the player does not right click after some time has passed I show a message box with "Did you know? You can right click on stuff". No idea if that worked, though.

We would be interested.

You can try the answer here if you haven't already (it has 2 way conversions- days_from_civil and civil_from_days): https://stackoverflow.com/questions/7960318/math-to-convert-seconds-since-1970-into-date-and-vice-versa?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

EDIT: Oh, and about this:

Another solution vga256 and me tried was to use Julian/Gregorian conversions and that seemed to be quite a good solution but unfortunately AGS doesn't really work well with float

I seriously doubt AGS doesn't "work well with floats", but rather floats as a data format have limitations which means you can't do accurate calculations with them. It's not AGS specific, all languages suffer from that, see here: http://floating-point-gui.de/
This is why some languages offer another data type which can do more accurate calculations, like decimals in c#, at the expense of performance.

Well, the hacky solution (without understanding the code, just based on the behavior you're describing) would be to move the "reduce one year" line to the end of the function, just before the return.

Note, though, that dealing with time is incredibly complex with like a billion of edge cases, so no matter what, test a lot.
Some reading material to appreciate the complexity:
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

For example, during character creation, I assign an outfit only for left:
IOutfit outfit = await game.Factory.Outfit.LoadOutfitFromFoldersAsync(_baseFolder, walkLeftFolder: "Walk", speakLeftFolder: "Walk", idleLeftFolder: "Walk");
and then I start the idle animation for down (because I didn't pay attention):
_character.StartAnimation(_character.Outfit[AGSOutfit.Idle].Down);
The problem is, the game gets stuck on the loading screen and the exception is only visible in output.

This should be fixed now (the game will properly crash with an error message).

Also, I saw that there's a bug with how the fade transition works in your loading screen (instead of fading in the new room, it's fading in the splash screen). Not yet sure what's going on there, it seems more complicated, I will look at it after I finish my current work.

This should also be fixed now.

Ah, right, forgot about the SDL effort, yeah, they seem to have vulkan support for mac: https://discourse.libsdl.org/t/sdl-2-0-8-released/23957

Heads up: Apple is deprecating OpenGL for macos: https://developer.apple.com/macos/whats-new/

Seems as the 2 possible options for supporting mac long term are either metal or vulcan using moltenvk (and of course supporting vulkan should give performance benefits on all platforms whereas metal is apple platforms only).