Messages

And since I'm at that, I might say that this habit of brushing AGS problems off, preferring to keep the "workarounds" tactic, is probably the reason why there are so many issues in its core functionality still after many years. People just get used to "workarounds" and don't bring problems up. Then every newcomer gets into a trouble.

The point I was making is that I don't think most users experience this as a serious problem.

I'm not sure whether the user on Discord was unlucky in what graphic software they tried to use, or just couldn't figure it out, but if this was really a problem "every newcomer" struggles with, we would hear about it way more often. (Compare all the questions about linking events and event handlers.)

And of course these nuances are never documented, so I cannot even find a reference when someone asks about a problem.

Isn't it all documented here? It doesn't explain how to actually create files in the required format, but since that will vary from image editor to image editor, that wouldn't be possible to document in general.

I don't know how useful having a mask drawing tools inside editor would be, besides being able to quickly setup a scene draft.

I would expect most people do use the AGS mask editor (supporting that as a higher priority), and that the mask import feature is more of an "advanced option."

BTW: It's been a while since I used it, but my recollection is that AGS doesn't export masks in the same format it requires them to be when imported. (You can only export one mask at a time or something?) If that's so, it should be an easy fix that could also help with creating files in importable states (you could just export the masks to a file, paste the drawing you've made into it, and resave).

I've been thinking about similar thing, have a "import mask" palette, optionally enabled, which has default color setup for masks. I don't think the regular game palette may be used for this, because it is divided between "game" and "room" colors, which may make using it for masks palette inconvenient.

If you're absolutely convinced this is a high priority, I would suggest an import screen where you could see the mask image and a list of the mask channels. Then with an eye-dropper tool you could assign each color to a channel. A default mapping of colors to channels (if they match) would then be a nice-to-have accelerator feature.

But realize that as soon as you move away from requiring palette-indexed images, you're going to have users who try to use anti-aliased, compressed or otherwise not 100% RGB-accurate masks.

I think you're somewhat overstating how much of a problem this is. Maybe not all graphic software can export to 8-bit, but most can (including Photoshop), and in my experience you can get them to assign to the first 16 (or however many) palette slots fairly easily.

If another export shuffles the palette order, there are two workarounds: you edit the file before you import it into AGS, or you switch the regions around in AGS (using the paint bucket to fill each region with the right number). It's a little bit of a hassle, but not a catastrophe. And it's really a problem with the graphic software, not AGS.

I believe most people who use this workflow figure out how to make it work reliably and efficiently.

That's not to say that it wouldn't be helpful to have a dialog to e.g. map palette indices to region numbers, since that could simplify the workflow a little, especially for newbies.

Nice work! As others have said, it's already better than a lot of walkcycles used in AGS games, and I'm sure you'll only improve with more practice.

One thing I notice is that the head bounce is one pixel higher for one leg than for the other. I see this in a lot of walkcycles, and to me it always makes it look like the character is limping. The jerky back motion of the arm (fixed in Creamy's version) increases this impression.

If you click the # button at the top of the thread (to the left of "Go Down"), it will copy the thread number to the clipboard. (Edit: Actually, it copies the whole thread URL, but using the thread ID format.)

(The usability of this feature sucks. Hovering over the button gives no indication of what it does, and clicking it doesn't give you any feedback that anything has been done, but at least it works.)

As it is, the character keeps moving forward for the entire cycle, resulting an odd gliding look.

Is there a way to make it so the forward movement only occurs for the relevant frames and that they remain locked in position for the rest of the walk cycle?

You may already have done this, but the first thing you need to do is to turn the "Movement linked to animation" option on in your game settings. Otherwise the character will move some pixels each game update even when the animation doesn't update, which will cause it to glide. Once you've done that, you can use Khris's solution to vary the forward speed over the animation loop and achieve a limping effect.

Also, if you look at what is actually needed in order to progress through an act of say, Monkey Island, it's probably a lot less than it feels like for the player. The player will spend time exploring, examining things, talking to npcs and so on. The puzzle dependency chart is not likely to show how the player's game will be like, as most players will need a bit of trial and error before reaching every goal.

It seems to me that the PDCs both for TSOMI and (to a somewhat lesser extent) MI2 Act II are quite bushy and complex.

Nice!

My impression just from the graph structure is that it seems rather linear, in the sense that doing one action mostly opens up just one new action, and then that action opens up another action, and so on, and so a player will have to follow it very step-by-step. There are a few parallel paths, but each path is pretty linear.

This is partly a subjective question of taste, and a lot depends on how well it's executed, but personally I often find games like that unsatisfying, because it's like each move then kind of forces the next move. Or sometimes every time you seem about to achieve your goal, some new complication pops up, leading to increasing frustration.

I tend to like it better when more of the steps have more than one precondition (it looks like there are only two non-trivial examples of that in your design: to create the super plunger and hair of the dog), or open up more than one way forward. Basically, more branching in the graph. Or as Noah Falstein and/or Ron Gilbert put it: "Make it bushy!"

Here is a PDC for The Dig for comparison. It does have some linear sections, but usually it's only three or four steps between each branching.

I haven't the chance to try it out now, but while it's still in testing, maybe an idea to generalize it further:

How about supporting negative values to allow users to switch the up/down directions (including diagonals)? (Typically for things like walking down hills.) I think that would greatly simplify this usecase.

But besides the autocomplete, the practial problems with macros are also that:
a) they are not type safe,
b) they increase the size of the code, because macro contents are essentially copied into each place where you call them from. Real templates also increase the size of the code, but only for each combination of type arguments. If you have a template function of <int>, you will have 1 <int> variant of that function generated and called from anywhere. With macro all the code is copied to the calling location each time.
c) they are not stepped into during debugging, also for the same reason as above. Which means that they are going to be more difficult to debug. Also, any errors would report not the lines in macro, but lines where they are called from.

