Suggestions for the next version of AGS

[Lt. Smash]

Suggestion:
Imagine you have a game with about 40 lines of old, not supported code. You want to compile it. It can't compile cause of compiling errors. It just shows the first one. You solve that-> compile the game->error: string no longer supported. etc.etc.

The suggestion is that all compiling errors are listed at once so you can solve them all and compile the game. At the moment you always have to compile to find out that the next line has wrong code.
This suggestion implemented would save lot of time, I think.

[edit]example: you have 25 StrCopy functions and enforce new-style strings. You compile-> 1st StrCopy error. You solve the problem and compile the game. -> 2nd StrCopy error. You solve.......etc. Errors that are caused by these errors can of course only be found after recompiling(after solving the errors).

[naltimari]

The suggestion is that all compiling errors are listed at once so you can solve them all

Depending on the way the parser is implemented (e.g. top-down, bottom-up, recursive), a single error 'cascades' into a lot of subsequent 'errors' which actually dont exist. This happens even in big mainstream compilers, like gcc or bcc (Borland), I mean, they may even report more than one error, but the only one you can 'trust' is the first. It's not that simple, I wrote a parser once...

While we're at it, I came across a parsing engine the other day which is very interesting, named Ch. ImageMagick has a binding for it. The best part I guess is that Ch would be compatible with the current parser (thus not breaking current scripts), since the syntax is also based on C.

Maybe AGS 3.1 could substitute the current parser for Ch?

[subspark]

Hell thats interesting!
Paul.

[Ali]

I haven't seen this mentioned elsewhere. Now that AGS stores the original path of sprites, would it be possible to reload multiple sprites/ sprite folders at the player's request?

This would be particularly useful to me because I am experimenting with pre-rendered 3D sprites and it is very time consuming to have to delete views, delete sprites then reimport sprites and rebuild views when the sprite files have the same names but updated content

I'm sorry if this has already been discussed, or is more complicated to implement than I imagine.

EDIT: Sorry Paul, I did a search but couldn't find it. Still, I'm glad I'm not the only person who would like such a feature.

[subspark]

I haven't seen this mentioned elsewhere.

Hehe. This is something I've already requested a couple of times not so long ago. It's in this thread somewhere I beleive.

Cheers,
Paul.

[monkey0506]

I believe that it was Chris's original intention to implement it this way, hence the tracking of the source-file now. It simply hasn't been implemented yet.

[subspark]

Roger that! Good to know 

Paul.

[naltimari]

I can't say that I would be satisfied with the same method because my artists would end up waiting around for one another to finish committing their changes to the ever evolving 'acprset.spr' where as if the data was external to the editor, single sprites could be upgraded.

I totally agree, acprset.spr being so 'monolithic' is not a very good thing. I dont know how other engines handle sprites, but I imagine there could be a more 'dynamic' way, like you suggested (grabbing sprites from the filesystem instead of stacking them all together in one single file). That would be the first step towards distributing work across many people.

Maybe CJ can add some event to the editor plugin API when AGS is about to save/read sprites, thus the 'sprite monolith' scheme can be customized in some way.

I also think that acprset.spr is quite big, obviously because it is using some 'lossless' method to store all the sprites, but there are situations when some of the sprites certainly can be compressed, especially in higher resolutions that depict 'real' scenes. Hmmm, another plugin idea comes to my mind...

So again to sum up my suggestion, I would really love to see AGS become more compatible with 'diffing' and 'merging' data in a way that feels personal.

My hope is for AGS to have a (ever increasing) flexible API, so people [who are willing to spend the time/money/effort] can customize it to their specific needs, by means of runtime and/or editor 'plugins'.

[subspark]

My hope is for AGS to have a (ever increasing) flexible API, so people [who are willing to spend the time/money/effort] can customize it to their specific needs, by means of runtime and/or editor 'plugins'.

I totally agree. I think this would open up a new class of design opportunities for a developer.

Paul.

[Rui 'Trovatore' Pires]

some of the sprites certainly can be compressed

You mean like the "Compress the sprite file" option in General Settings?

[naltimari]

You mean like the "Compress the sprite file" option in General Settings?

