Suggestions for the next version of AGS

[Lt. Smash]

Here are some suggestions I got using ags 3.0.1beta3:

- a sprite preview window
- proberty window: ability to change the sprite slot number
- import multiple sprites: ability to set transparency (like in "Import new sprite from file")
- export sprite to file: ability to choose bit-depth of the created file (gif, png,...)
- property window and work space should be updated when I single-click an entry in the project tree (ne need to double-click)
    In general I think there shouldn't always popup a new tab when click on smth in the prj tree. Maybe its more handy to make it more the Firefox-way.
- property window: width should be above height (no entries between - I know it is sorted alphabetical but that doesn't suit)
- ability to use normal scripting code in dialogs
- sound and music import
- ability to save rooms(-scripts) also when having compiling errors.
- ability to open translation-files within the editor. Just without syntax highlighting.
- and I think there are some options (property window) which are [outdated] because there is less use for them and they were for people who used the ie-editor. f.e. characters blinking view - I don't see the use for that. It just confuse people. You can easily create a view for a blinking char. Is there really need for an extra option?

Finally one question:  How do I import plugins?

I hope you can realise some of these suggestions

LtSm

EDIT:
- possibiliy to change transparent color of a sprite also when its already imported.
- ability to open more than one window (like having sprite manager and guis opened at once)

When I get more suggestions I will create a new post.

[subspark]

I would really love to see an enhanced file manager that enables the author to create custom data libraries instead of compiling most of the game data into the executable. I imagine the author creating a project tree in windows (a series of personally organized folders and files), and AGS would read the tree and draw game data directly from it using a file browser.

The author would choose a file extension for their data library or libraries and could enable encryption. When the project compiles, AGS copies the files in the windows project tree and bundles them up into a neat data package.

There are two distinct advantages to be had from this idea:

[1] The author could release their game on a digital distribution system like Steam and provide updates to their players that don't require them to redownload the entire game exe. You would essentially diff the data libraries.

[2] The author has more control over how their game data is distributed and can better manage projects where multiple people are involved. An SVN repository could be created, for example, and daily builds could be done with the latest file revisions that are checked in by fellow team members throughout the day.

Heres how I would set up my data package:


I'm not 100% sure that all this could be done with a plugin but I get the feeling that AGS already has the ability to use data from outside of the editor. That said, I would much rather see an official overhaul of the project data system.

Food for thought if nothing else.

Cheers,
Paul.

[Dusk]

[2] The author has more control over how their game data is distributed and can better manage projects where multiple people are involved. An SVN repository could be created, for example, and daily builds could be done with the latest file revisions that are checked in by fellow team members throughout the day.

Hi, just a quick note about this: having problems with Perforce (natively supported by AGS), we SOTE-guys begun using SVN with our project.
I wasn't sure of how it would have been working with big binary files like acsprset.spr - about 180 Mb at the moment - but I decided to try and we're very satisfied: SVN uses binary diffing with non-text files, and performance is much better than expected.
We frequently commit/update using a linux home server on my ADSL connection (max upload 40 Kb) and we're very happy of how it's working.
We try to not mess-up with conflicting updates, but for now we didn't have any problem. And hey, if something will go really bad, we can revert to a previous version

So, while I think that it would be really cool if AGS could get resources directly from a file system directory tree (moving and updating stuff would be easier), I have to say that isn't a critical feature for using a SVN repository (as I was frighten of).

Baaad english today, greetings from Italy

[naltimari]

I would really love to see an enhanced file manager that enables the author to create custom data libraries instead of compiling most of the game data into the executable.

Very interesting ideas, and it's very good to find these kind of concerns in the forum. They reflect the fact that (1) modern games should be (actually, must be) updated after their initial release and (2) games usually aren't made by a single person, at least not anymore.

I'm all for it.

[1] The author could release their game on a digital distribution system like Steam and provide updates to their players that don't require them to redownload the entire game exe. You would essentially diff the data libraries.

Or you would 'diff' the whole package, (game+data), and distribute only the 'patch' for winsetup.exe to 'apply' to the game. I dont know how Steam works, but I assume it's not free, so not everyone would be interested.

[2] The author has more control over how their game data is distributed and can better manage projects where multiple people are involved. An SVN repository could be created, for example, and daily builds could be done with the latest file revisions that are checked in by fellow team members throughout the day.

SVN integration could be implemented as an editor plugin, I guess. It's a very good idea. I was looking for a version control solution the other day, and SVN is coming out on top, along darcs (which I haven't evaluated thoroughly).

