Messages

For example, if user requested a teleport to "chapter 10", this system would apply:
- all changes for chapter 1
- all changes for chapter 2
- all changes for chapter 3
- etc
until chapter 10 is reached.

This made it much easier to update even with very high chapter numbers.

That's very similar to what @Wyz described in the thread I linked. In his case he also called these functions during normal gameplay at the start of the corresponding chapter, to ensure consistency. (Of course, on the other hand it is not difficult to imagine that this could easily be a source of gameplay bugs and inconsistencies, especially if there are changes to the game logic but the chapter functions aren't updated accordingly.)

It's hard to decide what to recommend, because I think it would be better to do the whole thing quite differently. For example, it doesn't make sense to always do:

Code: ags

  gGuiX.Visible = true;
  SaySpecial(cChar, "Blah");
  gGuiX.Visible = false;

Showing and hiding the display GUI should be part of the SaySpecial function.

However, the minimal change is to just add a line right after your call to SaySpecial7 that sets the label to the text it had.

If I understand your question correctly, it's about playtesting your game, and how to skip to particular parts of the game?

As heltenjon says, the Debug functions can be useful. It is also quite common to write some helper functions for testing which, for example, set all the game variables to a particular state, or jump to a given chapter/act (and then some tester/debug GUIs to let you set that while playing). See the suggestions here. If that's what you've been trying to do when you say "it's easy to make mistakes"... well, yeah, but then you just have to fix them.

Writing the game in a structured way (putting all the state variables together, for example) can go some ways towards keeping things organized and easy to get an overview of, and maybe help avoid mistakes, but if you haven't been planning it out in advance it can be a lot of work to fix; it might be more of a learning experience for your next project.

I don't understand what this means.

You wrote:

The problem is when it opens gui23 up, it removes the text from gui 16.

So I am wondering if I can't have the Mamba character in two different gui's at the same time.

That is not the cause of the problem. The reason the text disappears is that the function you are calling to display it, SaySpecial7, has a command to remove it (slabel7.SetText("")) once the player clicks past the blocking SayAt call.

SaySpecial7 ends with slabel7.SetText(""); so that's why the text disappears.

Well, then my work here is done. 

Khris made a small mistake in his code. It should be:

Code: ags

bool walking_right; // initially false

function room_RepExec()
{
  if (!cGallo.Moving) {
    if (!walking_right) cGallo.Walk(1000, 1020); 
    else cGallo.Walk(400, 1020); 
    walking_right = !walking_right;
  }
}

I tried your code anyway just to find out, but it doesnt compile (Error (line 22): undefined symbol 'walking_right'), and I dont know the proper way to phrase it.

Are you sure you included the first line of code in the example?

I thought this kind of think would be the easiest thing to do...

It's not hard to do. The problem is that it's easy to get it slightly wrong. So it's useful to understand why the different proposals break.

With FortressCaulfield's version, first of all the recommendation to put it in global repeatedly_execute_always() is wrong. You cannot call blocking functions from repeatedly_execute_always(). Since it is anyway only supposed to run within one room, you should (as you have done) put it in room_RepExec(), which is the room-equivalent of repeatedly_execute(), and then you don't need to check that you're in the right room either.

Second, I would first wonder whether there is a walkable area where cGallo is standing. If not, the character won't be able to walk using this command, and this may explain why it's just moving in place there.

Third, since it doesn't use non-blocking walk, I would expect the game to freeze while it is running (which is all the time in the room), so the player won't be able to do anything.

Finally, if you do turn on the non-blocking parameter in this version, it will break because it doesn't check whether the character is already moving before commanding it to walk (it checks the coordinate, but that won't change immediately when the walk starts). Therefore, it will keep commanding the character to walk every game cycle, and this will reset the walk (the internal counter that tells it when to actually start moving) so that it never actually moves.

AndreasBlack's code looks correct (apart from horrendously wrong indentation and formatting of the {} braces), but it will introduce a pause of some seconds between each walk. If you want the next movement to begin as soon as the last one is complete, you should replace all the IsTimerExpired() checks with !cGallo.Moving.

