Messages

The idea is that the player wouldn't be able to open gPanel by pressing the ESC key in my first room (with "new" - "load" - "quit")

Well, you have a command somewhere that performs that action by ESC key press. You need to find it in your script, and add a condition that player.Room is not certain room.

I tried to disable the ESC key in that room, or to disable the gPanel GUI so when pressing ESC nothing would happen.

Please explain in detail what did you do?

Added to 3.6.0
https://www.adventuregamestudio.co.uk/forums/index.php?topic=58976.msg636643259#msg636643259

[Editor:]

Updated to Alpha 17
(use download links in the first post)

Synced with AGS 3.5.1 - Patch 8.

New changes:

Editor:
- Added Web/Emscripten build target support (requires "Web build component" installed). See below for brief instructions.
- Added Character.IdleAnimationDelay property to let setup idle view's animation speed.
- Added Cursor.AnimationDelay property to let setup cursor's animation speed.
- Rooms created from a Blank template will now have default background of a game's resolution.
- Editor no longer prevents exporting string arguments from Get/SetTextProperty calls to TRS file.
- Fixed Custom properties' default values were not exported to translation.

Script API:
- Hotspot.Name and Object.Name may now be set in script.
- Added Character.IdleAnimationDelay to let control idle view's animation speed.
- Added new delay parameter to Mouse.ChangeModeView() to let control cursor's animation speed.

Engine:
- Fixed AudioChannel.Speed not working.
- Fixed AudioChannel.PositionMs now resetting when the repeating clip rewinds.
- Fixed File.ReadRawLine() failing at character values >127.
- Fixed potential crash on room load if the walkable area mask contained color values above the supported range.
- Fixed loading savegame made before 3.6.0 was crashing due to incorrect audio channels initialization.

Web / Emscripten:
- Initial port release.



In regards to building Web version of the game. We do not provide necessary files in installation yet, so you'd have to download them yourself for now. They may be found attached to any release on github starting with v3.6.0.16, the archive is called "emscripten.zip". For instance, the current one is: https://github.com/adventuregamestudio/ags/releases/download/v.3.6.0.16/emscripten.zip

Go to your Editor's program folder, create a new subfolder inside called "Web". Unpack emscripten.zip there (unpack fully, there are several archives inside for technical reasons, we will fix this later).
You should now have 4 files there:
- ags.js
- ags.wasm
- index.html
- my_game_files.js

Now when you have this, run the Editor and open your project. The new "Web" Build target should become available. If you check it, and rebuild the project, the Editor will deploy necessary files into Compiled/Web folder in your project.

Note that you cannot run index.html directly, it likely won't work. You need to create a web server with these files on it. There is a multitude of ways you can do that. For example I've been testing this using a simple Google Chrome app called Web Server for Chrome. You may find your own way.

For any questions regarding the Web port please refer to and post in dedicated forum thread:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=59164.0

[Download AGS 3.5.1 installer]

AGS 3.5.1 - Patch 8

Full release number: 3.5.1.15

Download AGS 3.5.1 installer

Download AGS 3.5.1 as a .zip archive

For Editor

Spoiler

VC 2015 redistributable needed for AGS Editor on Windows

Download Dark UI Theme for the editor

[close]

For Android

Spoiler

Android launcher (APK signed with Debug key), suitable for running any compatible AGS game

Native engine libraries, for making your own signed APKs

[close]

For Engine/Editor developers

Spoiler

AGS source code central repository

Debug symbols database (for analysing crash dumps)

[close]

Released: 4th February 2022

Previous stable version: AGS 3.5.0 P10 forum thread


This release is brought to you by:

- Alan v. Drake
- Crimson Wizard
- eri0o
- fernewelten (fixes)
- James Duong (implemented "--console-attach" option for Windows)
- Morgan Willcock
- Nick Sonneveld
- rofl0r
- Pablo Navarro (fixes)
- Thierry Crozat (bug fixing)
- vga256 (bug fixing)



Summary

3.5.1 is a minor update after 3.5.0, which contains mostly utility additions, fixes and perfomance improvements.

For the reference, we currently have another major version in works, which is already usable although may be not as stable, and introduces a SDL2-based engine, planned to be released as 3.6.0. If you're interested you may find it here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=58976.0



