Survey: what is good in AGS and what needs improvement

Started by Crimson Wizard, Fri 12/01/2018 01:10:23

Previous topic - Next topic

Crimson Wizard

Hello.

First of all, this is NOT another "feature request" topic.
This is also NOT "what to add to the next version of AGS" topic.


Sorry for this disclaimer. Please read further :).




There are few new engines underway, being made by people known in AGS community, such as XAGE, MonoAGS, and maybe some others we do not know about. They may copy AGS to some degree or reimagine adventure creating tool in their own way. Since I am currently considering contributing to one of them, and just because I think that might be important for any such undertaking, I would like to make a following survey.

The primary targets for this survey are people who have big experience working with AGS, but others may participate too, of course.

Survey has only two simple questions, but they may need extensive answers:
1) What do you like about AGS, and would like to keep if any new creative tool arrives?
2) What do you think should be changed (added, removed, altered)?

Now, this is NOT about simple and obvious things, like
- not being able to change GUI color at runtime, or
- having a limit of N sprites, or
- running on many platforms, etc

but rather about ones, such as
* editing workflow,
* methods to achieve something you want,
* script API design
(how well does script allow you to control game behavior), and so forth.

If you have experience working with other game creating systems, and may make a comparison, please do so.

I know that similar discussions were held in the past, but that may be hard to find these posts, so I wanted to make something "centralized" for this time. But links to old forum threads are also accepted.

Jack

The games I've been making have been pretty scripting and graphically intensive, and the thing I like most about AGS is the flexibility and the support for multiple platforms. On top of this, setting up a basic game is fairly simplistic. Hitting this intersection of simplicity and flexibility is the holy grail, and somehow AGS scores very highly here.

If you had to change just one thing and forget about the rest, I would say it is to port the graphical engine to something faster. Personally I would go for something as established and widely supported as possible, like OpenGL, rather than whatever buzzword the sycophants are drooling on this week.

Gurok

AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Radiant

Adventure games contain a number of elements that we take for granted but are really not trivial to implement. For instance, walkbehinds; auto-following characters; dialog system; screen resolutions; and numerous others. AGS deals with these well in an intuitive way, allowing the prospective game designer to focus on the actual game instead. This is a strong point; I wouldn't expect any adventure engine to become popular if it doesn't do this.

Something I'd like to change is the editor interface. It requires too many clicks to perform basic tasks, which is mostly because it combines everything in a single tree view, and because tab handling isn't smooth. Also, it is lacking in keyboard shortcuts, including hotkeys in its menus. I believe in the design pattern that everything should have an alt- or control- keyboard shortcut and a clear tab order; multiple control methods (i.e. keyboard OR mouse OR dropdown menu) are good.

Something I'd like to change in the engine is error handling; there are many issues that currently cause AGS to abort, that instead should simply be written to the log since they're non-fatal. Also when AGS does abort, its error messages usually lack information you need to fix the problem. For instance, trying to animate a non-existent loop could be dealt with by logging it and having the character retain its current loop; but AGS halts and shows an error message that doesn't tell you which character or which loop it was. I don't mean this as a specific bug report; it is the general philosophy of "aborting on non-fatal errors" that I think should be different.

dactylopus

Quote from: Radiant on Fri 12/01/2018 09:15:08
Something I'd like to change in the engine is error handling; there are many issues that currently cause AGS to abort, that instead should simply be written to the log since they're non-fatal. Also when AGS does abort, its error messages usually lack information you need to fix the problem. For instance, trying to animate a non-existent loop could be dealt with by logging it and having the character retain its current loop; but AGS halts and shows an error message that doesn't tell you which character or which loop it was. I don't mean this as a specific bug report; it is the general philosophy of "aborting on non-fatal errors" that I think should be different.
As a beginner, something I like about aborting on non-fatal errors is that it immediately shows me that there is a problem.  I can't proceed until I have fixed this problem.  So maybe "Abort on non-fatal errors" could be a Yes / No choice.

Crimson Wizard

It would also be interesting to know if any of you have opinion on making script language more customizable.
Something similar to what Monsieur OUXX have mentioned in another thread -

Quote from: Monsieur OUXX on Tue 09/01/2018 14:00:59
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.
- event hooks! event hooks everywhere! E.g. OnNewItemInInventory

Radiant

