Messages

Amazing. Thank you! What are your plans for AGS 3.x.x? I guess from now on there will only be bugfixes and you are focusing on version 4? Or will version 3 continue to receive major updates?

I don't have issues, but it's interesting to see all the bugs that were found. For example, I would never have found this bug myself, but now that I know about it, I've often encountered it in games like Blackwell, because Joey always has his floating/idle animation. ^^ https://github.com/adventuregamestudio/ags/issues/2703

Supposedly, it might be possible to add new functionality that addresses todays "adventure game standards" into the engine. But how wise that would be?

Let's take "double click to exit" example.

First of all, AGS does not have a concept of "exit", at all. There are things like hotspots, characters, objects, but none of them are "exit". The thing serving as an "exit" is defined only by the commands that user types in script. So, if we want such function built-in into the engine, we will have to introduce a complete new concept. Whether that is a new type of object, or a new property of hotspot, etc, something that would let users to tell "this is the exit".

Then, having such exit to trigger when player double click on it, that's a quite a specific behavior. It may be a "standard" today, but what would happen if users will suddenly want a different one? Hold mouse button for 1 second, or make a gesture with the mouse. Should we modify the engine every time a "fashion" changes?

I get where you're coming from and I totally understand that you don't want to follow every fashion trend, but double-clicking and interrupting a walk by a player's input has been a standard for over 10 years now. Just like the popup inventory bar, it's not going anywhere because it has proven it's worth in the adventure genre. That's why I think they deserve to have at least a basic function that can then be further defined by scripting.

Hypothetically, if I had to do this in the engine, then I'd probably introduce a new BlockStyle type, something like eBlockCancellable (can't figure a better name now). This will allow to tag commands which you want to be interruptible per case more easily. Then add a game-wide setting that defines skipping controls for ALL functions that are run with eBlockCancellable.

Unfortunately, I can't help you how to customize interruption or double-clicking, but reading something so well thought out as your first thought process makes me positive that you will find a proper implementation in the future. I don't know how or if this will be implemented, but I'm glad that this has been discussed and that I'm not alone in wanting this kind of feature.

I'm going to take a closer look at Danvzare's solution now. Sounds promising. ^^

Thank you very much for responding to my post in such great detail. I really appreciate it!

The basic way which lets player to cancel a continuous action in AGS is to call such action with eNoBlock argument.

Such as:

Code: ags

function stairs_Interact(Hotspot *theHotspot, CursorMode mode) 
{
    character.Walk(248, 178, eNoBlock);
}

And then detect when the character actually arrived at the location and call ChangeRoom in a separate event, using either "stand on hotspot" event, using a Region, or Room's "crossed edge" event, whichever seems more suitable.

That is, so to say, a foundation of scripting non-blocking sequences of actions in AGS, when some things (like character actions and reaction to player input) are supposed to happen in parallel. You break the chain of actions in 2 or more parts: the start and the end (etc), and separate them in script.

If you need another event to happen after certain previous action has finished, while player retains ability to control the game, but detecting a "position" is not suitable, then this is done by testing current character or game's state in "repeatedly_execute" function. There's a related article in the manual:
https://adventuregamestudio.github.io/ags-manual/RepExec.html

I suspect that certain blocking actions may be cancelled with player input, if you test for mouse button states in "repeatedly_execute_always" and issue a command that cancels the current action, e.g. character.StopMoving(). But that may not be convenient for a number of reasons, so above method is preferrable.

The main problem is that as soon as you start

Code: ags

function stairs_Interact(Hotspot *theHotspot, CursorMode mode)

the mouse cursor  gets invisible no matter what and I want to have this exit as a hotspot. So yes, I could break the chain of actions in more parts, but that wouldn't have any effect on the mouse disappearing if I define it as a hotspot.

I suppose that it could be technically possible to support interrupting blocking Walk by a player's input. After all Say command and few similar ones (Display, etc) are intended to be interrupted by input (mouse key). So why not do the same to Walk (and others)?
The simplest answer is probably: that won't be enough to solve your problem, and may create more inconsistencies in the end.

The problem is, AGS scripting system is made in such way, that it does not allow to have two or more script functions run simultaneously, nor have player input events (mouse clicks, key presses, etc) be handled while the script function is running, or any blocking action within it. The script functions also cannot be interrupted or aborted from elsewhere.
[...]
Because of that, if we have a "cancellable" Walk, then we'll also have to introduce extra input configuration for cancelling, just like there's a configuration for skipping speech now, because each game developer will want their own control style.
And still the list of what is possible to do during a blocking Walk command will be very limited. For example, GUI won't work, so player won't be able to access menu while character is walking, and so forth.

Therefore such function support will solve one tiny issue, but won't raise general restriction, won't make things much easier.

I don't have an extremely deep understanding on the entirety of this project, but I still think that the fact that the default settings of a hotspot is to make the mouse cursor invisible is anything but intuitive. Even if you couldn't do anything until the character stops walking, it would be better than waiting for a (seemingly) little cutscene to start, where you can't do anything - as it is currently the case. It never feels good when you are prevented to interact in a adventure game (at least, when it is something like that). That's just something I've noticed in pretty much all AGS games when I play them. No other engine does it like that these days and I'm always able to interrupt this process.

I also find it odd that there is simply no function for the double-click exit, as it has become the normal standard in adventures. It makes totally sense that you can and should script advanced behavior yourself, but I think these two things are nowadays a "basic function" that should be easy to achieve and AGS should provide a simple function for them. But well... the way you explained it sounds good. I'm sure that can be implemented in a way.


Apart from that, I really have nothing to complain about, those are the only negative things I noticed.

Thanks again for your post! 

It would be nice if there was a function that already did this though.

Indeed, but thank you very much for this code! I'll take a closer look tonight and give you feedback.

But you know where I'm going with this, right? That really stands out. It somehow doesn't fit in with the rest, which is incredibly intuitive and well thought-out.

Can you give me some example codes of how you would approach this issue, eri0o? That would be nice. Then I'll play around with it a bit...

[BUT]

Hello, I've been working with AGS for a while now and I have finally decided to register. First of all, I have to say that I have already tried a few engines, but AGS is definitely the most intuitive - it's really fun to work with and very well thought-out!

The only thing I've noticed, both when playing a lot of AGS games and now when creating them, is that one thing in particular is strange and REALLY outdated:

Let's say you define a staircase as an hotspot exit so that you can eventually change the room by using it. Like this:

Code: ags

function stairs_Interact(Hotspot *theHotspot, CursorMode mode) 
{
character.Walk(248, 178, eBlock);  
character.ChangeRoom(2,7,75);  
}

Clicking on this hotspot will make the player walk to it, BUT the cursor will be disabled in this process. This prevents you from canceling the walk. I have seen that there is a template that tries to prevent this behavior, but it does not always work reliably (Tumbleweed). I don't understand why the default behavior is not that you can cancel this walk. Pretty much every adventure game does this nowadays. I think it breaks the flow of the game if you're forced to wait as if it is a cutscene. I haven't seen that anywhere else. It would be also nice, to support double click to skip the walking instantly to change the room.

To demonstrate how much better it would be, here's another video:

https://streamable.com/y3bfw4

Especially if you often have to walk long distances and have many screens, this is immediately noticeable in a negative way. That's why i wanted to ask if there is a possibility to add a function that makes it possible to cancel this walk.