Daily builds would be very easy, I guess, since Game.agf is an XML file, and keeps the paths to every single resource in the game (sprites, sounds, fonts, etc). So, implementing daily builds would be a matter of (a) calling the editor with the 'compile' command switch, and (b) letting it update the resources to which Game.agf points to. (a) is already present in AGS, I dont know about (b).

[subspark]

having problems with Perforce (natively supported by AGS),

CJ Fixed the Perforce BUG when I reported that AGS wouldnt launch. It was suggested by Chris that i rename a dll in the perforce directory to 'iforgethename.dll.no'. I can't remember if this workaround had been eliminated by now.

We try to not mess-up with conflicting updates, but for now we didn't have any problem. And hey, if something will go really bad, we can revert to a previous version

I'm glad to hear you've found a system that works for you. 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 'acsprset.spr' where as if the data was external to the editor, single sprites could be upgraded.
With a data management system like the one I have suggested, members could indeed better manage their files. Not to mention the would-be unnecessary trend of having only one guy use the engine and import all of the data.

I am a project lead and an artist so you can imagine the drama of having to essentially halt production for me to go in and make technical changes to the rooms, fonts, GUIs and oversee all the work that has been done. Eeaargh!

My idea of customizing your own data packages (tree/extension) is to make the game more your own and less 'everybody else's'.

Cheers,
Paul.

Edit: Oh and about Steam, I have long-time friends at Popcap Games who started out as a small games development studio much like my own here in Sydney. They chose to contact Valve software about securing the SteamSDK so that they could distribute their games to a larger audience. Adel was the project manager for one of their early games I forget which one now, loaded up their sales tracker each week for about 8 months to find that 'larger audience' was something around the 270,000 customer mark. In less than a year, they pulled in over a million in sales and something like 7 or 8 percent of their gross profit went to Valve for their service. From memory, it was unusually small being a single digit percentage. This is extremely lucrative to me and my team and if I am going to invest decent money into developing our games then this is an avenue I would like to explore. Company growth is a prime objective of Valve's, through their support of a 3rd party market. 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.

[Dusk]

CJ Fixed the Perforce BUG when I reported that AGS wouldnt launch. It was suggested by Chris that i rename a dll in the perforce directory to 'iforgethename.dll.no'. I can't remember if this workaround had been eliminated by now.

Mmm if I remember I had problem with Perforce by itself.. I don't remember about AGS not starting. By the way, I'm not sure of the advantages/disadvanteges of using SVN against something "AGS supported". I mean, to sync binary files you had to do stuff out of AGS if I remember well my test... so, the generic and already experienced SVN/TortoiseSVN method shouldn't be worse that the other one? Or am I missing something BIG? 

I'm glad to hear you've found a system that works for you. 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 'acsprset.spr' where as if the data was external to the editor, single sprites could be upgraded.

Sure, I can understand your frustration about this... I suppose our development is a bit more timely relaxed and, btw, usually only my pal BobaFonts works on the sprites, and 90% of the times I only mess with the scripts, so our collaboration is generally "easily split".

I am a project lead and an artist so you can imagine the drama of having to essentially halt production for me to go in and make technical changes to the rooms, fonts, GUIs and oversee all the work that has been done. Eeaargh!

Yes I sure imagine that
IMHO AGS 3 is by itself a step forward in the right direction (XML, separated script files for rooms...) and I'm sure that CJ will go on in improving the collaborative-work-friendness of AGS (while I can understand that it might not be high-priority).

Good luck with your projects, Paul!

D.

[subspark]

Good luck with your projects, Paul!

Thanks mate! And the same to you all .

Initially, I imagined that all this could be done through a plugin, aside from the encryption of a personalized data library, but AGS can essentially draw things such a sprites from a working directory can it not? Isn't that one of the things raw draw is good for after all?
As for the custom library files, perhaps AGS can be scripted to read data from a zip archive with a renamed extension?

What is the scope of AGS and it's reading and writing of files on disk? Am I dreaming or can some of this stuff already be achieved without the official support of a new feature?

Cheers,
Paul.

[monkey0506]

SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

I believe the reasoning behind this is that walkable areas/regions are governed by a 16-color bitmap, which is also the reason why we can't have overlapping areas. It's been suggested many times that this behavior be changed, but it's not something that would be a "quick 'n' easy 'fix'".

