Messages

Doesn't // usually mean that that part of the script is commeted out and the editor therefore won't run this line? Try removing // in front of your code.

Translation files use comments to also have options.

https://adventuregamestudio.github.io/ags-manual/Translations.html#additional-options

I need to clarify, how do you see that the font is not replaced? Do you refer to the GUI?

If i remember right, the GUI fonts are not replaced by translation options at all. These options affect only speech and messages done using Display.
NormalFont is for general messages, SpeechFont is for the speech only.

If you need to replace fonts on GUI, you need to run over all guis and replace the font property on all eligible controls

Spoiler

Code: ags

function ReplaceFontOnAllGUI(int old_font, int new_font)
{
    for (int i = 0; i < Game.GUICount; i++)
    {
         for (int j = 0; j < guis[i].ControlCount; j++)
         {
              GUIControl* c= guis[i].Controls[j];
              Button* btn = c.AsButton;
              if (btn != null && btn.Font == old_font)
                   btn.Font = new_font;
              // and so on
         }
    }
}

[close]

This is a known issue in the old version of template, where the script logic relied on the human-readable text.
The newest version of template should be fixed since AGS 3.6.0.

Here's the fixed code:
https://github.com/adventuregamestudio/ags-template-source/blob/169184f96a559b392f5205054d218440f1b0cd46/Sierra-style/GlobalScript.asc#L384-L401

Sorry for the silly question, but have you recompiled translation after changing this?

As for the outline font question, since it's not mentioned in the translation file instructions, is whether there's a "//#SpeechOutlineFont=" option for setting up a custom outline font for the engine to pick if run in Hebrew from the game setup?

No, but you may configure this in the Hebrew font itself (in the editor).

I noticed this recently when investigating how RTL works in AGS. This is the original behavior, and I have no explanation to this. Could be an oversight of the AGS creator, or some hidden intent which meaning was lost in time.

I would also test other things, such as ListBox and TextBox.

This could be fixed in the upcoming version 3.6.1, or a patch to 3.6.0.

So, Morgan told me that the building process excludes all pages starting with underscore "_", therefore one may create pages like "_InventoryItems" and they won't get included.

Moved Game Features list and Inventory Items to the hidden names for now:
https://github.com/adventuregamestudio/ags-manual/wiki/_GameFeatures
https://github.com/adventuregamestudio/ags-manual/wiki/_InventoryItems

If I remember correctly, AGS has a hardcoded limit to 128 characters when importing SCI format.

If you upload this font, I might look if it feasible to safely load it without breaking 128-long fonts.

The "inside the treehouse" was because I think the main point of room 1 is to show how to open a door and change to another room, a very basic and very important feature that is used in so many games.

Ah, I see.

I wonder if this will be fine if the interior of a treehouse had 2 exits, both leading to room 1, but one placing character at a door and another at a balcony. That would illustrate that you may use ChangeRoom to enter in different places even if you come from one room.

I think it's worth pointing out that in the example shown, the easiest solution is to pad out the background with a black bar on top so that it's 320x200.

How is that easiest, compared with few lines in script?
(The easiest imo would be if AGS let you configure this in the editor)

I think the door should open to a different room, it could be inside the treehouse. The many paths also seem a bit complicated, different walkable areas will be covered in the next room with the bridge.

Hmm, I have an opposite opinion, imo it's fine to have a number of demonstrated features in one room so long as they don't disperse attention. This makes the demo more "condensed". If there's 1 feature per room, rooms will feel empty.

After all, rooms may be logically divided into visible sections, where each section has a noticeable feature.

If I understand correctly, the "bridge" room is the one where the walkable area gets disabled and enabled? This seems distinct enough to allow more than 1 walkable area in a previous room.
I.e.:
- room 1 shows that you may have several "locations" defined by walkable areas.
- room 2 shows that these areas may be manipulated with, turning them on and off, allowing to walk between; and then shows that you may have other kinds of regions too (looking at your feature list on the previous page).

