Messages

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.

[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.

[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.

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.



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

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

how would you add the characters constant position to the log wouldnt it have to be still or it would fill up the log.

I meant, if you only need this information when character begins to move, then this information may be added to the log message that tells about character starting to walk. It will not be displayed every game frame. This is an option.

If you need to see this information every time coordinate changes, then of course it should not be printed into the log.

Could you also include a list off to the side having all the objects and characters and their coordinates

It's going to be a whole separate feature:
1) gather all this information inside the engine and pass it to the debugger (editor);
2) parse in the editor, and arrange as the list or table;
3) display this list somewhere.

I think it's doable though. The question is mostly which data to pass and how to organize visually in a nice way.
This has to allow for expansion, because as soon as it shows coordinates people will ask for other things too.


Otoh, if it's only about knowing where the character walked from when it starts walking, this may be just added to the existing log message.

By the way, this is somewhat related, but theoretically one could write a stand-alone application that either reads the engine log on the fly, from the file or stdout; or connects to the engine using same "Debugger" interface as editor uses, and then displays all messages in a window. This way one would be able to see game's log even without the editor.

I'm sorry, I did not have time to look into this yet, and I definitely should have written a better documentation.

I ended up doing a dirty hack for the time being, but I hope to sit down and adapt it properly at some point.

Just as a note, you may use switch for simplier code:

Code: ags

switch (hoverOver)
{
case gDetails:
case gResume:
// etc
    DragDrop.AutoTrackHookKey = true;
    break;
default:
    DragDrop.AutoTrackHookKey = false;
    break;
}

[@Icey]

@Icey, you need to read the description given in the first post (under the spoiler), it explains how to setup "PxPos" custom properties.

Custom properties are the way to add new values to game objects. Topic covering custom properties may be found in the manual: https://adventuregamestudio.github.io/ags-manual/CustomProperties.html

[1.]

Yes, though I think the way it works now is somewhat misleading and requires ppl to know how it works. It's really not clear.
It would be nice to not have things not running "hidden & automaticly" in the BG.

Suppose, I could add a command into a context menu saying "Update from source", and maybe a checkbox in Preferences to switch autoupdate off. Would that be better?

1. If we have this as an option, I may immediately see a problem: this lets Editor work in two "modes", where in the first the AudioCache is synced with the sources, and in the second it is not. In the second case AudioCache is detached and a kind of source itself, and audio files in it are separate variants from the ones in the source.
As a consequence, in the first "mode" the AudioCache folder is safe to delete, because it's supposedly just a copy of sources, and automatically restoring from sources is always wanted.
In the second "mode" it will NOT be safe to delete, as it's not an automatic copy, but a separate variant, not necessarily identical to the source, and automatically restoring from sources may not be wanted.
I'm concerned that this will increase the amount of trouble finding out how the editor works, and will make advising users difficult, because you will have to know which "mode" they are working on. For instance, right now I always say that it's safe to delete AudioCache / not store it inside the source control repository, so long as you have originals in the initial location, because editor will restore the cache from sources. If the above change is made, I would have to double check whether user autosyncs or not syncs AudioCache with the sources.

2. So, let's suppose that the more "proper" way would be to completely remove the autosyncing. In which case we have "mode two", where AudioCache cannot be safely deleted unless user is absolutely certain that the sources contain the variant they need for this game. Of course this also will screw everyone who is used to work with sources, editing them and expecting that the game catches them up. As well as will make storing source audio files inside the project folder unnecessarily increasing the project size, as Snarky mentioned above.

3. The third alternative, which just came to my mind, is this: if the source files are located in the relative location inside the game folder, then they are autosynced. Because if user put them into the project, they likely want these to be used automatically.
Otherwise (if they are somewhere outside) - they are not autosynced.
Again, I have no idea if this is convenient. Good systems are simple systems, that work one way.



I should also mention, that at least some developers (including me) would like to move towards having all the game resources directly in the game folder, so that there are no intermediate "caches", then a user may work with files directly in a specifically designated folder.
I.e. right now there's a change to room formats in works, that stores rooms split into its components, with backgrounds, masks etc as separate files that may be edited at will using any external editor (image editors etc).

[PS]

I would like to request similar functionality for audio clips. Sometimes you need to update the audio for whatever reason (for example to adjust the volume for consistency), and currently this requires a whole sequence of steps to replace the clip in AGS (or the "hack" of overwriting the file in the AudioCache). It would also be useful if a missing AudioCache directory could be automatically recreated from the source files (to save space with source control tracking).