Changes in the Patch 8:

Engine:
- Clearer error messages for Get/SetProperty functions.
- Fixed PlayFlic() command fails to start the video (regression in 3.5.1).
- Fixed DrawingSurface.DrawSurface() not applying transparency parameter correctly if the drawn surface has alpha channel.
- Fixed @OVERHOTSPOT@ is not updated immediately when character's name changes while cursor is above that character.

Templates:
- In BASS template fixed right click not dropping currently selected item if cursor was hovering over another item.


Changes in the Patch 7:

Editor:
- Added "Layout -> Reset to Defaults" menu command.
- Editor will now reset panel layout to default state if loading layout fail for any reason.
- Default config is now saved also when the game is run in debug mode (F5). This ensures that the test run is using the latest Default Setup, if the user's config has not been created yet.
- Editor will now display an error if user tried to reserve too many channels for audio types.
- Fixed Editor failing to start if user preferences file is corrupted.
- Fixed "Use old-style custom dialog options API" was not set when importing pre-3.4.0 projects.
- Fixed comboboxes' drop-down arrows were not painted with the right color from a color theme.

Engine:
- Fixed program crash occuring if the game reserved too many channels for audio types.
- Fixed potential crash occuring when player loads a save made in a multi-frame room, but the room was since edited and no longer has as many frames.
- Fixed character may have incorrect Frame (property) values while turning.


Changes in the Patch 6:

Editor:
- Added line numbers in the dialog script editor.
- Fixed Dialog script loosing changes if the pane is closed or redocked.
- Fixed controls arrangement on the Dialog pane getting broken when it's redocked.