That is, unless you insist on each room be dedicated strictly to 1 feature / game element and everything related to it.
But imo combining few things in one room makes a more curious exploration experience. This also makes things feel more natural, closer to real game.

But does this mean that the sprite file doesn't have to be checked in? I think this hugely improves collaboration. And size of the repository.

That is true, it does not have to be checked in.

Although, you have to keep in mind that the spritefile recreation is basically a full reimport, and takes time proportional to the number of sprites and their resolution.

EDIT: Somehow I have a copy of this full-length game source in my temporary possession (i was doing some engine bugs research in it):
https://www.adventuregamestudio.co.uk/site/games/game/2330-mage-s-initiation-reign-of-the-elements/
This is a 640x400 game, with roughly 300 MB amount of sprites in png format.
I made a test on it, first exporting all sprites and remapping "source" link to these exports, and then tried full sprite file recreation.
Recreation takes about 30 seconds on my PC.

NOTE 2: this does not help with room bgs though, unless you are using ags4 where rooms are split into multiple files.

[IMPORTANT]

Hello.
Yes, since AGS 3.5.0 you may freely set room position on screen using Viewports. Screen.Viewport is a primary viewport.

For example

Code: ags

Screen.Viewport.SetPosition((Screen.Width - Room.Width) / 2, (Screen.Height - Room.Height) / 2, Room.Width, Room.Height);

Will center current room in the screen.

You probably should do this in "on_event" function, on "eEventEnterRoomBeforeFadein" event, - then this will be performed each time a next room is loaded.

IMPORTANT
AGS automatically handles coordinate conversions (such as offsets) when using functions accepting screen coordinates like Room.ProcessClick or Character.GetAtScreenXY, and so forth, so you don't have to worry about that.
But if you're using functions that accept room coordinates and want to pass screen coords there (or vice versa),  then you should take offsets into account, or use Screen.ScreenToRoomPoint and Screen.ScreenToRoomPoint functions respectively. Same is true for scrolling rooms case.

For example:

Code: ags

// will work fine, AGS converts mouse coords to room automatically
Room.ProcessClick(mouse.x, mouse.y, mouse.Mode);

Code: ags

// Imagine you want to move character to the cursor pos
Point* room_pt = Screen.ScreenToRoomPoint(mouse.x, mouse.y);
player.x = room_pt.x;
player.y = room_pt.y;

Related articles in the manual:
https://adventuregamestudio.github.io/ags-manual/Screen.html
https://adventuregamestudio.github.io/ags-manual/Viewport.html
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Event.html#on_event

Btw, I haven't been using the newer versions of AGS (been some time since my last game) - how easy is it now to collaborate? Is there still that huge sprite file that is impossible to merge? I.e. we need one dedicated person to take care of importing sprites? Or has this improved?

No, nothing has improved. Rooms storage was improved but it's in AGS 4 alpha.

The only thing that makes it slightly easier with sprites is that now there's a "recreate sprite file from sources" command in the editor, which makes sense if the source images are stored inside the project folder.

And there's still a problem of sprite numbers: if they conflict then you cannot merge game.

I don't know if translation is a thing, but we should consider making the labels as separate sprites. The map could also be implemented as GUI with labels.

You may have GUI with labels, but also a room with objects.
In case of a room you could make a mini-character going around the map, similar to Monkey Island 1 or Hero Quest. (It's theoretically possible to do on GUI, but then you will have to implement your own pathfinding)
In case of GUI, it's easier to setup textual items (with objects you'd have to create sprites, or dynamic sprites with translated text at runtime).

I forgot to post this earlier, but here's a game I've been thinking about as of a reference:
https://archive.org/details/openquest