Quote from: Crimson Wizard on Fri 12/01/2018 15:56:25
It would also be interesting to know if any of you have opinion on making script language more customizable.
Something similar to what Monsieur OUXX have mentioned in another thread -
I don't think this is necessary, you can usually customize things with the low-level functions that already exist; e.g. RawDrawImageTransparent() can cover for fading, and OnNewItem already has a hook in the form of on_event(eEventAddInventory).

I suggest that making the code more "theoretically pure" will detract from its usability to anyone who's not a trained software engineer. Which, let's face it, adventure game designers shouldn't have to be.

Crimson Wizard

#7
Quote from: Radiant on Fri 12/01/2018 16:14:50I don't think this is necessary, you can usually customize things with the low-level functions that already exist; e.g. RawDrawImageTransparent() can cover for fading,
You can indeed make your fade-out effect with raw drawing, but what you cannot do is integrate your code into same sequence as built-in transitions. That is - your fade-in won't be automatically called between "Before fade-in" and "After fade-in" events, but in "After fade-in" stage (probably even in repeatedly_execute). You cannot use functions like SetNextScreenTransition with your custom transition, and so on. In the end there will be two duplicating systems: built-in transition and your custom transition.


Quote from: Radiant on Fri 12/01/2018 16:14:50
I suggest that making the code more "theoretically pure" will detract from its usability to anyone who's not a trained software engineer. Which, let's face it, adventure game designers shouldn't have to be.

But this is not what is suggested, what is suggested is to -
1) have engine API multi-leveled, where you may code with low-level API if you need totally custom behavior, or with high-level API if you want to stay inside the adventure genre presets.
2) have parts of engine replaceable, where people who are okay with default behavior will be using it, and those who want custom behavior will be able to easily connect it into the system. For example, make a way for engine to run your own "room transition" callback function, while providing number of default ones.

morganw

Quote from: Gurok on Fri 12/01/2018 06:06:05
AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.
It would be good if you could optionally decide which scripts are on a fixed frame rate and which will wait for vsync (perhaps just capped at 60 FPS). So the viewport and mouse cursor could be smoothly moved, but game speed is still configurable. i.e. separate the game events from the engine events, so when using the RenderAtScreenResolution setting you can get the retro look with smooth scrolling and interface. Doing this is Unity is pretty difficult, normally you end up with spritesheet jitter and pixels changing in width as they scroll, I think you had to point the camera at a render texture to work around that which didn't use to be available in the free version.

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.

Also, directory based project structure (sprite is just an image file) with YAML datafiles instead of XML (so people can read it with just their eyes). I think just letting the compiler pack the sprites would be a big improvement for a lot of people. As an example:
Quote from: http://thebrotherhoodgames.com/blog/2013/10/visionaire-engine-powering-stasis/The engine is extremely artist friendly, with the ability to slide easily into a production line. All images are read from external files, so updating graphics is as easy as copying files in Windows Explorer. Simply replace the old frames in the directory, and they are automatically updated in the game.

AnasAbdin

I kept writing and erasing the line I want to begin this reply! If I didn't know what SCI is, I would have thought all Sierra's games were made using AGS along with Lucas Arts games. AGS is the best way to create an adventure game there's no discussion about this. And when those stunning AGS arcade games pop up every once in a while in the Complete Games forum, one knows that AGS has no limits.

However, there's something that always gave me hard times when using AGS. I don't know the technical word for this, I'll try to describe it instead. (btw, there may be a direct way to do this but I didn't discover it yet in AGS).

I have an issue with the Walk/Move functions and the Non-Blocking option as well. Why isn't there an "easy" way to move an object in a specific trajectory as a non-blocking function? Let's say I want to make an object to orbit another one in a non blocking manner. I couldn't find a direct way to do so. Now things like this come in the way when deciding to create puzzles. Why do I have to use a plugin to do a simple movement like this?

I also think the ability to add and benefit from libraries such as OpenGL and so on, would give AGS a great push towards the top lists of games engines.

tzachs

Quote from: Gurok on Fri 12/01/2018 06:06:05
AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.
I made the same "crime" at the beginning with my engine, until somebody on the chat enlightened me on this feature in AGS. It wasn't due to laziness, it was due to artistic blindness, I didn't notice the difference myself.

Quote from: morganw on Fri 12/01/2018 19:22:44
Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.
Can you expand on this? I'm not sure I completely got what you're aiming for here. Can you also explain which use-cases are you hoping to solve (or make better) with this?

Jack