I believe all this must work already, with editor checking audio timestamps of the source files. AudioCache is also supposed to be fully recreated if missing, so long as the source files can be found on their remembered locations.
Does it not?

I only remember that there has been a bug occuring under certain conditions:
https://github.com/adventuregamestudio/ags/issues/778


PS I remember to never keep AudioCache under the source control for all of my team projects, and it always worked iirc.

PPS In regards to sprites, we have a ticket for "recreate sprite file" feature, and I believe it's doable, with the exception for the sprites imported from clipboard (when you do Ctrl+C/Ctrl+V from a image editor), as these cannot have a source file reference.

Do people read "tips of the day"? I did not even remember that AGS has this thing... how useful it is?

imho it might be best to have proper articles in the manual.

The current cons of AGS, perhaps from my personal perspective:

- Game editor is frankly subpar; user interface is often awkward and limiting.
- Game project source is difficult to read, let alone work with, outside the editor. Most of the game data is inside a big xml file, and rooms are saved in binary format so you cannot even look what's inside of them without launching AGS. Imported sprites are written into one big file, where again you cannot look into them or replace without running editor. This also makes parts of the project prone to file corruption: anything happens during saving the game may make you loose a whole room, or all of the sprites.
- For the same reason, it's complicated to work with AGS games under a version control tool (svn, git etc): as parts of the game are binary blobs, it is impossible to track the actual history of their changes.
- Lack of Unicode text support.
- Imperfect translation system, where translations may be complicated to update and easy to break. No true support for localizing other parts of the game rather than the texts: such as images, sounds, voices (you have to do this by hand, sometimes using workarounds).
- Building game packages for other platforms than Windows and Linux requires manual labour. No official support for gaming consoles.
- Scripting language is a mix of low-level and high-level concepts, but does not get any of these to the logical conclusion. So on one hand you cannot refer to plain variables and structs using their memory adresses, on another you have "managed" structs but the use of these is limited by incomplete syntax and unsupported features. It's like having bits of both worlds instead of one but complete.
- Script's implementation is slower compared to popular scripting languages. This won't be noticed if you have a regular point and click scene, but may quickly become a problem if you e.g. script a fast paced arcade sequence with physics simulation, etc.
- Most of the things may be only created at the design time. You cannot have dynamically created rooms or objects. This complicates working on anything that is not a standard point and click scene, and forces you to precreate almost everything in the editor, even if you need an object only for some temporary visual effect. If you want a "procedurically generated" scene or game, you have to precreate a number of dummy objects and reuse these.
- Game saves contain practically a virtual memory state, and may be restored reliably only if the game contains exactly same game objects.
- Lack of contemporary visual effect support: e.g. no GPU-based object rotation, no custom shaders, let alone any 3D effects. Any additional effects have to be scripted with the use of the pixel drawing (aka "software drawing") which is significantly slower.
- Engine is not well optimized for high-resolution games: the way it draws things, or loads resources, maybe works well with "classic" low resolutions, but not with higher ones.
- Abscence of debugging and diagnostic capabilities: you cannot tell what's going on inside the engine when it runs your game.

Other than that drawbacks of AGS would be <...> no real cross-platform capability in engine.

What do you mean? AGS engine is working on several platforms for about 10 years now...

I also thought Godot allows to build game for many platforms, at least its in my memory from the time was I checking it out.

But I think a big con for AGS is that it's really difficult if not downright impossible for multiple coders to work on the game at the same time.

You're correct that collaborative work on programming is difficult in AGS, not impossible but requires some coordination.  I left a project in a huff when issues with SVN meant I was getting constant compiler errors.  Ideally I wanted guys to write the new code and give me references for where they wanted it copied and pasted but I got ignored.

I wonder what were the problems that people face when code same game together. Obviously it goes down to splitting the tasks between the people, just like in any other programming project. If each person works strictly on their own, and even better in their own module(s) and/or room scripts, I imagine there should not be too many conflicts.

As far as I know, the engine misuses the "high bits" of memory locations in some circumstances to store additional information there (e.g., for linking purposes). They evidently don't believe that even all 32 bits of the address space are needed.

I don't remember all details right now, but even if these "high bits" are filled - this is before the "fixups". When the real memory address are saved in script data (variables, registers) they don't contain any extra packed information.

So do we have proof that doubling the memory bits will actually buy actual game writers or actual gamers some coffee?

