Messages

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.

Is there a complete list anywhere of which items need these pages written?

No, i did not prepare this yet. I think anything relevant will do for now, as things may be restructured later.

Also, I've noticed that people here and on discord have commented that there are pages that need screenshots, which seems like an easy thing to create. Is there a list of "needed screenshots" anywhere?

Not in my knowledge.

Here is my attempt at writing a "behavioral" description of inventory items. Some of it may be incorrect or in need of clarification, but this is the extent of my knowledge of how they work:

I've read it, and am afraid that it's written in an overly "encyclopedic" style. I'd propose a more light and regular-human-friendly style for these articles, so to speak.
There are also few incorrect terms used, and incorrect information.
For instance, Inventory items are not a "script object" but a game object, which has a corresponding InventoryItem script class.
Another example, it's not inventory IDs are in array, but pointers to InventoryItem objects are.

One thing that confused me about inventory items--and this may just be the BASS template--but in the custom properties you can set the item "InstantUse" as well which changes the behavior somewhat.  I didn't realize why it affected some inventory items and not others.

All custom properties come from templates, there are no custom properties provided by AGS itself.

Something that I find strange in your example, if you already have Spanish in the game itself, then why do you need a separate Spanish translation?

Good question...maybe this is part of the problem. But if I have to refer to spanish language and this is the default idiom...how must I refer to it?

You pass an empty line:

Code: ags

Game.ChangeTranslation("");

Did you edit the key lines in TRS yourself?

No...but I changed the lines on the dialog, as you can see on the first image i posted....

The translation will not work if the key lines are different from the text in game.
You must do translation Update if you edit or add new lines.
Alternatively, you could edit them by hand, if there are only few modified lines.

But in any case, the key lines must match the game. So if in game's dialog you have "&1 Hola Jerry!!", then in TRS you should have exactly "&1 Hola Jerry!!", not "1: Hola Jerry!!".

Of course... here is:

You do not need to insert numbers there (like "1:", "2:"...), if they are not part of the text.
Did you edit the key lines in TRS yourself?

My default language is spanish in the game.

Something that I find strange in your example, if you already have Spanish in the game itself, then why do you need a separate Spanish translation?

You say it's "english.trs", but in script posted above you have Game.ChangeTranslation("Ingles")?

Another question that I have because I do not know Spanish, what is the default language in your game, the one you have in scripts and editor? Is it not the spanish already?

When you say "dialogues", do you mean a Dialog script and options, or something else? Can you show an example of a dialogue?

Well, I've been waiting for anybody interested in testing this, but it's been too long, so I cancelled the feature merged this into ags4 branch.

Voxes are supposed to be generated along with the built game, inside Compiled/Data, Compiled/Windows etc.

Please always clarify what does "not work properly" mean: you do not hear voices at all, they are from wrong language, anything else?

Which files did you create (what names and extensions exactly), and did you setup the voice numbers properly in the speech text?

On  a side note, this code does not make any sense:

Code: ags

Game.ChangeTranslation("Spanish") == true;

Perhaps you meant to use "if"?

There are number of config settings that are not a part of the save because they do not relate to game progress, but to player's preferences. For example, a player might want to continue same game using another language, or another display mode.

[and the screen stays black permanently....until I press a key or the cursor mouse]

When I test the game and record a game, it is perfectly recorded. If I use these routines to recover one of the saved games, it works too but....it fades-in to black, and the screen stays black permanently....until I press a key or the cursor mouse, so that with a fade-out the correct scene appears and the game continues without problem.
How can I avoid the need to have to press the mouse or a key for the process of restoring a game to be done perfectly?

This is not a normal behavior.

How is your game saved, in which moment exactly and what script do you use?

Do you have any commands in on_event function under eEventRestoreGame?

[Rooms]

@RootBound, hello, thank you for your interest!

I know the editor well enough to at least explain many of the "Built-in Game Features." This is essentially the list of components in the "explore project" window, correct?

Not only, there are objects that may only be created at runtime (like overlays, dynamic sprites, drawing surfaces), and also concepts that do not have a direct representation in the project tree, such as speech, animation, walking (pathfinding).

I'd like to emphasize again that there's a distinction between describing a game feature (behavior) and editing an item in the editor. In my opinion these should be distinct articles.

When I speak about features, I mean an overview of how something works in AGS.

To give couple of very crude examples:

Rooms

A game made in AGS consists of rooms. Rooms are like scenes, and may be used for various purposes: game locations, menus, cutscenes, and so forth. Rooms may have this and that. Characters travel between rooms. Only one room may be loaded and running at a time, - that is decided by where the player character is. Etc etc...

Characters

Character is meant to represent a person in the game (but may have other utilitary uses). Characters can: Speak, Walk, Animate. Character walking involves both moving and animating using current NormalView. Pathfinding is normally done over walkable areas in the room (link to what walkable areas are). Etc etc.

Would I need to have a github account?

Ideally yes, but if you don't want for some reasons, you could post the text elsewhere, except in that case we'd have to manually copy it over to the manual repository (and possibly reformat).

There's an updated version built on top of 3.6.x wip update, may be downloaded here:
https://cirrus-ci.com/task/6132921954729984

Has some performance optimizations and fixes compared to the old one. Also, the log level settings were since removed and log panel now uses the Properties panel instead (you have to select the log panel to make its settings shown).

The log font may be also configured in the Editor preferences (on Advanced tab).

I would also suggest separated panels for game messages and script messages.

I think multiple tabs could be implemented later as an additional enhancement, if really wanted. For the time being we are focusing minimal necessary setup where you may filter message types. There are potentially more message groups than game and script; also if messages of different types are displayed on different panels that might make it more difficult to find out if they are related. So it's something to think over and experiment with before making any actual changes.

Holding the back button and selecting "Toggle keyboard" does make the keyboard appear...for a split second, and then it vanishes just as quickly.  I've tried with both Hacker's Keyboard and the default Samsung keyboard.

I heard it may have something to do with restrictions on newer Android devices, but I don't know if there's anything to that.

I did not know that's a case. Could you tell what are your device specifics? I will open an issue in our issue tracker.

Is there any way to bring up the virtual keyboard when playing AGS games?

It should be brought up by holding "BACK" and choosing "Show Keyboard" in the menu.