Quote from: AnasAbdin on Fri 12/01/2018 19:48:37
I have an issue with the Walk/Move functions and the Non-Blocking option as well. Why isn't there an "easy" way to move an object in a specific trajectory as a non-blocking function? Let's say I want to make an object to orbit another one in a non blocking manner. I couldn't find a direct way to do so. Now things like this come in the way when deciding to create puzzles. Why do I have to use a plugin to do a simple movement like this?
Currently this is done in scripting and works well, but you have to do it all in scripting. You would specify exactly where the object is for each frame of the game.

To make this easier, I think this is what the tween plugin does, haven't used it myself though.

This reminds me of one thing which is conspicuously missing from AGS though, which is scaling for objects (without having to use DS), like characters have.

morganw

Quote from: tzachs on Fri 12/01/2018 20:35:38
Quote from: morganw on Fri 12/01/2018 19:22:44
Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.
Can you expand on this? I'm not sure I completely got what you're aiming for here. Can you also explain which use-cases are you hoping to solve (or make better) with this?
As an example, if you had three objects which you need to check the state for some kind of puzzle, rather than just put them in a room and store the state in the room script, you have a base level object (one that would be extended with components to become the other type of game objects) and encapsulate the object state and functions in there. The idea being, if you didn't want to use it you don't have (just use the pre-extended objects), but you could take an empty object and manually assign the components (bitmap, events hooks, scripts, etc). So the parent object might have a function to validate the position of its children which is used as the puzzle logic, but may also have a bitmap (perhaps the three objects are on a tray) or blit to its own surface (perhaps it is a magic tray), and also provide routing for events to propagate (can fire events into its children, pass-on events from its parent, or claim events). When the puzzle is solved, just deactivate the parent to stop all scripts and events on the children, so I guess I'm suggesting it as an option to prevent having lots of booleans and if statements in a room script or global script (but you can still do it that way if you want as that is just one parent and one child).

morganw

For things I really like (and for contrast): Game.DoOnceOnly

If you are defining global state, you may as well describe what you are doing it for at the same time. :)

CrashPL

I love the AGS engine, I really do. I've been lurking around this forum since 2010, reading the beginner/advanced technical questions/scripting manual, and trying my best doing some crappy demos hopefully nobody will ever see, before finally tackling the my biggest project to date in 2014. I love the power of AGScript, the clean and effective IDE, and the fact a whole lot of community suggestions are already implemented in AGS (switch-case, a better resolution management in winsetup etc.)

During the 3,5+ years of ZA development, I've noticed some things I personally would improve in AGS, to make my work a little bit easier. These are not fatal flaws by any means, as I can go around them, easy or complex way, although they'd surely make a difference in my development time. If some of them can be resolved by using a custom plugin/module (or I just wasn't aware a solution already exists in AGS), then please ignore the point and excuse my ill-informed self. ;)

- quick jump to other AGS constructs, than sprites/method and global variables definitions - currently if I right-click on a number/method/variable in AGS, I can choose to quickly jump to the sprite page and view the sprite with the given ID or jump directly the method/global variable definiton. It would be great if I could also use it to quickly jump to the appropriate preview, by right-clicking on a room/view number (inside an appropriate method) or InventoryItem/Character name (currently it only displays a prompt, explaining the internally defined variable)!

- ability to zoom-in/out on the sprite page - ZA is quite a sprite heavy game, and sometimes I'm not really sure if I'm using the right sprite for the view/object. The sprite page thumbnail is quite small, and I'm unable to see the details, which would tell me what kind of sprite I'm currently dealing with. It would be nice to have a zoom-in option directly on the sprite page, without having to open the sprite in the external program, just to see the bigger version. ;)

- an additional flag, allowing the video file to play with both game audio and video file audio at the same time - ZA features several FMV cutscenes during the gameplay, which require both the game audio and video file audio to play at the same time. While this is doable in AGS, by exporting the video file audio track, it would be a tad easier if I had the option to do it directly in the PlayVideo method.

- optimize the GUI drawing routines for 32-bit games - GUIs in 32-bit games, especially transparent ones, or featuring some animations, ale slowing the game considerably on lower-end PCs, or in software rendering, even though the game alone is working just fine. Would love to see a bit of optimization in the GUI drawing routine in the near future!

- being able to translate text values of custom properties - Polish translation of ZA would be so much easier to do...

- scaling for objects - just like Jack mentioned