While it's possible to write very complex macros where this would be a problem, I think in practice most macros would be relatively simple and the drawbacks insignificant. I could definitely see myself using macros to ensure that modules are compatible with AGS 3.4, 3.6 and 4.0, for example, expanding to slightly different code depending on the version number/API-support. (This is probably already possible in many cases, but I don't believe the current preprocessor macros allow you to e.g. turn SETCOORDS(x,y) into Coord.X = x; Coord.Y = y;, for example.)

This may be resolved by implementing a script module database, or perhaps a in-Editor menu for looking up for script modules in a list of repositories.

This would be really helpful! I spend a lot of time searching the forums for relevant modules that are not outdated.

I have a bit of a hard time imagining how this would work in practice. What information would this database have to make it easier to find relevant modules, and how would it be populated and maintained?

I guess it would be possible to search e.g. all projects tagged ags on GitHub, but I'm not convinced it would add a great deal of value.

3. New Dialog editor/dialog scripts. The way modern dialogs are designed is very different nowadays, it's more of a tree structure than a bunch of questions right off the bat. It's also frustrating to not be able to reorder the dialog options.

Are you familiar with the Dialog Designer tool and editor plugin?

Templates would also be very useful, even if limited to script-only. The big benefit I could otherwise see of generics over function overloading is for functions that act on collections (arrays), but templates can solve that.

@Crimson Wizard, I think you mentioned at some point that it might be possible to pretty much just take the component of the C or C++ build process that handles macros and drop it into AGS, since it's more or less its own separate language. Could that also enable templates?

I think all of this is mostly relevant for people writing "utility code" such as modules. So the strategic goal is something like "create a better ecosystem of libraries/modules to address various game needs, by making it easier to write flexible, general-purpose code."

CW's list is pretty much the same things I would prioritize, with special focus on the save game issue.

- More pre-coded maths functions: distance, abs, clamp, etc.

It also occurs to me that if we had function overloading (or generics), offering these would become a lot easier and more elegant, since you wouldn't need separate absInt()/absFloat() etc. functions. I don't suppose that's supported in the AGS 4 compiler already?

(Talking about scripting language improvements, a small thing that's a real pain in the ass when writing modules is that you can't use properties in the module where they're declared, but have to use the getter/setter methods instead—and that IIRC the compiler doesn't throw an error, but it fails at run-time. But this is probably too low-level for a roadmap.)

To come at it from a slightly different angle, I think it could also be useful to think about "strategic goals" for further AGS development.

For example, a goal might be "better support for high-resolution games" (which would probably imply things like performance improvements, better upscaling/downscaling of the game window, sub-pixel positioning and smooth scaling of sprites/textures).

Or "better support for distributed game development" (allowing multiple people to work on a project without conflicts). Or "better support for command-line tools and scripts." Or "better platform support" or "better web support" (e.g. letting the web port write saves to real files, or load resources on-demand). Or for that matter "better parser" if we think the way forward is text-input games, or "better ability to integrate with AI services," in case someone feels a need to have ChatGPT-powered NPCs.

It can be a way to let us think about what sort of engine we want AGS to become.