- export sprite to file: ability to choose bit-depth of the created file (gif, png,...)

I'd actually like to voice my support for this suggestion because IIRC even if I'm running an 8-bit game, files exported are still at either 24- or 32-bit. Best-case scenario here (IMO) would be to allow exporting to 8-, 16-, or 32-bit with the default (selected) option being the current game color-depth.

- property window and work space should be updated when I single-click an entry in the project tree (ne need to double-click)
    In general I think there shouldn't always popup a new tab when click on smth in the prj tree. Maybe its more handy to make it more the Firefox-way.

The decision to make everything open in new tabs was intentional and I've actually come to prefer it this way. One possibility might be an 'Open in current tab' option from the right-click menu to stop everything opening in new tabs?

- property window: width should be above height (no entries between - I know it is sorted alphabetical but that doesn't suit)

As you've said, everything is sorted alphabetically. It's perhaps not the most logically intuitive ordering, but I'd say better for the editor to remain consistent in this behavior throughout. I'd much rather every property window be sorted alphabetically than each one being sorted by some other, altogether more arbitrary scheme.

- ability to use normal scripting code in dialogs

I'm not sure CJ is planning on a dialog revamp for the 3.0.1 release, but he's been promising one for a while, so I imagine it won't be too much longer before this sees an update as well.

- sound and music import

I can appreciate the desire to be able to "manage" your audio files from within the editor as we can with everything else, but I wouldn't say it's too high a priority. Especially with the extremely promising Audio Manager plugin that smiley has so graciously provided us with.

- ability to save rooms(-scripts) also when having compiling errors.

The 'Save room' option doesn't work if there are compile errors? AFAIK you should be able to save the game even in instances where it won't compile properly.

- and I think there are some options (property window) which are [outdated] because there is less use for them and they were for people who used the ie-editor. f.e. characters blinking view - I don't see the use for that. It just confuse people. You can easily create a view for a blinking char. Is there really need for an extra option?

Making characters blink periodically is an extremely common option. Having the view automatically linked in and run is really just a nicety. I mean, do we really need an Idle view?

- possibiliy to change transparent color of a sprite also when its already imported.

This would require the sprite to be reimported anyway, so I don't think there would be great benefit. Especially if the source file had moved, been renamed, deleted, etc. it could cause problems.

- ability to open more than one window (like having sprite manager and guis opened at once)

Erm...isn't this the reason for tabs?

Cheers,

monkey

[subspark]

Thanks Monkey. I was hoping somebody could reply before I took over the thread with posts.
Lt. Smash, I agree with monkey in every case and I think its best that the program behavior your questioning remains untouched.
We like those features the way they are. Thats not to say however that other things can't be improved or redesigned.

What does anyone else think?

Cheers,
Paul.

[Ghost]

SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

I totally second that- I had quite a hard time of hit-and-miss sifting through colours now that pcx is no longer supported. A colour picker would greatly add to the comfort.

[Lt. Smash]

- ability to save rooms(-scripts) also when having compiling errors.

The 'Save room' option doesn't work if there are compile errors? AFAIK you should be able to save the game even in instances where it won't compile properly.

I can save the whole game. But when I create a new room and want to save it or when I try to compile the game the error message appears. It's the same as here sadistyk and rui have.
I don't know what the problem is. Tell me please if you know.
I imported some guis and the global script from another game.
I think in the error message should be written where the problem is and how it can be solved.

[DoorKnobHandle]

SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

I totally second that- I had quite a hard time of hit-and-miss sifting through colours now that pcx is no longer supported. A colour picker would greatly add to the comfort.

If walkable areas could be created from DrawingSurfaces/DynamicSprites by code, then the color-picker would already be implemented. That's what I think is the best way to do this, although it's not high-priority to me.

[subspark]

Are you suggesting we code in our walkable areas? I'm not a programmer and setting up rooms is usually, at least for our team, the artist's space. I wouldn't want the programmers treading on the artist's toes or vice versa. This is poor workflow and bad principle.

If we are to be awarded with additional walkable areas, then I believe the artists should also be able to create them.

Cheers,
Paul.

[DoorKnobHandle]

Huh? What I'm saying is...

(1) Walkable areas (say, up to 32) can still be implemented the same way they are now...
(2) Programmers can access these areas in script (via accessing a DynamicSprite/DrawingSurface) and use that to change them in all ways...
(3) Programmers could also add new walkable areas, but they wouldn't have to use raw geometry functions (DrawLine, DrawRect or similar), they could load an image from the hard-drive or from the AGS sprite manager (via the sprite-slot) and use that one as a new area...

That's what I was thinking... Anyways, I wouldn't need this stuff, three walkable-areas were always enough for everything I did.

[naltimari]

(1) Walkable areas (say, up to 32) can still be implemented the same way they are now...
(2) Programmers can access these areas in script (via accessing a DynamicSprite/DrawingSurface) and use that to change them in all ways...
(3) Programmers could also add new walkable areas, but they wouldn't have to use raw geometry functions (DrawLine, DrawRect or similar), they could load an image from the hard-drive or from the AGS sprite manager (via the sprite-slot) and use that one as a new area...

I agree with these suggestions. I think programmers must always have 'backdoors' for anything that can be done 'interactively' in the editor. This way, missing functionality can always be implemented by someone as an editor plugin.

Additionally, I would like GetWalkableAreaAt() to use Room coordinates, not Screen coordinates, as it is right now. If someone can point me to a hack that shows if a point is inside an off-screen walkable area, I would like to know (right now I'm using regions).

[GarageGothic]

Additionally, I would like GetWalkableAreaAt() to use Room coordinates, not Screen coordinates, as it is right now. If someone can point me to a hack that shows if a point is inside an off-screen walkable area, I would like to know (right now I'm using regions).

Can't you use GetViewportX() and GetViewportY() as offsets? If GetWalkableAreaAt() doesn''t work at all outside the displayed screen area, you could alternately SetViewport to the area in question, do your check and then ReleaseViewport, all within the same game loop so the player wouldn't see it.

Edit: And two three suggestion for CJ (sorry for being so demanding):

1) Any chance that the slight offset of labels using antialiased fonts as compared to non-antialiased fonts could be fixed now that DrawingSurface supports hi-res coordinates? I remember reading that anti-aliased fonts were rendered as DynamicSprites internally in the engine.

2) Using DrawingSurface, I developed my own method of rendering outlined TrueType fonts to display nicer looking text overlays. Basically I'm drawing the text 8 times non-antialiased at 1 pixel offsets for the outline and then drawing the interior text anti-aliased. Any chance that this could be implemented in the engine? While it's OK to do for speech, it's a bit of a pain to keep DynamicSprites for every single text item on a GUI. See screenshot below for comparison with AGS' own font rendering:


Above: Custom rendering of text as graphical overlay.
Below: Text on GUI label. Note especially the 'a' and the 's' as less readable.

3) Now that we have DrawingSurface.GetPixel, I would find it very useful to also have a reverse GetColorFromRGB function, such as Game.GetRFromColor, Game.GetGFromColor and Game.GetBFromColor. Edit: After posting this, I worked out how to calculate these values using the (2048, 64, 1) ratios, and after lots of testing I got it right. Still I wonder if an engine-internal function wouldn't be faster? If that's not the case, never mind me.

