Messages

Another update:
https://cirrus-ci.com/task/4777755552776192

This is how it looks like, overall:

Please tell which version of AGS are you using exactly, and which steps do you do to build the game, which folder do you look in?

Characters already have a "Idle View" mechanic that practically does that, you could use that directly, or use a "dummy" idle view to trigger your code. Set a "idle view" and configure "idle delay" for a character. Then in "repeatedly_execute" test whether idle view had started, and do your thing.

Code: ags

function repeatedly_execute()
{
    if (player.View == player.IdleView) {
         // your actions
    }
}

Relevant articles in the manual:

https://adventuregamestudio.github.io/ags-manual/Character.html#characteridleview
https://adventuregamestudio.github.io/ags-manual/Character.html#charactersetidleview

All Room Objects are stored in an array "object[]". If your "piece" objects have sequential order, then you could do "object[i + FIRST]", where FIRST is the index of a first "puzzle" object.

If they are not sequential, and it's too difficult to make them such for any reason, then you could create your own array and assign objects to it:

Code: ags

Object* pieces[HOW_MANY];
pieces[0] = piece0;
pieces[1] = piece1;
etc

and then work with "pieces" array.

Please, be careful with ChatGPT, it was already proven that ChatGPT does not guarantee a valid AGS script (don't know about other languages).


LoseInventory and AddInventory are functions. The syntax of calling a function is "FunctionName(arguments)".
Therefore the code should be:

Code: ags

function oObject0_UseInv()
{
    if (player.ActiveInventory == iEmptyBottle) {
       player.LoseInventory(iEmptyBottle);
       player.AddInventory(iBlueBottle);
    }
}

Related topics in the manual (they contain examples!):
https://adventuregamestudio.github.io/ags-manual/Character.html#characteraddinventory
https://adventuregamestudio.github.io/ags-manual/Character.html#characterloseinventory

But that's just my two cents on the matter. There are definitely good reasons to have a demo game that's meant to be a showcase of what you can do with the engine, rather than a tutorial game which tells you how you can do things with the engine. It all depends on whether we want to inspire newcomers or help them get acquainted.

There may be two demo games, one made as a tutorial, and another for showcasing more advanced stuff mended together.

The tutorial game could have a "chapter" menu which teleports you to the wanted room, with description of what that room does.

[agsunpak]

If the other game used different font that contains proper letters with umlauts, that could explain the difference in result.

Then again, the issue may be in a codepage you are saving your TRS, maybe it's not matching the game's font.

I still have the feeling that the mapping of the fonts has been changed because in the .trs file, the umlauts are written as special characters, for example, "ä" is represented as "$" but in the game it is displayed as an umlaut. I'm just wondering how this can be achieved with just a .trs file without making any changes to the game files.

All of this depends on:
- Which letters does the font have and which indexes they use.
- Which letters do you use in TRS and which encoding (utf, ANSI, other) do you save in. The encoding  of your TRS defines the values that letters are going to be represented with. Some letters always save in the value range of 0-127 (this refers to punctuation symbols, and basic latin letters), others will depend on encoding.

For example, if in font they have "ä" in standard place of "$", then you may get to display "ä" simply by putting "$" in the TRS.
For another example, if their font corresponds to ANSI-1252, then your TRS should be saved exactly in ANSI-1252 in order to match all letters.
If they don't have "ä" at all in their game's font, then there's no other way than providing another font.

Here's the archive containing our own command line tools existing so far:
https://www.dropbox.com/s/6wfl3foo3jb9iyu/agstools-360.zip?dl=0
(most of them are only useful when you're compiling the game from sources though)
inside there's a program called agsunpak, it unpacks the AGS game package. It's used from command line like "agsunpak.exe gamefile outputdir". For example: "agsunpak.exe game.exe mydir" or "agsunpak.exe game.ags mydir" (if the game data is in "*.ags" file).

You could use it to get the fonts out of the game and then analyze them using a WFN editor.
One editor may be found here: https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/editor-plugin-wfn-fonteditor/
There has been another older one by Radiant, somewhat easier to use, but I don't have a download link for it.

No problem, it was indeed a lot of text. No, the other person used a different game from the same publisher, but both games were released in the same year, so there shouldn't be too much difference, right?

If the other game used different font that contains proper letters with umlauts, that could explain the difference in result.

Then again, the issue may be in a codepage you are saving your TRS, maybe it's not matching the game's font.

Yes, I understand that the question is difficult to answer. But, I cannot distribute the game data as it is a commercial game, and I don't want to cause any harm.

You could perhaps give a link or at least name the game's title. But I guess it's not important anymore if you found the working solution.

I have experimented again and managed to make the game use the other font and therefore display the special characters. However, now the font appears very distorted. Could this have something to do with the font size? How can I change it to make it look better?

This is an annoying gap in translation system, but I don't think you can set the font size with TRS.
This may be a proper feature request for the future engine versions.
I think you could maybe try converting ttf->wfn and choose the destination size when you convert (if converter allows this).
Other than that, look for other fonts, or even draw some yourself. There are WFN font editors around, for example this one: https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/editor-plugin-wfn-fonteditor/

I tried that, and the game starts without any issues. However, when I connect the .trs with the acwin.exe, toget the .tra file, I get an error message, and the game no longer starts with acwin.

There's some misunderstanding. You don't use acwin.exe to get tra file from trs, acwin.exe only runs the game.
You need to use the translation compiler to make tra from trs.

I tried the program you suggested, is there any manual or instruction available for it?

You run it from command line. You can run "trac.exe --help" to see the list of options.
The common use is "trac.exe lang.trs lang.tra" -- this will take lang.trs file and create lang.tra.

Although the question of how the other person managed to achieve it with just a .trs file still bothers me a bit.

I might have missed this in your other replies, did that other person translate same game or another game? It's difficult to answer such question without knowing details, or better having the game with translation for analysis.

I have tried that. I converted a .ttf file (which includes special characters) into a .wfn file, located the entries for .wfn in the game.exe, renamed the new .wfn files accordingly, and copied them into the game folder. The game loads, but the font in the game doesn't change significantly, and the special characters still aren't displayed.

A side note, but if I recall correctly, you dont have to convert ttf->wfn, as AGS would try to find ttf first.

Could you please clarify what does "the font in the game doesn't change significantly" means? To make it certain, can you confirm that the new font is being used at all?

Regarding the issue, I don't know if you are aware of this, so must mention: in AGS all games made before 3.6.0 were made in ASCII/ANSI text format. This means that in order to display "extended" characters both the translation text and the font should comply to the same ANSI codepage. It does not really matter which one, what matters is that the ANSI codepage you are saving TRS with must match with the codepage the font is complying to. For this reason people were making "AGS compatible" fonts, if they needed to feature e.g. extended Latin with umlaut, Cyrillic alphabet, and so on. These fonts have to have the letters in particular slots, in accordance to the chosen codepage. For example, see how the letter table looks like in this wikipedia article: https://en.wikipedia.org/wiki/Windows-1252
The problem with this approach also is that when you save TRS in ANSI, the result will depend on your default system codepage. (This setting is also called "Language for non-Unicode applications" in Windows) So this is something to pay attention to.

This is irrelevant if you are going the alternate route, using a Unicode mode.

I'm not entirely sure if I understand correctly, but are you referring about the "Translation" option under the "Explore Project" tab?
If so, please note that I haven't loaded the game in AGS because it is encrypted.

No, I'm referring to the text TRS file, and compiling it with the translation compiler. You should not be needed to launch an Editor for this.

If I follow the Manual, such as adding "//#encoding=UTF-8" at the top of the .trs file, the Translation is completely ignored.
The .trs file is in UTF-8 encoded, but the .tra file is currently in ANSI, when I convert the .tra file to UTF-8, the Translation is not recognized.

Right, I forgot to mention that old translation compilers dont support this. You have to use either one that already supports 3.6.0 feature (I dont know if there's one already), or use our own:
https://www.dropbox.com/s/42widlilgfa2aoq/trac%20--%20ags%20translation%20compiler.zip?dl=0
this tool should be run from command line though.

Note that the Encoding option wont work with the old game or engine exe anyway. (unless it's a 3.6.0 game)

As for the last part about "placing 3.6.0 engine (with SDL2 dll) in the game dir," am I understanding correctly that I should copy the entire AGS into the game directory? Would that work even if the data is encrypted?

No, not the entire AGS, but the engine runtime, called "acwin.exe" for Windows. The standalone engine exe can load games just fine, if it finds them in current location.

I might say that "Inventory items represent something that a character may acquire and use: a physical object, an idea, a useable skill, and so forth, depending on game mechanics that you want to have".

Another thing, in my opinion it may be better to say that characters own copies (or "instances") of items, this is why character may have multiple instances of same item, and multiple characters may have same item too.

"called or pointed to from within the script" - may be said as "referred to".

"set of items that belongs to a character" - may be called simpler as "inventory". Perhaps you could put the definition in front: "Inventory - is a set of items that belong to a character", and then use this term in the following text.

Well, the tutorial game sure has its benefits, as it does not throw everything into the user at once, but allows to acquaint yourself with AGS gradually.

[translation]

AGS supports loading external files for much of the game data. Simply placing new fonts in the game dir will override ones in the game package, if their names match. For example, placing "agsfnt0.wfn" in the game dir will override the font 0, and so forth.

Besides that, compiled ags games may be unpacked and repacked; there are tools made that do that, mostly unofficial ones created in the last 20 years, but also we now have ones in our repository too (we do not distribute them "officially" yet). These tools let you unpack a game into separate files, replace some files, and pack back. That's another option for replacing fonts.


In addition, I might mention that AGS engine 3.6.0 supports Unicode mode, which may be turned on by translation too. This gives an opportunity to create proper unicode translations even to older games that were made in ascii mode.

This is explained in the manual here:
https://adventuregamestudio.github.io/ags-manual/Translations.html#additional-options

So, if you place 3.6.0 engine (with SDL2 dll) in the game dir, compile a translation with the "Encoding=utf-8" hint inside (and if TRS is saved as utf-8), and provide unicode-compatible font, then you may have proper translations in any language even for the games that did not support such feature.

Trying to remember things that are asked about often enough...

- Combining character looks out of several sprites, such as add new dresses, to save on amount of sprite variants drawn. (idk if this is considered "too advanced").
- Switching playable characters, maybe temporary for some puzzle, if you don't want to make a multi-protagonist game.
- Flashlight, where you need to search a "dark" room with a circular spot of "light".
- Certain object or item closeups where you may manipulate with them.

Random weird ideas:
- An NPC photographing you, then giving you a photo, which is basically a screenshot of a game (with GUI and cursor hidden) .

Technical stuff:
- Formatting a string and displaying some values on a label or elsewhere.

I would structure this differently. I would go by room and have the player explore each room after another.

My intent was to suggest a checklist of things that should be featured in the game. How they are featured is an open question.

In regards to the rest, I see that the idea here is more of a "technical" kind of a game, where features are artificially divided in scenes, as opposed to having a "regular" game demonstrating the selection of features.

["game scenes" task group]

However, I think the demo game should be a rather simple, and not three different things in one AGS project. Newbies would have a hard time to find the relevant part in code if the project is too big.

In the previous thread I made a suggestion to plan 2 demo games: one basic one, and one advanced one, latter using modules like Tween and others for effects.

To answer your original inquiry, here are the features I think a demo game could showcase.

This is about the list I was expecting for a simple demo game.

Perhaps these could be grouped for easier task designation and making checklists; while some expanded further.

For example, "game scenes" task group would include:
- Splash screen
- Title menu
- Credits

The "UI" task group would include:
- Gameplay controls
- In-game menu

The "room composition" task group:
- Animated backgrounds
- Animated objects
- Scaling walkable areas
- Walk-behinds
- Room music

And so forth.

On another hand, for example, "Dialogs" may have subtasks:
- Turn options on and off depending on story stage.
- Different replies (on same option) depending on story stage.
- Different replies (on same option) depending on how many times did you select same option. (e.g. NPC becoming annoyed that you keep asking same question)

The game coding may be roughly divided on:
1. Scripting the story: characters walking around talking, objects changing their looks, items being picked up and used, and so forth. In AGS this is done trivially using built-in commands, with minimal understanding of coding.
2. Coding advanced gameplay and puzzle mechanics. For this you need to understand coding better.

Good coding skills are required not only to make something happen, but also to do so efficiently: spend less time, write less code, make less mistakes.

If your game does not involve any advanced features, then I think you should be able to create a good quality game, assuming other things are done well (art, music, etc). Maybe your code will not be optimal, but nobody will see it, so it's not a big deal.

If you need occasional advanced coding, for example to script certain gameplay or puzzle mechanic, then you may have to ask for aid; this is what this forum is for. Sometimes using existing script modules may be enough.

OTOH if your game requires alot of advanced coding, then it's best to recruit a programmer into your dev team.

EDIT: what I'm trying to say, the answer on your question depends on what exactly do you want to have in your game.

Just for reporting, I looked into but there's a dependency (TheoraPlayer) that I have no idea how to build. My suggestion would be to make a minimal version of TheoraPlayer and have the source files of it in the project itself, but this looks like a ton of work. There it seems to be some sort of Android Studio project of that library there in TheoraPlayer sources, but I don't understand it, and there's a CMake file, but it's not written with anything beyond Linux in mind, so I didn't push it further. 

@eri0o
I found some spare time and made a branch, placing minimal TheoraPlayer sources inside the plugin:
https://github.com/ivan-mogilko/ags-spritevideo/commits/theora-directlink2

It works on Windows and Linux.

Would it make it easier to build for Android? Note it still requires separate libpng, libogg, libtheora and libvorbis. TheoraPlayer comes with its own ogg/theora/vorbis sources, but I decided to skip these now, and only add later if there's really no other way.

Unless there's a secret development going on right now, this idea seems to have been stalling (again).

When it comes to "crowd sourced" things like these, it's essential to have a "project manager", that is a person who would have a clear vision of what the project needs, posts a list of tasks, recruit people and delegate tasks to them. Without such person the project will never move anywhere.

For example, the previous "crowd sources" project I've seen, known as "Byte of the Draculator II", involved many peoples work, but was managed by @Baron, who coordinated them.

In my opinion, since the goal of the project is to demo AGS, the planning should begin with a list of features to be demonstrated, and later with the story and exact gameplay which implement these features, as these are secondary here.

The list of features could be divided into following parts:
1. General UI and gameplay. How the game is controlled, what actions can player do, how the actions, inventory, etc is represented by gui, and so forth.
2. The distinct game parts: what kind of "screens" beside the game itself should the game include: main menu, game menu, credits screen, cutscene screens, and so on.
3. Specific rooms and kinds of puzzles: what kind of stuff would we like to demonstrate in this game, from the technical perspective (ignoring the story wrapping these puzzles for now).

After having an outline of these features, it will be a time to script a technical prototype and invent a story.
After having a roughly playable story you may look for artists to create a final look.

I can try revising this draft to reflect your comments, but as regards the errors, I don't think my knowledge of the technical side of things is advanced enough to prevent similar errors on any other page I might write, so my text would have to serve as a very rough draft in need of revision by people with more expertise. If that's OK, I can continue writing drafts. If that's not a preferable situation, I may not be the best person for this, unfortunately.

Frankly, it's not a problem if a text might require revision (that's a normal process), the problem is to get someone to make these revisions . I'd really wished to delegate the work on the manual to some other people, as I have to constantly switch between various tasks and that becomes tedious.

If you feel not confident enough on technical side, I might propose to skip certain "advanced" details in these texts, and only explain how things work in general.