- fix some of the issues that are present in AGS for a long time, but aren't that noticeable - including special Windows key combinations (alt|ctrl+tab for example) locking the Escape key, the runtime engine failing to access the data files, if some non-ascii characters (cyryllic etc.) are in the game's path, strings with space at the end in the tra file not being translated and the font-drawing library issue in Linux ports.

These are the things I've noticed the most. But doesn't change the fact I love working with AGS. ;)

Snarky

Quote from: Crimson Wizard on Fri 12/01/2018 01:10:23
1) What do you like about AGS, and would like to keep if any new creative tool arrives?
2) What do you think should be changed (added, removed, altered)?

Overall I like the AGS way of doing things. It strikes a nice balance between being pretty easy to just pick up and use and being quite powerful. But there are many points that could be improved or streamlined, and many tasks that are way more tedious than they ought to be.

One of the best things is the "make my game" button: By which I mean, there's a very simple and easy-to-find option that will build a ready-to-distribute version of your game, complete with config program and everything. With the Awards Ceremony, I have on several occasions had to patch some bug and distribute a new version of the client in a matter of minutes, and AGS makes that a pretty painless process.

It could be improved further, though: first of all, I never understood why after running the game in debug mode, the exe file disappears from the compiled folder. Really annoying. Secondly, maybe some way to package it as an installer would make life even easier for newbies.

Second, I think the unified IDE that covers both coding and asset management is key. Convenience and "works right out of the box"-ness is what makes AGS such an appealing choice for new users.