Back in 2012 it was not a question of providing enough RAM support, it was simply a matter of letting engine work with 64-bit memory addresses. Because without special treatment the address of allocated object could be anything beyond 32-bit offset. Plus there were engine plugins which could also allocate managed objects, and were uncontrollable by the engine.

Whether or not full 64-bit or full 32-bit addresses are required for the script to run is a question to which we have currently no clear answer, and there's a lack of game perfomance statistics in general (and little to no means to gather these, as the engine itself does not provide any means for this).

Personally I would speculate that most games created with AGS so far may fit into 32-bit memory, and those which don't likely are overusing memory due to low optimization (again speculating, but I suspect that majority of game authors are either not much concerned about this, or are not savvy enough to do this properly).

In general, I doubt that standard adventure games *need* to occupy that much memory at once. And even then, most of the mem is likely to be taken by resources (sprites, sounds), and these are not exposed into script VM, so not part of this address issue. What is left for VM addresses is: script variables and managed objects. Most managed objects are merely "wrappers" which contain ID of an actual object in the engine. So probably most managed script memory goes to: dynamic containers (arrays, etc), and dynamic sprites.

I've been unable to compile it even in x86_64.

Could you post errors you are getting?

There's no "32-bit compatibility" in the engine at the moment, rather there's "64-bit compatibility".

The whole problem was that the script's byte-code was made to assume that the variables store memory addresses directly and these are 32-bit values; therefore all of its internal arithmetics are based on that assumption. This is how the script compiler currently works.

There are following alternate solutions which I can think of:

1. Stick to 32-bit memory arithmetics in bytecode, and restrict memory allocations to the lower 32-bit on all systems, at least for data directly referenced by the script. This has been suggested couple of times in the past. This will also keep backward compatibility with old games. As a downside engine may have trouble if game requires lots of RAM. Also existing plugins that create managed objects will not work on 64-bit systems, so there will be a need to change plugin API and make engine allocate these objects for plugins on demand instead.
Tbh I don't know if this is directly supported on all OSes. There's also a way to create a "virtual heap" management in the engine (I think Nick Sonneveld had similar experiments in his repository).

2. Move to 64-bit memory arithmetics completely; will break backward compatibility with older games, and there will be some complications to make it work correctly on 32-bit systems.

3. Create a bytecode converter that adjusts it to the certain pointer bitness, either as a tool or as an engine component. Will make script depend on the system, and if converter is inside the engine will slow down game startup.

4. Redesign the script bytecode and interpreter to not depend on pointer size.
(Additionally, there's always an option to create a bytecode converter that adjusts old game bytecode to the new format, if backward compatibility is wanted.)

If I recall correctly, AGS 4 is going to practically be a fresh start

No, it's fully based on current AGS, with just certain things cut off.

As far as I know, the biggest recent impact on script perfomance was caused by using a RuntimeScriptValue struct, or rather extra function calls (sometimes virtual function calls) and pointer accesses which followed as a consequence to using this struct. Originally there was no this struct and all memory accesses were direct although anonymous (you could not tell what object or variable is being accessed, not even its type), which was very fast, but due to how the interpreter worked (and how the bytecode was compiled) it was limiting pointers to 32-bit, which of course made this incompatible with 64-bit systems.
There were other reasons and purposes for this change, but today I no longer think these reasons and purposes were right.

In theory it might be possible to rewrite the script interpreter again and solve this differently. It might also be possible to do some partial changes without big rewrite and improve things somewhat.

But knowing that most of trouble comes from backward compatibility, the better way could be to redesign the bytecode and its compilation, and make it not rely on the pointer size when generating code.

Most of the trouble with AGS kept happening because back in 2012 we (the 3 or 4 people who were working on it at the time) used a backward compatible engine (meant for running old games) as a base for the further development. Thus the engine had 2 purposes which often conflicted with each other, causing restriction to what we may do.


PS. And of course there's always an option to replace the scripting language to something which is faster and has better list of features. For instance, years ago several people were advocating for Lua (there even has been a Lua plugin). Personally, my main concern was a huge difference in syntax between Lua and AGS script. Well, this all has been discussed many times on these forums.

object references could be direct but they use a hashmap/btree

Ouch.

I do not know if eri0o is refering to what I may suspect he's refering to, but if it's about accessing managed objects in script, primary access operations are done through flat array; hashmap is only used for the backward lookup (object pointer to managed handle) and that is done in limited cases (like disposing an object).
Of course hashmap or btree may be somewhat slower than accessing objects directly, but there has to be an actual research to find out if that is the cause of slowdown, and how much does it slow down anything in relative terms.
There's much more going on there when working with managed objects.