Actually I meant 'lossy' compression, like in JPG. Some sprites can surely afford lossy compression, as long as the engine keeps the original 'non-compressed' file (to avoid 'compression-over-compression' artifacts). This suggestion builds up on the previous one, in which sprites are fetched directly as files from a directory tree.

OTOH, I dont know what type of 'compression' is applied when you choose that option you mentioned, but certainly it's not as good as the compression present in PNG or JPG files, because the sprite cache grows many times larger that the original files.

[subspark]

I think lossy compression is a debatable issue. Here is what I imagine being an optimal approach:

• Sprites are built by Artists and are saved out in an uncompressed or lossless format
  
• Sprites are imported into AGS unchanged
  
• Users control a compression slider for each sprite with an overall sprite index file size measure
  
• Users control an overall compression slider in order to tweak overall project size estimates
  
  I don't know how reasonable AGS would be with decent compression algorithms but I imagine this sort of thing is pretty standard across the board.
  
  Cheers,
  Paul.

[naltimari]

• Users control an overall compression slider in order to tweak overall project size estimates
  

I dont know exactly what you mean, but if you want to use it as a 'target' filesize for the whole project, it would be a little hard to implement, so I would not ask for it...

Also, I find that sliders would be a bit of an overkill, I guess a simple 'quality/compression' field would suffice. Any value other than 100 (for quality) or 0 (for compression) would trigger the compression of the sprite on the next game build.

[subspark]

Also, I find that sliders would be a bit of an overkill

Why? Sliders are simply another way of displaying the measure of a value. It is notably a more user friendly method as well. Sliders don't have to be adjustable by the pixel. It can be adjusted in chunks of 5% and a label displaying the value below or above the slider would be present. Who in the world needs 42.7% compression for example?

but if you want to use it as a 'target' file size for the whole project

Not the whole 'project', but rather the entire sprite image index.
Let me clarify it's purpose:
A user might want to tweak each sprite's compression separately or might find that simply tweaking the overall compression for every sprite at once is more preferable. It depends on how much time the author wants to spend sifting through hundreds of sprites tweaking individual values. Another reason why a slider would be more appropriate than a text field in which the user is likely required to click on, in order to type in it, and then press enter to lock that value in. I've learned a valuable habit of thinking several steps ahead, particularly with engine design, which is why I chose to suggest it above

Paul.

[Shane 'ProgZmax' Stevens]

Would it be possible to add the object method to the Room class?  I think this would greatly help organization when adjusting object information from the global script and would also make it possible to edit objects in other rooms from a room script. 

IE:

Room[4].object[3].X=5;
Room[2].object[3].SetView(1,2,eRepeat,eNoBlock);

Also, I think it would be great if the compiler would check to see if the object being adjusted exists (this should be possible with the above approach?).

Note:  I'm not saying we should remove the current way objects are used, this way would simply add some more possibilities and better readability since as it is now there's no way of knowing what object call in a globalscript references which room unless you're the person who put it there.

[Rui 'Trovatore' Pires]

I support Prog's suggestion as long as it doesn't remove the ability to call them as we do now. In a global script, it would make things much easier, as well as stop our necessity to first check whether the player is in room X.

[Le Woltaire]

Coordinates:
- Could the division between x and y coordinates be a "," instead of a ";" when setting up the walk to points for hotspots. Coordinates are always typed  "x , y" anywhere and just here it is "x ; y" wich is quite confusing...

- Is it possible to add optional walk to points for objects? It has already been asked. But I ask again.

- Can there be a shortcut or something similar (maybe the middle mouse button) to copy the coordinates of the mouse to the clipboard? It doesn't seem to be possible via right click anymore when I'm editing a walkable area or hotspot.

Organizational:
- Could there be an additional character.asc and inventory.asc script, so that the GlobalScript.asc doesn't get messed up with all kind of character and inventory functions anymore and becomes more economic.
   
- I recognized that there is a folder option for views. Can there be one for characters and rooms as well.
Can there also be a drag and drop function to place existing views / characters / rooms into a folder.
It would make the organization of very large games much easier.

- When setting up the speech color for a character, can there be a pop-up to a color finder?