Engine:
- Fixed filepaths in scripts that have backslashes ('\') fail on non-Windows systems.
   All the (script) File functions will now convert backslashes in filepaths into forward slashes for compatibility.
- Fixed engine was still creating standard directories for game saves and data, even if user provided the custom paths for these.
- Fixed TextBox control crashing the game if it's empty and player presses Backspace.
- Fixed controls on a fully transparent GUI were not interactive (this is an original AGS behavior, which was unintentionally changed in 3.5.0 by mistake).

Compatibility:
- When running 3.5.0 games, treat fully transparent GUI as non-interactable.
   In AGS transparent GUIs may be still interacted with, but 3.5.0 introduced an unintentional (and undocumented) change to this, which was reverted in 3.5.1.

Android:
- Support global engine's config file when the game is run from the Launcher: it's located in the AGS games' parent directory, same place where android.cfg is.

WinSetup:
- Added "Custom game shared data path" to complement "Custom save path" option.


Changes in the Patch 5:

Contained no changes and was a formal re-release with only fixed program build instructions for Linux.


Changes in the Patch 4:

Editor:
- Fixed swapping of inventory item's numeric ID could lead to errors.
- Fixed crash when importing pre-3.* games with multiple script modules.
- Renamed "Enforce object-based scripting" setting to "Enforce post-2.62 scripting". This is for clarity.

Compiler:
- Fixed potential memory corruption when user script reaches max nested if/else blocks.

Engine:
- Also tell module name and approximate source line when reporting script import errors for the variables and local functions.


Changes in the Patch 3:

Editor:
- Fixed sprite file over 2 GB could not be loaded (regression since the last patch).

Engine:
- Further improvement to GUI perfomance: don't redraw GUI when the mouse cursor is hovering over or interacting with controls not leading to an actual visual change.
- Fixed ListBox items could become unaccessible if its font or height is changed leading to a disabled scrollbar.


Changes in the Patch 2:

Engine:
- Fixed speech lipsync getting disabled after loading another game with RunAGSGame().
- Fixed MOD/XM clips fail to play (regression).
- Fixed certain OGV videos fail to play (regression).
- Fixed software renderer was not updating game screen correctly when running a game with legacy "letterboxed" feature (regression).


Changes in the Patch 1:

Editor:
- Fixed script compiler sometimes was not specifying actual Dialog number when reporting errors in the dialog scripts.

Engine:
- Fixed Game.TranslationFilename always returning empty string (regression).
- Fixed GUI controls which were toggled from disabled to enabled state not responding to the mouse clicks until the mouse is moved (regression).
- Fixed OpenGL did not apply a Linear filter when "Render sprites in screen resolution" option is off.


What is new in 3.5.1

Editor:
- Added "Attach game data to exe" option to General Settings. This lets you to package game data separately from the game.exe (only important on Windows at the moment).
- Deprecated "Limit display mode to 16-bit" property in Runtime Setup as it's no longer used by the engine.
- Display aspect ratio in game resolution dialog.
- Implemented classic Color Picker dialog for the Color type values in the property grid, instead of the default one which does not allow user-defined colors.
- Improved tab switching performance for script windows.
- Editor will now enforce full game rebuild after upgrading an older project, this ensures that all scripts are recompiled with the new version rules.
- Fixed room lists in property editor were not updated after room number is changed.
- Fixed importing pre-3.* projects broken by incorrect assignment of "Game file name" property.
- Fixed importing Characters and GUI without sprites still created empty sprite folders.
- Fixed crash when exporting/importing Characters with no Normal View.
- Fixed translation compiler did not correctly save some of the escaped sequences, such as "\n".

Scripting:
- Implemented correct parsing of a "const string" function return type.
- Fixed implementing imported functions was forbidden in the room scripts.

Script API:
- Added GUI.Shown readonly property that tells whether GUI is active on screen. This is primarily for GUIs with "Popup At Y" style, because they hide themselves regardless of Visible property. Note that since 3.5.0 GUI.Visible only tells a script-set value.
- File.Open() now supports $CONFIGFILE$ tag which will try to open user config file for reading or writing regardless of where config is located on disk.
- Added System.SaveConfigToFile() which writes current engine settings to the user config file. Only the options that can be changed at runtime are written back at the moment.
- GetTranslation() now returns "const string" (was "string"). This is to prevent modifying returned string using old-style string functions, such as StrCat(), as this string may be allocated in the internal engine memory for its own use.

Engine:
- Support loading audio and video from data packages larger than 2 GB.
- Improved game data loading times by introducing buffered file stream. Initial tests showed 3-4 times faster file reading.
- Improved game perfomance by not reupdating all of the GUIs each time anything changes, instead only affected GUI will be updated each time.
- Some improvement to general script perfomance.
- Some improvement to script Dictionary and Set types perfomance.
- Room Object's Graphic property now can be assigned a sprite with index over 32767 and up to 65535. This restriction is due to internal data format, which cannot be fully fixed without breaking compatibility with plugin API. This may still be worked around by assigning a View, as View's frames may contain sprites of any index available.
- Similarily, Object's View, Loop and Frame can now be assigned a value over 32767 and up to 65535; not that this was ever an issue...
- Removed arbitrary limit of 1000000 dynamic array elements (now supports over 2 billion).
- Dialogs with no enabled options left will be now stopped, instead of raising script error.
- Engine will not longer quit the game when failing to write a save, but simply display an error on screen (...why this was a thing in the first place?!).
- When restoring a save engine will now try to match game pack by GUID rather than using exe/pack name. This resolves potential problems when game package may have different name in distribution to another system. Also makes saves in multi-game collections more reliable.
- In Debug game mode allow to toggle infinite FPS mode (prior it could not be turned off).
- Expanded text parser error messages for easier debugging.
- Adjusted all the command-line options to have consistent prefix convention, where all full-name options must be preceded by double-dash, and one-letter options by single dash.
- Added "--localuserconf" command and similar global config option which tells engine to read and write user config in the game's directory rather than using standard platform path. Game dir must be writeable for this to work.
- Added "--conf" command which forces engine to read only explicit config file on startup.
- Added "--user-data-dir" and "--shared-data-dir" commands for setting save game directory and shared app data directory from command line (this corresponds to existing options in config).
- Fully configurable log output (in both game config and command line) allows to set up which message types and groups are printed by which output methods (sinks), including: file, system console, in-game console. "warnings.log" is now created only if file log was not requested by user.
- Added "--log-" set of command line options for setting up log output.
- Added "--tell-filepath" option for printing known engine's and game's file locations.
- Added "--tell-gameproperties" option for printing some of the game's general settings.
More information on log config and --tell commands currently may be found in following text file: OPTIONS.md
This has to be added to the manual eventually.
- Support proper lookup for Allegro 4 library resources (such as its own config and digital MIDI patches) in the game directory.
- Engine will no longer precreate directories for common files: saves, user config, shared files and so forth, - before actually having to write these. This ensures that no new directories are created on your disk without actual need. Also this fixed a problem that could happen if someone deleted e.g. a game's save directory while game was running.
- Fixed running game from another directory by passing its relative filename as command-line argument: in this case engine was incorrectly using its own directory to search for external game data, opening files for reading by script command, and so on.
- Fixed some of the engine's own hotkeys (such windowed/fullscreen mode toggle) not working during certain skippable game states.
- Fixed overlay was set to wrong position if it were using TextWindow gui and either its text or X, Y properties got changed.
- Fixed crash occuring when the speech is using text window gui with zero Padding and the speech text is an empty line.
- Fixed characters and room objects were not updating their looks if their current graphic was a Dynamic Sprite, and that sprite was modified with ChangeCanvasSize, CopyTransparencyMask, Crop, Flip, Resize, Rotate or Tint function.
- Fixed Views' frames keeping reference to deleted Dynamic Sprites causing crashes. Now they will be reset to dummy sprite 0 for safety.
- Fixed engine crash when button's graphic is set to sprite out of range.
- Fixed animated cursor's normal graphic reappearing in between animation frames if mouse mode is being repeatedly reassigned, for example in rep-exec script.
- Fixed certain interactions did not work with GUI if it was made fully transparent.
- Fixed ListBox.FillSaveGameList() search pattern, it included files which contain save filename pattern but do not exactly match; for example: "agssave.001_".
- Fixed engine was ignoring audio files in game directory when running games which use old audio system.
- Fixed crash in Direct3D and OpenGL renderers that occured if game uses a plugin that performs software drawing on screen, and one of the rooms is smaller than the game's resolution.
- Fixed Direct3D was assigning wrong fullscreen refresh rate sometimes, slowing alt-tabbing.
- Fixed "--test" mode was lost upon restoring a save.

Engine Plugin API:
- Added IAGSEngine::GetRenderStageDesc() function which returns current render stage parameters. As of this version these parameters include 3 transformation matrixes, allowing any 3D render plugin to stay compliant to engine's scene rendering.

Compatibility:
- Fixed engine was trying to read unnecessary data when loading pre-2.72 games.
- Fixed "upscale" mode for old games (was broken in 3.5.0). Also engine will now try to detect if "upscale" mode wanted by reading old config options (if they are present).
- Fixed GUI.Visible not returning expected values for GUIs with "Popup At Y" style in pre-3.5.0 games, breaking some older games logic.
- Fixed potential buffer overflow when reading pre-3.1.0 games with old dialog script texts.
- Fixed engine was applying player's position too early when ChangeRoom was called for 2.72 and earlier games, which could result in wrong placement in the new room if the character was walking right before the transition.

Android:
- Corrected game scanning in AGS launcher, now it will work consistently with the desktop ports, and detect any compatible game data files named "*.ags" or "*.exe".

OSX:
- When looking for game files engine will no longer use hardcoded filename, will search for any compatible pack file instead.

Windows:
- Windows version of the engine now reads global configuration file. It is looked up in "%USERPROFILE%/Saved Games/Adventure Game Studio/acsetup.cfg"
- Default log file location is now also in "%USERPROFILE%/Saved Games/Adventure Game Studio".
- Added "--no-message-box" command line option to hide message boxes when alerts are raised. These messages will be still printed to log (if one is enabled).
- Added "--console-attach" command line option to try attach to the parent process's console. This is useful if you run game from command line and want to see engine's log in the console.

WinSetup:
- Fixed changing fullscreen mode from "use current desktop" to explicit resolution on save.







Thanks to everyone who contributed to and tested this version!

If you want something to happen anytime any room is started, there's a "on_event" function (in global script):
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Event.html#on_event

Code: ags

function on_event(EventType event, int data)
{
     if (event == eEventEnterRoomBeforeFadein)
     {
           // do something
     }
}

Hello guys, I really need help with this.
I have the emulator installed on Android. I saved my game.exe on the phone. When I open the emulator I can see the name of my game appearing. When I try to open the game by clicking on it, an error message tells that "Error: unable to find game data files". I also added the acsetup.cfg, audio.vox, winsetup.exe.
I am stuck! Thanks in advance! Marta

Please tell, what version of emulator are you using, and what version of AGS the game was made with?

Also note, that you dont need to use "game.exe", if it's your game you may use raw game data from Compiled/Data. winsetup.exe is also not necessary, it's a Windows only setup program.

[and]

OK, but the ReadRawLineBack function is used in another .txt file, not the one for the translation. So are we talking about the same thing ?

There are two separate problems.

1. ReadRawLineBack had a mistake that made it cut the line if a utf-8 character is met. Now this is fixed, you may download the patched editor here:
https://cirrus-ci.com/task/5287098419773440

2. Displaying the UTF-8 characters on screen. This is not directly related to ReadRawLineBack, but related to the data it read.
Engine will only display UTF-8 characters on screen if it works in "unicode" mode and you provide a proper unicode font.
There's currently only one way to switch engine to "unicode" mode: it is to enable translation that has "//#Encoding=UTF-8" in it.

[active]

Does that mean that I need to put this :

At the top of my translation file, then save the file where I have to read something using the ReadRawLineBack function in UTF-8, and then it will work as expected ?

You need to have that translation active, for the engine to display the UTF-8 text.
Create and compile translation normally, you don't have to save the file somewhere else.


On a separate note, we're currently conducting experiments to see how easy that would be to make the Editor itself work and save data in unicode mode. If it worked, then users won't have to rely on translations.
There are preliminary tests that give a hope it's possible, but this may take a while to integrate, so no promises for now.

It seems that "é" was causing an error in the ReadRawLineBack function. I changed into the .txt file and replaced all the "é" with "e", and it worked perfectly.

Any idea what's happenning ? It was NOT happenning with the 3.5.1 version I used before

Yes, this is a bug in 3.6.0, any letter with code above 127 will be mistakenly treated as an end of file. We have this recorded, and it will be trivial to fix.

I should note just in case, that if the letter is a "unicode" one (code above 255), and text is saved as UTF-8, this expected to be read normally (after this bug is fixed), as it reads byte by byte, but the string will only be correctly displayed if the engine works in the Unicode mode. Currently it may only be switched to this mode by the use of translation options; if you use translations and it has a utf-8 encoding option set, as explained in the thread: https://www.adventuregamestudio.co.uk/forums/index.php?topic=59240.0

EDIT : was the limit of 199 removed for the ReadRawLineBack function ? I thought that yes, but I'm not sure...

Yes, it should be mentioned in the Changes log: https://github.com/adventuregamestudio/ags/blob/master/Changes.txt

EDIT 2 : just managed to launch the game with the 3.6, and I found that scrolling with the finger pad works perfectly ! (it was one of my previous questions).

Nice, this is very good to know that SDL2 works better in this regard.

I unstickied and locked this old thread, because it was started many years ago and contains alot of obsolete information.

The new one is opened here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=59751.0

[AGS-3.x.x.x-debug.apk]

The old forum thread may still be found here. Please beware that it was started many years ago and may contain alot of outdated information.

This new thread is dedicated to discussing the Android port of AGS engine. Following is a brief cover of the topic.



AGS engine has an Android port that can run on most contemporary devices. [TODO] check device ranges and minimal requirements.
To run AGS games on Android you need a dedicated Android app (APK) and a game data.
We support two kinds of applications: a universal game launcher (aka "AGS Player") that can run just any random AGS game without any extra manipulations, and a single game app that you have to package along with the game data yourself into a signed APK. The latter may be then distributed by game shops, such as Google Play.

Currently the v3.x.x engine branch supports running games created with AGS 2.50 and higher.



AGS Player

"AGS Player" is a universal game launcher on Android, that displays a list of found AGS games and lets you run them.

This launcher requires games to be unpacked, placed in the internal storage or sd card, one game in its own subdirectory. You may use raw game data (*.ags files), or even games compiled for other platforms such as Windows ( Windows version of a game is usually just an engine exe with game data appended to it).

We distribute AGS Player with every release of AGS. The download link may be found in respective forum posts for each release.
Another place to find them is releases page in our repository: https://github.com/adventuregamestudio/ags/releases
In the Assets look for AGS-3.x.x.x-debug.apk and AGS-3.x.x.x-release.apk (these are same program, built with debug or release configuration).
If you'd like to build it yourself, you may do so following these instructions: https://github.com/adventuregamestudio/ags/blob/master/Android/README.md

After installing one on your Android device, run it and open the [...] menu, choose "Select game folder". Then type the path or browse to the parent folder you keep all your AGS games in (NOTE: browse button is added since v3.6.0).
You will see the list of all games that the AGS Player detected in that directory. Note that since v3.6.0 the search is recursive, displaying games also found in subfolders.
Touch the game name to run one.

KNOWN ISSUES

1. Please be aware that most AGS games are made not having touch screen in mind. We therefore cannot guarantee (or be responsible for) positive gaming experience. The port provides basic touch controls, and these may be configured to some degree, but they may not be convenient at all times. We accept suggestions for improving these controls, so long as these are universally useful (not meant for a specific game). Ideally the game should be adjusted for mobile/touch controls by their authors.

2. If the game requires engine plugins to run, these have to be included into the launcher APK. We include several plugins by default, mostly ones that were popular among AGS game authors in the past. We may probably expand the list of these plugins if there will be a demand for it.



Building games for Android in the Editor

Editor also comes with an optional feature that lets you deploy for Android using a ported engine.
To use this feature make sure you have installed the "Android build component" along with the editor. This creates a "Android" subfolder inside the Editor's program folder. After that a "Android" option will become available for selection in "Build targets" list in the General Settings of your game project.
You would also require Android Studio.

Before running the build you will have to configure paths to Android SDK and other options. This is done in File->Preferences dialog, on "Android" tab. These options will be used for all your games.
The "Android" section in General Settings is used to configure individual game's properties related to Android build, such as game name, and package format.

The compiled game will be placed into Compiled/Android folder.

For detailed information please see this dedicated forum post:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=59772.0



Building single game APK without Editor

If you'd like to have your individual game APK which you may distribute, or even sell on e.g. Google Play, you have to build one by combining following components:
- The Java/Kotlin application. We provide an project template for this: https://github.com/adventuregamestudio/ags/tree/master/Android/mygame
- The native engine module (and optionally plugins) in the form of dynamic libraries (*.so). You may either build these yourself following instructions in the README, or get prebuilt ones attached to corresponding AGS release. The archive is called AGS-3.x.x.x-android-libs.
- Your raw game's data found in Compiled/Data folder after compilation.

For building the full APK you will be also requiring Android Studio and some other tools.
The process is explained in this dedicated readme: https://github.com/adventuregamestudio/ags/tree/master/Android/mygame#readme

If you encountered bugs or have feature suggestions, you may open an issue in our tracker.



Any other useful information may be added to this post later.

I'd like to unstick and close this thread, as it is inactive for too long, and we mostly moved these kinds of development discussions to github.
As eri0o pointed out, the coding convention was moved (mostly) to THIS PAGE

But if someone likes to discuss this again, a new forum topic may be opened of course.

PS. Looking back, my personal views on code style and habits have changed significantly.

[NOTE:]

NOTE: as this thread was started 10 years ago, I closed it and opened a new one with the fully refreshed information in the top post:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=59750.0

[KNOWN ISSUES]

The old forum thread may still be found here. Please beware that it was started many years ago and may contain alot of outdated information.

This new thread is dedicated to discussing the Linux port of AGS engine. Following is a brief cover of the topic.


AGS engine runs on 32-bit and 64-bit Linux.
To run AGS games on Linux you need the Linux engine and a game data.
The same game data may be run by any engine port. Some ports require repacking it up in certain way (e.g. packing into APK for Android). For Linux this is not necessary.
Note that you may even use games created for e.g. Windows, because Windows version of a game is usually just an engine exe with game data appended to it. Normally any engine port can detect the game data in a file and load it up itself.

Currently the v3.x.x engine branch supports running games created with AGS 2.50 and higher.

If you have an engine executable coming with the game itself you may run it, or use a startup script supplied by the game authors.
If you have an engine installed on your system, all you have to do is to go into the game's directory and run the engine from there. Alternatively: run the engine, passing path to the game dir as a command line argument.

More information about command line args and runtime configuration may be found in our repository:
https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md


Building games for Linux in the Editor

When you compile your game using the Editor, it produces "raw" game data in Compiled/Data directory. These files alone may be enough to run a game using an engine port.

However, Editor also comes with an optional feature that lets you deploy for Linux using a prebuilt Linux engine and libraries. Please note that these will normally run only on Debian and related systems (Debian, Ubuntu, etc). For other systems you, or your users (players) would have to either build an engine from sources or get one from the system's maintainers (see more info below).
To use this feature make sure you have installed the "Linux build component" along with the editor. This creates a "Linux" subfolder inside the Editor's program folder. After that a "Linux" option will become available for selection in "Build targets" list in the General Settings of your game project. The compiled game for linux will be placed into Compiled/Linux folder.

KNOWN ISSUES

1. As of time of writing, because the linux files will be deployed on a Windows machine, the engine and launch scripts will loose their "executable" flags. The only known solution currently is to move these files onto the Linux machine and set this flag there before creating an archive. Alternatively, the users themselves may do that after your game's installation.

Following are commands that you must perform over the game distributive on a Linux machine:

Code: bash

chmod +x data/ags32
chmod +x data/ags64
chmod +x gamefilename

where "gamefilename" is the game's file name, and also the name of the launcher file in the root of game's package.

2. If your game uses any engine plugins, you MUST supply linux variants of these. If these are not available, the only workaround is to modify the script of your game specifically for Linux version to avoid relying on these plugins or using any plugin's commands. Otherwise the game won't run correctly, or at all.


Getting a stand-alone Linux engine

There are roughly 3 ways you may get a Linux engine onto your system.

1. Our build server makes engine binaries and Debian packages, runnable on Debian and related systems.These may be downloaded from Releases section of our repository:
https://github.com/adventuregamestudio/ags/releases

2. Some system maintainers may include ags engine into the official list of packages; in such case you may install the engine using your system software. Usually that may be found using a package manager on your OS, or asking system maintainers for information.

3. If nothing of above works, or you simply want to, you may build the engine yourself from the sources.
Our repository is: https://github.com/adventuregamestudio/ags
The information on Linux port may be found here: https://github.com/adventuregamestudio/ags/blob/master/debian/README.md

We have a Makefile, so if you prefer using make, then it may be as easy as

Code: ags

cd Engine
make

(assuming you have all the dependencies installed)

If you prefer CMake, then refer to https://github.com/adventuregamestudio/ags/blob/master/CMAKE.md

If you encountered bugs or have feature suggestions, you may open an issue in our tracker.


Game-written paths and files

Following are the default locations of files created by the game:

User config: $XDG_DATA_HOME/ags/GAMENAME/acsetup.cfg
Game saves: $XDG_DATA_HOME/ags/GAMENAME/
Shared game files*: $XDG_DATA_HOME/ags-common/GAMENAME/
Engine log location: $XDG_DATA_HOME/ags/

* - shared game files are ones that are written in script using $APPDATADIR$ path token.

NOTES:
1. You, or players, may assign a different savegame location in game config, see these docs:
https://adventuregamestudio.github.io/ags-manual/DefaultSetup.html#environment
https://adventuregamestudio.github.io/ags-manual/EngineConfigFile.html#configuration-file-options
2. Because there's no analogue of WinSetup on Linux, the "user config" may only be written by the engine if you call System.SaveConfigToFile() in script.

I have videos and text instructions on my website https://anthonyirwin.com/adventure-game-studio-ags-macos-build/

Hello.
There is an outdated information in these instructions, related to using game files:
You do not have to use Windows files, but use files from Compiled/Data instead: these are raw game data without windows engine attached.
Renaming file to ac2game.dat is also not necessary. Older version of the mac port was searching for that file explicitly. Now it should be accepting any filename, iirc, but the convention is to have file called gamename.ags.

This is mentioned in the 3.5.1 readme here:
https://github.com/adventuregamestudio/ags/blob/release-3.5.1/OSX/README.md

According to the error message, the file must be called exactly "lib_agsshell.so"; in the first post you mentioned "libagsshell.so" without underscore. Please double check that the name.
IIRC the linux's library must be called exactly like the dll, bit with a "lib" prefix.
For example, if the dll is called "my_plugin.dll", the *.so should be "libmy_plugin.so".

Normally there should be 2 files, one for 32-bit and another for 64-bit linux, put in the Linux/lib32 and/or Linux/lib64 respectively.

Editor only checks for the plugin presence in its program folder, and ignores them in the game's Compiled folder.

I rarely remember of precise details, or rarely have them in dreams, but remember an idea of a dream sometimes.

Just recently, i had a dream where a gigantic ship crashed in the coastal city's bay and half-sunk. There was an artificial island nearby built by a secretive billionare, and rumors said that he had a prediction of this ship crashing many years ago, so specifically built his mansion nearby to receive a direct access to it when it will crash there years later. It might have been of great importance to him... A group of operatives is sent to investigate the island. Last thing i recall is how we got attacked by tiny baby-like creatures crawling out of the sea.

This sounds a little like Resident Evil game, although I never played any of these.


PS. BTW, I recall there have been another thread about dreams a while ago.
Here it is: https://www.adventuregamestudio.co.uk/forums/index.php?topic=57318.0
Also found another small one: https://www.adventuregamestudio.co.uk/forums/index.php?topic=55458.0

I don't know if it's a lot, and I should have to calculate for the whole data of my game.

I must admit that 2.5 MB is not a lot today, especially compared to the rest of the game data.

Having very long script files is also impacting the RAM ?

Yes, script are compiled, and compiled scripts are loaded by the engine fully. The bigger script is, the bigger memory it requires.
Usually script sizes are in kilobytes though, but this may be more if they also include large global arrays of fixed size.

When you talk about disk cache : what do you mean ? How to use that in AGS ?

Save data into the custom file, remove it from the variables. When necessary - load it back. There are file commands in ags script:
https://adventuregamestudio.github.io/ags-manual/File.html
But the disk cache is the last resort, you probably won't need this. Unless you are close to the game completion and found that your script data takes too much memory.

If I understand you well, instead of having an array like cartes[150] that is initialized at game_start, I should have instead only one 'cartes' instance, and a function like :

I mean rather - have these cartes stored in files, and loaded, as scripting everything in a function will likely require same memory. The point of this solution is to not have all of this data mentioned in script.
But this solution comes with extra problem: you need to save these files prior to using them in game. This means that you also need some kind of a "map editor", either scripted as a AGS game, or separate tool.
Alternatively, you may describe maps in a text format and parse them in script, for instance using IniFile module.

EDIT : when I run my game, I just had a look at the Task Manager, and it displays 408,5Mo in the Memory Section. Does it mean I'm using 408,5Mo over 3GB ?

That likely means your active process(es) are using 408 Mb total.
I think "Mo" is "Megabytes" in French?

EDIT 3 : I don't understand what are the custom saves. What's about ? Instead of AGS saves ?

You may save and load your own files from script. This way you can write only data that you need for your game to remember.
How to work with custom files in AGS:
https://adventuregamestudio.github.io/ags-manual/File.html

Again, this is an option, and you may look into this after you deal with other problems.

I wonder how many data can be stored in an AGS game.

This depends on the system you're running it on.

E.g. on Windows the engine is still distributed as a 32-bit app, which means that it cannot exceed 3 GB of RAM (iirc). If we build a 64-bit program, then it will allow much more. But it will never be able to surpass what the player has on their computer, obviously. If player has 2 GB RAM, that's it (and portion of that RAM will always be used by an operating system).

If you have a plain struct, then you dont have to guess, instead calculate the size of the struct. Your struct is mostly ints. One integer is 4 bytes. Sum up all the ints and arrays of ints you have, and you'll know how much it takes exactly.

If you have too much data, the general approach, for engines and games, is not to have literally everything loaded at the same time. Instead, have only 1 instance of a struct representing current location, and have actual data saved in files. Load one part of your world at a time, and replace it when the player moves outside.

In memory keep only things that may change. If that's convenient, you may make a second struct for that, having only data that can be changed, and have such structs for each "left" area where player may return to later. When player leaves the area, copy respective data from the "main" struct to the "memory" struct. When player enters previously visited area again, copy from "memory" struct to the "main" struct.

If that is also too much, there's still a resort: use disk cache. Basically, write the data for the inactive parts of the world to files, and read from these as player returns to them.

And since you are doing your own type of game, I strongly recommend considering custom saves instead of using AGS own saves: this way you will only save what your game actually needs.