Messages

However, there may be another solution: use some tool to generate a sound timeline with these levels, put this as a custom data in your game, and use that in script instead. With this no additions to the engine will be necessary.

That is essentially what eri0o suggested, using Rhubarb as the tool to identify when speech is happening in the voice clips and save this in a data file, and TotalLipSync as the script to read the data and control the animation.

Both are perhaps "overkill" in the sense that they do a lot more than is necessary for this particular case, but they should work. (One could make some fairly simple changes to TLS to make it play a looping animation instead of tracking individual frames whenever the mouth isn't closed. Or of course write the code from scratch.)

Yeah, most days. I haven't got it in 2 in forever, probably not since I last posted it here. (Though the other day I was very close: I think the word was STONE and I stupidly guessed STONY on the second.)

I play Quordle more, and recently got into Octordle. I particularly like Octordle "rescue" mode: it starts off with a few rows pre-filled with random guesses.

Looks nice!

One thing that jumps out at me is the tangent between the lowest tree branch and the left side of the nearest pit. Try to avoid edges that line up: they tend to flatten the image and even cause "optical illusions" where they seem to be part of the same object. Now it almost looks as if the pit is hanging off the tree.

Is the area under the blue tarp on the right a region accessible to players? The way it is laid out, it seems like characters would have to walk off screen to reach it. (Unless the entry is hidden behind or under the tarp, which is also not ideal.) But I think it looks too tantalizing to not be accessible.

I'm also a little unsure of the scale. If you place a character in the scene, do you feel like everything is the right size? It looks to me like maybe the tent and crate are massive compared to other objects in the scene.

Sure, there are various other things you could improve, but there are lots of AGS games with much worse graphics than this, so don't let that hold you back. This is already good enough, at least for a first game!

Hello! Sorry for the double post. Is there a way to manually change the X position of the tail?

Sorry no, not in the released version of the module. I really have to complete and release v2, which has this setting.

That's not what that snippet does. It's for the tap-once-to-walk, tap-again-to-stop movement style used in Sierra games.

But anyway, I was saying that calling StopMoving() should assure the behavior that you don't want, for those who for whatever reason prefer that, without the need for a new configuration setting:

Character.StopMoving()

Stops the character moving and sets its graphic to the standing frame of the current loop.

Can't the original behavior be accomplished by adding a Character.StopMoving() command before the redirection? If so, I don't think there is any reason to add another configuration setting.

Even if that were true, mistakes made 10 years ago are water under the bridge. Good stuff is happening now!

You sometimes complain about how you haven't (in your view) done a good job improving AGS, @Crimson Wizard, talking about mistakes you've made and so on. I think this list is a great demonstration that you, along with the other contributors, have in fact made great strides, even just in the last couple of years. Most of the things you listed as the major weaknesses of AGS back in 2021 have been addressed, or are currently being addressed, at least to some extent.

I thought if people didn't get it from the pictures and info so far, they wouldn't get it at all, but in the interest of trying to kick this activity off again...



(If people still don't get it in a couple of days, I'll just give the answer and someone else can post something.)

Edit: All right, no takers, I guess. It was The Double Life of Véronique by Krzysztof Kieslowski, starring Irène Jacob.

[The Forgotten City]

Personally the only noteworthy thing I can think of from the past three years is Return to Monkey Island.

Looking over the lists of Aggies from the last three years (not a definitive record of significant adventure games, by any means, but a good starting point), The Forgotten City and Stray seem like others worth highlighting. And I'd also throw in Pentiment.

Daedalic also seems to be abandoning adventure games, which seems to be working for them somewhat.

You may have missed some recent news on that front.

Nice! I haven't played it in twenty years, but I remember The Riddle of Master Lu very fondly... and with some frustration.

It had some really cool ideas (I've often cited the gameplay element where you can collect curios for your museum as a neat gimmick that other games could use for inspiration; it's similar in a way to modern game trophies and achievements, but more closely tied to the in-game world), and had great production values. (I'm almost tempted to suggest you try upscaling the graphics for an HD remake.)

Fixing the lack of captions will be a huge improvement. I would have thought the best way to achieve that would be through a ScummVM port (as they did for KQ7), but it looks like attempts to add the engine to ScummVM were abandoned, so for a non-engine-coder I guess a remake is the last resort. Good luck!

"Foreshortening" is a form of perspective distortion: the effect that something gets "squeezed" when looked at from an angle. For example, if we have four character direction views, let's imagine them dividing a circle so that each wedge is the range of movement angles that uses that view; first seen directly from above, and then from more and more sideways angles:



As you can see, as the circle and cross get more and more flattened by foreshortening, the front and back view angles get wider, while the side view angles get narrower.

We can represent this perspective distortion as a single number: the height/width ratio of the circle or ellipse. That is (I assume without examining the calculation closely) the value (or the inverse of the value) that @Khris sets to 1.8 in the code here.

So this should be enough to support top-down movement (just set the value to 1.0). And I don't believe isometric perspective really needs any special settings, does it, as long as one of the view angles more or less matches the direction of the isometric movement.

The FOA2 engine is still available here, with screenshots of the editor. Yeah, I always loved that aspect of it, though it's essentially bolting a simple 3D level editor projected on top of a 2D background.

Do you mean to gradually slow down the movement when walking up the y-axis, to imitate longer traversed distance when they walk further to the background? That would be great too. It would also make sense to work vice-versa and accelerate when walking down (forth) again.

No, in this context I'm just talking about the view angles, though it's related. If your room is a flat surface extending to infinity (a single walkable area), then moving at e.g. a 30-degree angle on screen (say 10 pixels up, 20 pixels right) represents quite different movement angles in 3D space depending on the distance, because movement "away" gets increasingly foreshortened, so that small y-movements represent larger and larger distances "into" the screen. Therefore, the further away the character is, the wider the angle of movement that should use an up/down angle.

Or to explain it another way: Let's say you have a room in one-point perspective, with a road coming from the bottom left going straight into the vanishing point in the distance. Now imagine a car driving down the road, moving in a straight line (the road) across the screen. Then the car will be seen from the side when it's up close, but more and more from behind as it recedes into the distance, even though it's always moving at the same angle. To get this effect in AGS, the relative size of the different viewangles (IOW the foreshortening) has to change depending on distance.

As Crimson Wizard says, it's possible that all this is unnecessarily complicated for a 2D engine. (My bigger concern is that it might not look right unless you also do foreshortening of the movement.)

Besides, how many users will actually going to use this, in a 2D point & click game?

It depends on what "this" is. I think the inability to adjust the view angles is a real problem, which people regularly complain about. Just how much flexibility and built-in logic is needed to meet user needs is more debatable.

My proposal is to make it a setting very much like Scaling: set on a walkable area basis (with a sensible default), but possible to override. I'm assuming it would be a float representing the degree of foreshortening, like in Khris's calculation.

To do the "vary by distance" part you could actually just do the same as for scaling: define a max and min value and interpolate between them, so it doesn't seem all that complicated to me, but if you just want to have a single property that will be a big improvement in itself.

along with settings to define the direction angles.

I believe I have mentioned this before, but in this case it should be a setting per walkable area, as the foreshortening can vary even within a room, depending on the angle each surface is viewed from (for example if a room is divided into floors at two different levels, or if part of the ground is angled).

(Properly speaking it should also vary by distance, but that might be getting a bit too complicated. Perhaps if it was made dynamic, it would be possible to script it.)

I believe there is a drawback with @Khris's code, in that characters walking along a straight line can end up flickering, flipping back and forth between two angles, if the dy/dx ratio varies per step (as it can do due to integer rounding). Ideally we should have access to the list of waypoints calculated by the pathfinding algorithm, so we could know the angle of the path segment as a whole.

This sounds like a good idea to me. I've always found the editing tools in the room editor unintuitive and fiddly to use.

I'm not quite sure I understand or can envision exactly how it's meant to work. The analogy with painting apps is good (after all, a lot of it is essentially a painting app), but in the ones I'm familiar with, like Photoshop, there are two panels: a tool panel and a layer panel. But for the AGS editor, the relevant tools may very depending on the layer type (drawing tools aren't relevant for objects, for example), so the UI needs to be a bit different, no?

Also, there is a natural connection between the "layer" (e.g. a walkable area or an object) and the properties of that layer, so will the properties pane and the layer panel be linked somehow?

There are multiple modules for doing queued background speech, which is going to be easier than implementing all the logic yourself:

https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-queuedspeech-v4-1-updated-1-oct-2016-bugfix-edition/
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-bgspeech-v2-2-now-with-non-blocking-wait-command!/
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-queued-background-speech-with-subtitles-v2-03/ (This one doesn't have a working dl link, and is probably very outdated anyway)

The easiest thing is going to be making an invisible character to act as the speaker, which you can position as needed.