On the improvement side, I agree that the way assets are "trapped" in the editor rather than existing on the file system, and the way tools like the compiler can only be called from the editor (so that you can't script automated builds, for example) are major, needless limitations. I also agree with Radiant that that the UI could be improved in many places, and with CrashPL about the graphics UIs specifically (e.g. zooming, which is implemented inconsistently throughout, between sprites, views, characters, rooms...).

I also always found the View system really unintuitive and tedious for working with animations. The way it mixes together different angles of the same animation and different animations is weird, and having the angles hardcoded makes it difficult whenever you want less than 4 different angles (e.g. only left and right animations, or only up and down animations). I think it would be better if a view were only different angles on "the same" animation, and to group related animations together you'd simply place them in a folder. (The main change needed would be the ability to view all the animation loops in a folder in the same animation editor tab.)

The AGS documentation is overall very good: I use the manual all the time from within the editor. Having that and not having to open a browser to look stuff up is really important. The AGS community and all the technical knowledge available on the forums (old threads as well as live advice) is irreplaceable.

There's a lot of room for improvement there as well, particularly in documenting the editor and making a reference section for things that are currently only described in the tutorial/introduction, but the most important thing would be to have an up-to-date version of the manual online; among other things, it would make it easier to help others because you could just refer them to the right place in the manual.

Also having the "IntelliSense" capabilities (tooltip hints for functions, autocomplete) in the code editor is of course really important, though that's probably a baseline expectation these days. I love that you can add tooltip help for new functions etc. using the triple slash comments. (It just occurred to me that it might be cool to extend these contextual hints further to e.g. preview a sprite or an animation just by hovering over the code, but it's not really something I've been missing.)

I actually think the biggest code editor annoyance is that it feels slightly buggy: not very good at picking up updates to your code, search not working reliably, etc. Also on the coding side I think debugging could be improved, particularly to make it easier to inspect the value of variables at different points in the code. And I seem to recall that one of step-over/into is missing, making it more tedious that it ought to be to reach the point in your code you want to check.

More ambitiously, I really like tzachs' idea of being able to edit script from within the game, by e.g. writing dialog as you're playing. (I'm not exactly how his version works, but I was imagining that when you reach some undefined interaction, it'd pop up a little code editing window where you could just type in what would happen.) Live reloading of scripts would probably mean working in an interpreted language, as I understand it.

Staying on the topic of the code editor: having to put all the character/GUI/I-forget-what-else interaction handlers in GlobalScript is fucking idiotic, and I hate it.

With the recent additions of standard constructs like for loops and case statements, AGS Script is a pretty decent scripting language, and well suited for the game logic of a typical adventure game. Maybe a language like Lua or JavaScript (or TypeScript) would be better, but it seems like there are a bunch of drawbacks to any alternative as well.

The two things that would need improvement in my book is first, some easier way to script a non-blocking wait (it's a very common use-case, and one of the most frequent things newbies struggle with), just the way Game.DoOnceOnly() makes it really easy to script something to happen only once. I know it's hard to fit into the way the engine threads work, but maybe a new keyword that would introduce some very limited function pointer capability?

The other things is of course fixing the pointer/struct limitations, presumably by implementing a garbage collector. I've written probably thousands of lines of code that would be instantly redundant with that capability.

cat

What is good in AGS:


  • The community
    This is the friendliest forum on the internet I know and I have met lovely people here, online and also IRL. But related to game development, this is also important:

    • Tech support
      The technical boards are very active. Most stuff I can find already answered in old threads; but when a new question arises, it is immediately answered. Even n00bs are treated nicely when they ask the most basic questions and are met with astonishing patience.
    • Free modules
      There is a vast amount of freely available modules, plugins and templates. Many games use at least some of them.
    • Game promotion
      With the games database and the completed games announcement and the game in production boards, there is a place to promote one's games.
      Because of MAGS there is a constant output of newly created games.
  • Ease of use
    AGS provides tailored features for creating adventure games. It handles characters, inventory, GUIs, rooms, animation, pathfinding, translations etc. In the room editor, you have a great GUI for walkable areas, walk-behinds, regions, placing objects and whatnot. It also supports other generic features like sound and video. Not much scripting knowledge is required to make a basic game...
  • Scripting
    ...but it can be done, if needed. There is a huge bunch of non-adventure games of any genre that showcase AGS's capabilities in this regard. Sure, the scripting language is limited compared to other languages, but I always managed to code what I wanted to do (even if it was done in a clumsy way due to language limitations).
    Also the rawdraw functions a great addition for advanced coding.

What is not so good in AGS:


  • Binary files
    The room files are binary and even without opening the room editor, whenever I compile the game, git shows the files as modified. It is not possible to merge or undo changes here. Also the hooks for events (e.g. lookat) are stored somewhere there and are missed when renaming a function.
    The same applies for the sprite file. I keep it in source control because the goal is being able to build the game from any given commit. However, the whole file is updated when a single sprite changes. When I update a file on the disk I have to go to the sprite editor as well and reload it there. This is also a hindrance for teamwork, as it is not possible to merge.
  • Save games
    Save games easily break with newer game versions. There is no hook (e.g. onGameRestored) for fixing inconsistencies between versions in code to avoid crashes on load.
  • Platform support
    There is some support but it does not work out of the box and versions for other platforms are lagging behind (e.g. Android)

Ali

Quote from: Gurok on Fri 12/01/2018 06:06:05
AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.

This is bang on, in my view. It's not perfect, but it captures the character movement from 90s adventure games - which (inexplicably) better than character movement in many contemporary 2D adventure games where sprites slide all over the place.

Scripting sequential events is also super-easy. You can write a script which works like a movie script where the game waits for each event to complete before moving on to the next. it sounds simple, but other game engines seem to be designed around things happening simultaneously, based on lots of different inputs. For artists and writers, the AGS way is incredibly helpful.

Theme

2) What do you think should be changed (added, removed, altered)?
I think you could add 3d, doesn't have to be a 3d engine, but some basis for someone who wants to implement maybe opengl functions, shaders and integrate 3d as a plugin or something.
Been able to change the out of the box stuff. They are good for beginners, but advanced users can make their own classes and alter the default.

eri0o

QuoteScripting sequential events is also super-easy. You can write a script which works like a movie script where the game waits for each event to complete before moving on to the next. it sounds simple, but other game engines seem to be designed around things happening simultaneously, based on lots of different inputs.

Damn, I missed this thread when it was written. The above sentence from Ali is my most beloved feature. I love the editor, the intellisense and all, but the way I can just write things in script and they happen in smart order, not everything at the same time, is awesome! Doing this in any other engine is a pain! (callbacks everywhere!!!)

If I could add something, it would be like threads or parallel instances of this queue of events, so things could happen in background and be scripted as easy as blocking functions in normal scripting.

Vince Twelve

I wish the dialog files were stored as separate files in the game folder like rooms and script files.  Right now it's all wrapped up in the .agf file.  This would allow better versioning of dialogs and the writing of custom tools for writing/translating dialogs.  Just a thought I've been having recently.

KyriakosCH

Does the new version have a demo template using the script for typewriter-styled text? As in jrpgs (and rpg maker) :)
Cause that is one cool AGS script, and i think it will get a lot of use if it is included in a template. (nod)
This is the Way - A dark allegory. My Twitter!  My Youtube!

SMF spam blocked by CleanTalk