As for the idea that you're unable to set global variables, that's certainly not the case: the likely explanation is that some code that you assume is running never actually runs.

@gendiskan, taking it to email is not ideal because this isn't really a one-to-one conversation. (It should be possible to "watch" the thread so you get an email alert whenever there is a post, but unfortunately this feature doesn't seem to work correctly.)

I'm not an engine dev, but I wouldn't mind taking a crack at a module to do keyboard navigation instead of moving the mouse for GUIs and other interactive elements (hotspots, objects, characters), and getting that into the default templates.

Thanks for the report. I will look into it.

(Also, the game looks really great. I am honestly a bit apprehensive that you're relying on my code for the speech display.)

If you use the Speech Center plugin, you can specify other speech functions to export in the voice acting script.

The game dump is great to have so you can search it for anything.  What room an object is in, where global inits are being used etc.

The built-in search in the IDE should support that (though it has sometimes been a bit glitchy). It should be unnecessary to export the game to a single text file just to run a search (which you then have to map back to the editable files).

How do I mark this topic as solved?

If you edit the first post in the thread, you can change the subject. It's customary to add "[SOLVED]" to mark it solved.

Rendering shadows using some kind of mask is possible.

In order to do this in general you need to have a 3D model of the objects casting the shadows, of the surfaces the shadows are cast on, and of the position of the light source. You may restrict it in various ways (and use tricks and approximations) to require less data, but a freely moving light source is probably always going to be difficult to fake in 2D.

If the geometry is simple enough, you could potentially build a 3D model and calculate the shadow projections (via raycasting or some other method). Shadows of irregular objects are much more difficult, but if you have something like a character view from multiple angles, it could be possible to take the closest matching view depending on the angle, and project that outline onto the surface. (See this earlier discussion.)

Depending on the restrictions and simplifications that are acceptable, other solutions are probably possible. I think a small handful of AGS games have actually done dynamic shadows of one kind or another.

Well, in the simplest case, simply by defining the walkable areas in terms of connected polygons. They will then be rasterized as a step in the pathfinding (drawing onto a Dynamic sprite and using MaskPathfinder), but who cares?

Alternatively, users can write a pathfinding algorithm for polygon-based regions, and use the new WalkPath() method to apply it. This would enable e.g. overlapping walkable areas.

It comes down to a question of what problem we are actually trying to solve. (It's not clear what @Walmaker's problem really is, nor whether it actually has anything to do with "vector based walkboxes.")

We need a pathfinder that works with a list of geometric shapes instead.

Do we, though? Why?

Though by exposing the pathfinding API as you've just been working on, @Crimson Wizard, it becomes possible to implement vector-based walkable areas (and editing) within AGS. (That is to say, it will still be a pixel mask in the end, but it can be dynamically generated from a set of polygons.)

Thanks @gendiskan, I think that list makes it a lot easier to see what is and is not possible in AGS. FYI, Crimson Wizard is one of the main engine devs.

You should be aware that compared to Ren'Py, AGS is a more "primitive" engine in a couple of ways. First, because it is older. And second, because it is more low-level in several areas, not providing ready-made solutions but only commands in its programming language that allow game developers to build their own solutions. That means many things often end up being hardcoded in each game, and can make it more difficult to offer built-in engine-wide accessibility features.

Strictly from the technical point of view (not considering potential design or configuration issues),

* Adjustable text size, color, and opacity, including fonts for players with dyslexia.
[...]
* Sound adjustments (mono or stereo) and volume settings for effects, music, and voices, if any.

These should be relatively straightforward to do.

In terms of how this would actually work, Crimson Wizard, are you thinking that players would configure it in winsetup.exe (or by editing the cfg file), and it would adjust the default color and volume values set in the editor?

Because as we know, AGS games don't come with any default in-game configuration UI.

Also, this would only work if the game developer never uses the script API to overrule the starting values set in the editor, because then they become hardcoded. My intuition is that most games do set these values in script at some point, and so this solution would have quite limited effectiveness, but I might be wrong about that.

It would be possible to create a module (or even an engine API) that would define text styles that could be used throughout the game, which could then be configured/overruled by an external style sheet (or configured in an in-game menu), but you would need to convince game makers to actually use it (or deprecate all the commands to hardcode text appearance).

(BTW, the SpeechBubble 2.0 module that I've been working on off-and-on, still very much incomplete, has this notion of "styles" to configure text appearance, and it would be quite possible to read them from a style sheet. I'm also building an in-game UI to configure it: my experience is that this is a massive amount of work, but a lot of it has to do with configuring the appearance of the bubble, rather than the text itself.)

For audio type volume, the ideal is probably that all games have in-game volume controls for the different audio types, but since game devs have to build the GUIs, it's hard to guarantee. It could be part of the standard templates, at least.

* Analog control, allowing players to navigate menus and interactive elements with keys or buttons.

I think this is theoretically possible, but will require implementing whole new control system within the engine from scratch, possibly with external input configuration, because keys or control buttons may be also used for certain purposes within the game (script).

Interesting. It doesn't merely require new keyboard handling, but a notion of UI focus that AGS doesn't currently have. (To give an example: currently, if there are multiple text fields on-screen at the same time and you type something, it fills in every field simultaneously.)

In the near-term, it might be possible to create a module to provide keyboard control to GUIs, and add it to the default templates.

* Screen reader compatibility to verbalize menus, texts, and subtitles.

I have a guess that this is easier to do using an external tool, which works over the game window with final game image.
In AGS this may be complicated to do, because it does not have distinct "text element", and texts are baked onto other graphical elements. Some game objects have "text" property, but not all, so they won't be able to tell what is drawn on them. And there's also a "raw drawing" feature that lets paint text on sprites.

Yeah, and I'd add to the list of challenges that the way text is done in AGS, you can't always tell whether text has changed or not. For example, there could be a label with text that is set again every game cycle whether or not it is empty, the same as before, or has new content. (A mouseover tooltip is the obvious example, but depending on how things are scripted this could apply to a lot of UI text, e.g. status messages.) And again you run into the problem that AGS doesn't have a notion of UI focus, or even of a UI hierarchy.

On the other hand, I would expect it to be fairly easy to provide screen reader support for  character speech or dialog, since that does have this notion of "focus" (one character speaks at a time, except for background speech) and the content of each line is clearly defined.

However, if there was an API for screen reader integration built into AGS, it might make it easier for game makers to offer screen reader support in their games. (I'm not sure exactly what such integration requires. I had a hard time finding documentation.)

The easiest way is to put a button in the middle of the GUI and set the item sprite as the button graphic.

@Akril15, since you're having similar problems with both this module, TotalLipSync and the built-in lipsync, it seems clear that there is some common underlying issue. That appears to be that none of them can find or open the sync files. Something must be going wrong with how you are adding them to the game project.

I think you should start by debugging that part: just try to open the file yourself (on game start, for example, using some test code like:

Code: ags

  String filepath = "..."; // Put the path you want to try here
  File* file = File.Open(filepath, eFileRead);
  if(file == null)
    Display("Could not open %s", filepath);
  else
  {
    Display("Opened %s OK!", filepath);
    file.Close();
  }

(Or you can use System.Log() if you prefer.)

Once you are able to figure out what filepath you need for a particular folder location so that this is working, it should be easy to get it to work with the modules/built-int lipsync as well. Check out the File.Open() and Package custom data folder(s) documentation for guidance. (Crimson Wizard just posted an improved version of the explanation on Discord, but I don't know when it will actually appear in the online manual.)

Well, is the mouse cursor outside of the bounds as it opens? I don't know what your GUI design looks like, but if the slider doesn't appear right where the mouse cursor is, then it might of course immediately trigger the closing condition. You should work out the region you want it to remain open within and adjust the CLOSING_DISTANCE value (or values) accordingly.

Some good stuff in the Brok documentation! I didn't realize sending text to the clipboard could be a way to interact with screen readers.

It occurs to me that it wouldn't be hard to make a module with custom functions to log all dialog and descriptions, which could then be replayed. I've seen similar things in other engines. (This would be significantly simpler than the ability to actually rewind the game, as Ren'Py allows.)

Perhaps there could be a page on the Wiki or in the manual about ways to make your game more accessible.