I don't remember all details, but iirc it's either 1 or 2 rooms game with a simple sequence of actions.
It was an original candidate for a new demo game back in mid-2010ies, at least in my mind, but it's made in AGS 2.72 and uses a number of obsolete features, so would need to be upgraded anyway.
EDIT: the archived version does not include the sources unfortunately, and I cannot remember if I had them anywhere.

Another example of a good "simple demo" style, at least imho, could be this game:
https://www.adventuregamestudio.co.uk/site/games/game/1208-awakener/

This is all just for the reference, to illustrate what I had in mind when proposing to make a simple demo game.

If it were me, I would suggest creating a bare-bones, minimalist demo game: One or two rooms, with everything needed for a traditional adventure game but nothing fancy going on. Release this separately (on github or similar) as "Demo Game - Basic." Arguably, this game should be the result you (can) get if you follow the AGS tutorial to the end.

I think Snarky has reasonable arguments, and initially I thought this is what would be done first, before going into more complex demos.

Overall I feel like I myself got somehow swindled from one idea to another. This happens way too often to me lately, I cannot stay focused on initial thought. But probably that's because I am not actually dedicated to the game design process, and only comment on what others are doing.

The kind of project discussed here may indeed be useful as a big feature demonstration, but I am not certain if it will work for a basic tutorial purpose.

Perhaps, I may propose to imagine you are the absolute beginner to AGS. Try to look at this with their eyes, and ask what do you expect from a "demo game", if your intent is to quickly start your own.

But I don't think I will be participating in this conversation, as I simply cannot stay focused on the problem well enough to provide reasonable contribution.

I might have made a mistake though. There's only 1 item under "game features" now, and because we use this version of the manual to make a AGS distributable, it may look confusing to readers.

I need to find a way to "hide" these pages temporarily, until there's more related content.

There's a way to create separate "branches" in the manual, and put pages there, but these branches wont be accessible and editable from the Wiki frontpage, one would have to use git for that probably, and that's more complicated.

Alternatively, of course, we might quickly make several pages with at least some minimal information.

EDIT: Another alternative is if I make a private clone of the manual, and gather these new pages there. Then later, when there's enough material, I'd copy these texts to the official place.

Does anybody have a good idea on how to solve this? Perhaps if there were a temporary place to gather these pages before there's enough content to look good in the manual?

Myself I don't have much spare time now to write these pages.

I don't think so. I believe someone would have to make a Mac/Linux version of the plugin, and even then you might have to rebuild the game to link it properly with the new plugin.

Flashlight plugin have been rewritten many years ago by JJS, as a part of the initial engine ports. It is present in our repository: https://github.com/adventuregamestudio/ags/tree/master/Plugins
It's kept 100% script compatible, because it's used to run old games. It may not be 100% precise in behavior though, and I've never tested it myself.

The plugin may either be built standalone (*.dylib), or integrated with the engine if particular compilation flag is used (BUILTIN_PLUGINS).

It's possible to find out whether plugin is used at all at runtime, if you run the engine with "--log-stdout=main:all", it will print its attempt to hook up plugins or use built-in functions.

Yes, replace the "room" with "location" in the rule, and "location" may consist of number of rooms, if changing rooms is necessary to showcase something.

What does everyone think? (Apologies for the gigantic image -- couldn't figure out how to make tables work in the forum post).

You could upload a spreadsheet to any file hosting, like google drive, and post a link instead.

In regards to the table, I'm afraid this kind of configuration will result in lots of empty cells, and a waste of visual space. The "group" may be made as a single column, where you print a group's name (or a short tag), perhaps even with a colored background corresponding to a group.
It should be easy to sort the items, keeping them grouped by "group" value.

[each room is self-sufficient]

The real question is: how much adventure game is needed for a demo game? If you want to get a game with good story and great world building, there are tons of them in the database. The demo game should IMHO showcase the most common use cases and how to implement them.

Yes, I guess you're right.

So, the rule should then be that each room is self-sufficient, not requiring visiting other rooms for completing.