[subspark]

That's what I was thinking...

Thanks for the clarification, Dkh. I couldn't really pinpoint what you were suggesting in your first post, sorry.

I openly agree with both of you by the way, as long as the artist has equal control over walkable areas and regions. After all, it is indeed the artist that designs the backgrounds in which these areas fit. I definitely think a more programmer-friendly way of creating walkable areas, other than drawing them, is a welcome idea.  8)

Cheers,
Paul.

Edit: I like the way that font is presented GarageGothic. The one at the top feels very nice!

[Charity]

I too would like to voice support for the ability to access walkableareas/regions/walkbehinds/etc. from the script.

If DrawingSurface controlled areas/regions, would we be able to create them from a predrawn sprite (similar to how masks work in the editor)?

Edit: How did I miss that?

[Shane 'ProgZmax' Stevens]

Next to the SpeechColor property in the editor it would be nice to have a little filled square with the color represented by the speech color number so you can easily remember what color it is you selected.

[DoorKnobHandle]

I too would like to voice support for the ability to access walkableareas/regions/walkbehinds/etc. from the script.

If DrawingSurface controlled areas/regions, would we be able to create them from a predrawn sprite (similar to how masks work in the editor)?

(3) Programmers could also add new walkable areas, but they wouldn't have to use raw geometry functions (DrawLine, DrawRect or similar), they could load an image from the hard-drive or from the AGS sprite manager (via the sprite-slot) and use that one as a new area...