- When I import multiple sprites in the sprites folder, the imported sprites change their order.

- I still believe the limit of walkable areas walk behinds and regions should be altered to about 40 per room.
There is no reason for the 16 area limit. The argument that people will mess around with areas is not really understandable in my eyes.

- Can the view number be shown in a Tab, like with the rooms in this way: "View 32: Ego". It speeds up scripting.

Testing and previewing:
- It seems that the preview background option has been deleted. Could it be added again and include room objects and hotspots.

- The "jump to room" debug feature should automatically place the player character in a walkable area if there is one, so you can walk around and test the game faster.

- When a game is tested in full-screen mode the room tab gets automatically closed.
  Could it remain opened? It's annoying to reopen the room every time when a test run is done.

- When I preview an animation a large sprite or character gets cropped at a certain height so one can just view half of the animation. Can this be altered to a higher size?

Graphics:
- Alpha channels are shown as gray or white blocks in the sprite manager and preview window. Could their preview include the transparency shadings?

- Alpha channels don't seem to work with GUI buttons, can it be added.

-Whenever I import a singel PNG I get the "Appears to have an alpha channel" Question. You won't believe how often I already clicked "YES" but I never clicked "NO" in my life. Please remove that thing. Can't it be substituted via a tag in the import editor or something?

Sound:
- Is there a possibility to increase the number of channels?

[monkey0506]

Would it be possible to add the object method to the Room class?  I think this would greatly help organization when adjusting object information from the global script and would also make it possible to edit objects in other rooms from a room script. 

IE:

Room[4].object[3].X=5;
Room[2].object[3].SetView(1,2,eRepeat,eNoBlock);

Also, I think it would be great if the compiler would check to see if the object being adjusted exists (this should be possible with the above approach?).

Note:  I'm not saying we should remove the current way objects are used, this way would simply add some more possibilities and better readability since as it is now there's no way of knowing what object call in a globalscript references which room unless you're the person who put it there.

I think one of the biggest problems with this has always been the lack of any type of constant (macro or constant static variable) (i.e., AGS_MAX_ROOMS or Game.RoomCount) which would make the sizing of the array much more abstract. In approaching this it has been mentioned that rooms aren't required to be numbered numerically which could lead to lots of "empty" entries at valid array indices (due to the very nature of an array).

Another problem is of course that AGS has a limit of 300 state-saving rooms but then 1000 total rooms (I believe, IIRC you can't have rooms numbered 1000 or higher, but only 0-999 correct?). So in implementing this array should it only allow access to the state-saving rooms, or all the rooms? Making all 1000 rooms accessible from this array would make the overall array huge.

Also we must consider the fact that one of the benefits of AGS has always been that having objects stored within the rooms means the game doesn't have to track every object in every room throughout the whole game, but only has to keep up with the objects in the current room. On modern computers this might not even make a noticeable impact on gameplay; but it certainly would on older computers.

I'm not against the suggestion, but I think we must consider all the pros and cons and approach this one carefully so as to get the most benefit from it.

[Lt. Smash]

suggestion:
A nice feature would be to change the game language in-game. Maybe Game.Translation=String TranslationName;.
We would not need to use to the WinSetup.exe and it would look more professional to change the language from english to spain in the options menu of a game.

In the editor: Right click on a translation: Edit in default text editor. Or possibility to edit it in the editor itself.

What would also be nice: Game.Windowed=true/false; Game.GraphicsFilter=2xNN,3xNN,Hq2x,Hq3x; Game.ForceLetterboxRes=true/false;
These are things that are implemented in ScummVM and would be nice to have in AGS.

[GarageGothic]

Lt. Smash, I suggested something earlier in this thread, which would make your requests quite easy to implement through a module:

If the savegame compatibility issue [between different graphics resolutions] was solved, and RunAGSGame was made to re-initialize the engine, as monkey_05_06 suggested [...] you could let the player change the graphics [and other] settings from an in-game options menu, write them to acsetup.cfg using File functions, save the game in progress, then restart the entire game using RunAGSGame (whereby the engine would re-initialize using the settings from the .cfg file) and then restore the savegame to resume gameplay.