[it's easy to make a Mac version]

I think that's a somewhat negative way of putting it, Crimson Wizard.

The key thing to get across is that it's easy to make a Mac version of your game, even if it takes a couple of manual steps: you just need a generic, "blank" app package (with a pre-built version of the engine), and then drop the files created when you build the game into that.

For 90% of people it makes sense to use a pre-built app package rather than the more complicated process of building the engine for Mac, so that should be presented as option 1. (I've earlier argued that there should be official Mac engine builds hosted on github, which I still think is a good idea. In fact, why not also distribute them with the IDE? Then the only thing missing from automatically building for Mac is dropping the files into a copy of the archive/package on build.)

I was wondering if this is the fault of my dialogue GUI specifically, or if this is an issue AGS has running animations while a GUI is open, so I tested this by making a new and very small GUI consisting of just one button to trigger the animation (the lightest GUI possible). The animation stuttered. Therefor, this is an inherent issue AGS has running animations while any GUI is open.

May we see this GUI? It seems likely that you're doing something non-optimal.

Yeah, depending on how you have it set up, it may be fairly simple to automate (ideally as a batch operation over all files, but at least to do the necessary edit as a single action on each file). Might be possible to do as a macro in Photoshop with a bit of ingenuity, if you're not prepared to script it in a command-line tool like imagemagick.

If you have to check in each case how many rows of pixels you can overlap before it starts interfering with the animation, things get a lot more complicated.

(I thought I should also mention that this approach will not be exactly identical to the "correct" approach of pre-merging the sprites, since along the edge the pixels that are part of the overlap will have more weight than neighboring pixels that aren't part of the overlap when rendering the final "smooth-scaled" pixel value, since they are drawn twice. For example, a rendered pixel that should properly be an even 50-50 blend of two neighboring sprite pixels may end up as a 75-25 blend instead. I think in most cases this will not be noticeable, though.)

[Edit:]

It occurs to me that the way I would probably do this compositing of separate character parts would be to make both the sprites the full character size, just with transparent portions. That way the positioning and scaling would be trivial. Is that what you've done as well, @Dave Gilbert?

Because in that case, I think the seams may be an unavoidable consequence of smooth scaling. A pixel that belongs 50% to the head sprite and 50% to the body sprite will end up 25% transparent, because each part is rendered at 50% opacity.

The only way around it I can think of is to merge the two sprites together on a full-scale dynamic sprite and then scale that—but this might end up causing the game to stutter.

Edit: Another possible solution, if there is a static overlap between the two parts of the character (i.e. a row of pixels along the seam that doesn't animate), would be to include this overlap in both sprites. While this will not completely eliminate the seam in all situations, it will make it a lot less noticeable.*

Unfortunately, if you do this you might end up with a little "bump" along the edge of the character, as the anti-aliased edge become less transparent than it is supposed to be just there. If this is noticeable in practice, a refinement would be to exclude the edge pixel from the overlap.

Similarly, the approach only works if the character is fully opaque. For a semi-transparent character (like a ghost or hologram), you will be drawing the overlap twice and therefore end up with the opposite problem: a line where the opacity is too high.

*I believe that in general, with an overlap of n pixels and a scaling factor of p, the worst case is ((1-np)/2)^2. With no overlap, this gives a 25% transparent seam in the worst case at 50% scaling (or, in this case, any scaling). With 1 pixel overlap, it gives just a 6.25% transparent seam at the same scaling. (And if np>= 1, there will be no seam at all; so that with a 2-pixel overlap you are guaranteed no seam at 50% scaling or above.)

Exponentially more, recently!  I don't want to promise any sort of a release date, but we're so much closer than before.

That's excellent news!

I'm aware of the occasional YouTube ID issue, but unless people bring issues directly to my attention it's pretty much impossible for me to fix them.  I don't see any post from Wesley in this forum for instance?

In this case it was discussed on Discord. Thanks for the fix!

The 'community' FAQ will be revised in the new version of the site

Is there actually any progress on that, BTW? It's been a couple of years without any news, I believe.

I think there are a couple of things that might be high priority enough that they would be worth addressing before the site update, unless it is very close to launch. For example the problem with submitting to the Games Database, where it just kicks you to a blank page if there's something it doesn't like in the way you filled in the form (in particular if you put a YouTube link in the YouTube video field).

I suspect this is a hurdle that keeps a lot of games out of the db, since it seems to trip up nearly everyone who's doing it for the first time—recently @Wesley when trying to submit a demo to be eligible for the AGS Awards before the new year's deadline.