List of suggestions and possibly some minor problems

[frogking]

About a month ago I created my first game using AGS for the October MAGS competition and I scribbled some barely readable notes whenever I encountered something which I found confusing or which didn't work as I expected. I thought feedback like this can be helpful for developers even if some of the issues may already have a solution I don't know about. Don't treat it as a list of complaints, I think AGS is a cool product I used AGS 3.1.2.


Development Environment

o The new game wizard should provide a browse button to
  select the target directory for the new game. It might also
  be useful to direct the user to the "General Settings" page
  after creating the game.

o It should be possible to reopen a previously edited game
  from the file menu (File > Recent > ... ?) similar to the
  way you can do on AGS startup. Also, creating a new game
  should be possible from the File menu for completeness.

o It would be nice to be able to toggle break points just by
  left clicking in the gray area between the line number and
  the beginning of the line.

o People often seem to accidentally release debug versions at
  least for quick MAGS games. Actually, "debug mode" is more a
  build setting than an actual game setting. Maybe there could
  be commands like "Build Debug Version" and "Build Release
  Version" in the menu instead which would output to different
  subdirectories.

o It would be nice to be able to force-edit script files while
  testing the game (at your own risk, knowing that the debugger
  may no longer show the correct line numbers). This allows
  to fix small things like typos in message without having
  to write them on a list or abort testing.


Scripting Language

o A ternary operator would be nice, but is of course syntactic sugar.

o Calling a global function from a dialog script did not seem to
  work for me (but I may have been doing something wrong).

o I had the impression that the global script does not import
  the global header (so within the global script a function name
  is only known if it occurs at an earlier time in the script).


Event Handling

o When compiling the game, there should be an error if an
  event handler has a function name set which does not exist,
  just as for functions called in code. Currently this seems to
  needlessly crash at runtime.

o It would be convenient if the InventoryItem had an event
 
    UseInvSymmetric(InventoryItem* otherItem)

  If an item is used on another, this would always be called for both items.
  So you only need to implement one for combining two objects.

o Also, I fell into the trap of having no reactions for some interactions
  although I implemented unhandled_event. This of course happens if you do
  handle an event but then have some condition inside the event handler
  for this interaction to have the desired effect. I solved this by
  adding code like "else {unhandled_event(5,1);}" but it is a bit
  cryptic and the event type is actually already known by the
  engine. Maybe a built-in function "treat_as_unhandled_event()"
  could be added.

o Also, regarding unhandled events, it might be more forgiving
  for the player to give the negative response immediately instead
  of first walking up to the hotspot as if something was happening.
  Maybe this could be a game option under "Character Movement":

    "Do not walk to hotspot for unhandled events"


Sprite Handling

o It would be nice to have a "Reimport Sprite(s)" command which
  simply reloaded the selected sprites from the filename stored in
  the SourceFile property. This allows to edit multiple sprites
  with an external editor and then updating them in AGS without
  having to browse to each (in my case I was generating *lots* of
  frames for animations from a 3D source and I found it to be less
  painful to simply delete the old sprites and recreate the
  animation loops than try to replace the sprites from file).

o When importing a sprite with an alpha channel, you first get
  a message box asking you whether to use the alpha channel. Then
  the normal sprite import dialog opens which includes the normal
  transparency options. This is a bit confusing for the user. I
  would recommend to include "Alpha Channel" as an option in
  the "transparent colour" combobox and select it as default if
  the imported image has an alpha channel. This would make it
  more clear what happens and it saves a click too.

o A warning might be displayed within the dialog if the imported
  image has an alpha channel but the game is not configured to be
  32-bit color.

o Furthermore, the alpha channel did not seem to work for
  inventory items within the inventory window. Pixels with partial
  transparancy were tinted with black instead of the actual
  background color. So I had to use a black inventory window


Room editor

o The "Show this room's" combo box in the room editor and the
  object selection combo box in the property window are closely
  coupled but very distant on the screen. In particular, it is
  a bit confusing if you come from scripting just to add a few
  event handlers to some objects, because the objects don't
  appear in the property box unless you also select the
  correct region type on the other side of the screen.

  Maybe the following functionality would be helpful:

   In the property window, add a check box

     "Filter by currently displayed region type"

   If this is disabled, the combo box could show all
   objects. If an object is selected which has a different
   type from the current display settings, automatically
   change the display to the type of the new object.

o Clearing areas (drawing with right mouse button) seems to affect
  all regions while drawing only affects the currently selected. This
  is somewhat counter-intuitive. Also, if this is desired for some
  reason, there should at least be an easy way to completely reset
  or clear the current region without affecting other regions.
 
o A brush size / line thickness for freehand drawing of regions
  would be nice. Sometimes 1 pixel is a bit restrictive.


GUI editor

o This could do with a "grid" for placing components or at least a small
  delay after a click before it can be moved. I routinely moved GUI elements
  by accident for 1 pixel when I just wanted to select them.


Music / Sound

o If you delete the last piece of music, the old music.vox
  should be deleted when compiling. Currently it sticks around.

o It would be nice to give sounds names instead of numbers.


Site

o I didn't find the documentation for [ hide ] [ /hide ] in the forum documentation
  where the other tags are documented.



And congratulations for reading this up to the end

[Crimson Wizard]

I second following:

o The new game wizard should provide a browse button to
 select the target directory for the new game. It might also
 be useful to direct the user to the "General Settings" page
 after creating the game.

o It should be possible to reopen a previously edited game
 from the file menu (File > Recent > ... ?) similar to the
 way you can do on AGS startup. Also, creating a new game
 should be possible from the File menu for completeness.

...

o It would be nice to be able to force-edit script files while
 testing the game (at your own risk, knowing that the debugger
 may no longer show the correct line numbers). This allows
 to fix small things like typos in message without having
 to write them on a list or abort testing.

...

o It would be convenient if the InventoryItem had an event
 
   UseInvSymmetric(InventoryItem* otherItem)

...

o It would be nice to have a "Reimport Sprite(s)" command which
 simply reloaded the selected sprites from the filename stored in
 the SourceFile property. This allows to edit multiple sprites
 with an external editor and then updating them in AGS without
 having to browse to each (in my case I was generating *lots* of
 frames for animations from a 3D source and I found it to be less
 painful to simply delete the old sprites and recreate the
 animation loops than try to replace the sprites from file).

o Clearing areas (drawing with right mouse button) seems to affect
 all regions while drawing only affects the currently selected. This
 is somewhat counter-intuitive. Also, if this is desired for some
 reason, there should at least be an easy way to completely reset
 or clear the current region without affecting other regions.

This is already implemented in AGS 3.2 RC2:

o It would be nice to give sounds names instead of numbers.

[Calin Leafshade]

they all seem like pretty reasonable requests and i support the vast majority of them

[Divon]

"Sprite Handling

o It would be nice to have a "Reimport Sprite(s)" command which
  simply reloaded the selected sprites from the filename stored in
  the SourceFile property. This allows to edit multiple sprites
  with an external editor and then updating them in AGS without
  having to browse to each (in my case I was generating *lots* of
  frames for animations from a 3D source and I found it to be less
  painful to simply delete the old sprites and recreate the
  animation loops than try to replace the sprites from file)."


^^^^
I agree with this as emphatically as humanly possible.

[Ali]

"Sprite Handling

o It would be nice to have a "Reimport Sprite(s)" command which
  simply reloaded the selected sprites from the filename stored in
  the SourceFile property. This allows to edit multiple sprites
  with an external editor and then updating them in AGS without
  having to browse to each (in my case I was generating *lots* of
  frames for animations from a 3D source and I found it to be less
  painful to simply delete the old sprites and recreate the
  animation loops than try to replace the sprites from file)."


^^^^
I agree with this as emphatically as humanly possible.

Thirded equally emphatically!

This has been asked for in the past, but it would be SO useful for people rendering sprites in 3D and vector based software... which more people might do if this was supported!

Now that AGS shows the file path of each sprite, perhaps it wouldn't be too difficult to implement?

[monkey0506]

o The new game wizard should provide a browse button to
  select the target directory for the new game. It might also
  be useful to direct the user to the "General Settings" page
  after creating the game.

o It should be possible to reopen a previously edited game
  from the file menu (File > Recent > ... ?) similar to the
  way you can do on AGS startup. Also, creating a new game
  should be possible from the File menu for completeness.

o It would be nice to be able to toggle break points just by
  left clicking in the gray area between the line number and
  the beginning of the line.

o People often seem to accidentally release debug versions at
  least for quick MAGS games. Actually, "debug mode" is more a
  build setting than an actual game setting. Maybe there could
  be commands like "Build Debug Version" and "Build Release
  Version" in the menu instead which would output to different
  subdirectories.

o Also, I fell into the trap of having no reactions for some interactions
  although I implemented unhandled_event. This of course happens if you do
  handle an event but then have some condition inside the event handler
  for this interaction to have the desired effect. I solved this by
  adding code like "else {unhandled_event(5,1);}" but it is a bit
  cryptic and the event type is actually already known by the
  engine. Maybe a built-in function "treat_as_unhandled_event()"
  could be added.

o Also, regarding unhandled events, it might be more forgiving
  for the player to give the negative response immediately instead
  of first walking up to the hotspot as if something was happening.
  Maybe this could be a game option under "Character Movement":

    "Do not walk to hotspot for unhandled events"

o Furthermore, the alpha channel did not seem to work for
  inventory items within the inventory window. Pixels with partial
  transparancy were tinted with black instead of the actual
  background color. So I had to use a black inventory window

o A brush size / line thickness for freehand drawing of regions
  would be nice. Sometimes 1 pixel is a bit restrictive.

o If you delete the last piece of music, the old music.vox
  should be deleted when compiling. Currently it sticks around.

I can appreciate and support these.

o It would be nice to be able to force-edit script files while
  testing the game (at your own risk, knowing that the debugger
  may no longer show the correct line numbers). This allows
  to fix small things like typos in message without having
  to write them on a list or abort testing.

I definitely understand the benefit of being able to do that, but it could also have a heavy penalty. I can quite easily see people misusing this ability and causing drastically negative effects. Would be nice, but would have to be handled very carefully I think.

o A ternary operator would be nice, but is of course syntactic sugar.

And it would save people complaining so much about how overly complicated the if-else clause is. This would be great actually.

o Calling a global function from a dialog script did not seem to
  work for me (but I may have been doing something wrong).

This does work, but in order for you to be able to call a global function from a dialog script, the function has to be imported, and you have to make sure to use "normal" scripting in the dialog script:

Code: ags

// script header (*.ash)
import function some_func();

// script file (*.asc)
function some_func() {
  // ...
}

// dialog script
  some_func(); // this line MUST be preceded by at least one whitespace character

o I had the impression that the global script does not import
  the global header (so within the global script a function name
  is only known if it occurs at an earlier time in the script).

I'm sorry, what? AGS does not allow functions to be called after only the declaration like C++, they must be defined before they can be called. So just because you've imported the function in a script header doesn't mean you can call it in any subsequent script. It can't be used until it's defined. However, the global header is included in the global script.

For example, the function declarations (imports) give us the ability to define optional parameters (for integer and enumerated types; pointer types may also in this special case substitute only the value of 0 in place of null; float may not have optional parameters; optional parameter values must be literal and not based around a variable value) (see the manual entry on function).

Which actually does contain some misinformation on the actual usage of optional parameters, but it is correct in displaying the only supported usage of optional parameters.

So if you define an optional parameter as part of an import in a script header (including the global header) this value will apply to all subsequent scripts (including the global script).

o When compiling the game, there should be an error if an
  event handler has a function name set which does not exist,
  just as for functions called in code. Currently this seems to
  needlessly crash at runtime.

By this same logic there should be a compile-time crash for any functions which have an import defined, are never called, and are never defined. Obviously these event handlers are called internally so even if they're not defined there may not be (currently) a flag thrown for an invalid function call. I support the logic of it, but I'm not sure it's presently feasible. Might be quite a task for CJ to implement this.

o It would be convenient if the InventoryItem had an event
 
    UseInvSymmetric(InventoryItem* otherItem)

  If an item is used on another, this would always be called for both items.
  So you only need to implement one for combining two objects.

This is exactly the same as the existing iItem_UseInv functions only that it takes an InventoryItem parameter directly. The "normal" method of usage is just to check player.ActiveInventory. Even given your implementation though I don't see how this would prevent the need for duplication of code/logic.

In my recent game I did something like this though, which I think is what you're wanting to achieve:

Code: ags

void InventoryCombination(InventoryItem *itemOne, InventoryItem *itemTwo) {
  // combines inventory items
  if ((itemOne == null) || (itemTwo == null)) return;
  if (itemTwo.ID < itemOne.ID) {
    // swaps the inventory items so the one with the lower ID is always itemOne
    // this prevents code duplication and additional conditionals
    InventoryItem *item = itemOne;
    itemOne = itemTwo;
    itemTwo = item;
  }
  if (itemOne == iSomeItem) {
    if (itemTwo == iAnotherItem) { // works regardless of the order the parameters were given in
      player.LoseInventory(iSomeItem);
      player.LoseInventory(iAnotherItem);
      player.AddInventory(iThirdItem);
    }
  }
}

But I appreciate some type of built in functionality to the same end would be convenient.

o It would be nice to have a "Reimport Sprite(s)" command which
  simply reloaded the selected sprites from the filename stored in
  the SourceFile property. This allows to edit multiple sprites
  with an external editor and then updating them in AGS without
  having to browse to each (in my case I was generating *lots* of
  frames for animations from a 3D source and I found it to be less
  painful to simply delete the old sprites and recreate the
  animation loops than try to replace the sprites from file).

I thought this was already an option. I thought that was the purpose of storing the source location...but yes. This.

o When importing a sprite with an alpha channel, you first get
  a message box asking you whether to use the alpha channel. Then
  the normal sprite import dialog opens which includes the normal
  transparency options. This is a bit confusing for the user. I
  would recommend to include "Alpha Channel" as an option in
  the "transparent colour" combobox and select it as default if
  the imported image has an alpha channel. This would make it
  more clear what happens and it saves a click too.

There are two options that perform this function. "Leave as is" and "No transparency". Most likely if you're using an alpha channel you're going to use "No transparency". The name of the option itself might be confusing, but there's a calltip-esque prompt that tells you what it does.

o A warning might be displayed within the dialog if the imported
  image has an alpha channel but the game is not configured to be
  32-bit color.

I do get an error (at least in an 8-bit game):

---------------------------
Adventure Game Studio
---------------------------
There was an error importing the file. The error message was: 'You cannot import a hi-colour or true-colour image into a 256-colour game.'. Please try again
---------------------------
OK   
---------------------------

o The "Show this room's" combo box in the room editor and the
  object selection combo box in the property window are closely
  coupled but very distant on the screen. In particular, it is
  a bit confusing if you come from scripting just to add a few
  event handlers to some objects, because the objects don't
  appear in the property box unless you also select the
  correct region type on the other side of the screen.

  Maybe the following functionality would be helpful:

   In the property window, add a check box

     "Filter by currently displayed region type"

   If this is disabled, the combo box could show all
   objects. If an object is selected which has a different
   type from the current display settings, automatically
   change the display to the type of the new object.

I don't see how this would work. A lot of times objects, hotspots, regions, and walkable areas are all right on top of each other. How could you filter this simply by display when they'd all be hiding each other? Maybe this would be easier if showing the room's "Nothing" could populate the properties drop-down with everything? But then it would be very cluttered with all the hotspots, walkable areas, and regions in there. The way it is makes it much more organized.

o Clearing areas (drawing with right mouse button) seems to affect
  all regions while drawing only affects the currently selected. This
  is somewhat counter-intuitive. Also, if this is desired for some
  reason, there should at least be an easy way to completely reset
  or clear the current region without affecting other regions.

Right-clicking while drawing areas uses the "eraser" which really just draws hotspot 0. This is the same as in MS Paint where right-clicking draws the background color. I would expect it to do this. And if you want a way to clear the current region just use the fill tool instead of line tools. Right-clicking with the fill tool reacts similarly (as expected).
 

o This could do with a "grid" for placing components or at least a small
  delay after a click before it can be moved. I routinely moved GUI elements
  by accident for 1 pixel when I just wanted to select them.

There used to be an option to lock GUI controls in place. That was taken out in 3.0 with the redesign of the editor. But I for one would like to see it back.

o It would be nice to give sounds names instead of numbers.

As noted this has been changed in the upcoming version 3.2.

o I didn't find the documentation for [ hide ] [ /hide ] in the forum documentation
  where the other tags are documented.

I don't know that this tag is documented. I discovered it (as you probably did) just by quoting someone else who's used it.

[Ryan Timothy B]

Sprites:
o It would be nice to have a "Reimport Sprite(s)" command which
  simply reloaded the selected sprites from the filename stored in
  the SourceFile property. This allows to edit multiple sprites
  with an external editor and then updating them in AGS without
  having to browse to each (in my case I was generating *lots* of
  frames for animations from a 3D source and I found it to be less
  painful to simply delete the old sprites and recreate the
  animation loops than try to replace the sprites from file).

GUI:
o This could do with a "grid" for placing components or at least a small
  delay after a click before it can be moved. I routinely moved GUI elements
  by accident for 1 pixel when I just wanted to select them.

I completely support these two suggestions. 

I move the GUI controls all the time too.  I also use the time consuming drop down menu just to avoid accidentally moving them .  Perhaps if a GUI control isn't selected, you shouldn't be able to move it on your first click.  The first click should be for selecting the control, second click and hold should be for moving it.  Or just the tiny delay on the first click would do.

Perhaps also adding the ability to align the GUI control X and Y coordinates with the arrow keys.  I know I'd like this feature (I'm always playing with tiny GUI buttons and having to place them exactly--arrow keys would be much easier than subtracting/adding from the editor pane).

[frogking]

@monkey: Thanks for the detailed reply!

I'm sorry, what? AGS does not allow functions to be called after only the declaration like C++, they must be defined before they can be called.

Well that explains it then

o When compiling the game, there should be an error if an
  event handler has a function name set which does not exist,
  just as for functions called in code. Currently this seems to
  needlessly crash at runtime.

By this same logic there should be a compile-time crash for any functions which have an import defined, are never called, and are never defined. Obviously these event handlers are called internally so even if they're not defined there may not be (currently) a flag thrown for an invalid function call. I support the logic of it, but I'm not sure it's presently feasible. Might be quite a task for CJ to implement this.

I'm not sure I fully understand this and your comparison to a function which is never called. Just to make sure we are talking about the same thing: For me, specifying the name 'foo' in the GUI as an event handler is functionally equivalent to writing a call to 'foo()' in the script. The latter case rightly generates the compiler error "undefined token foo".

It's the other direction which is harder to detect: When code may reference an object defined in the GUI, as with sprites (so you get this big glaring warning box if you delete a sprite in the GUI). Although I found it strange that the sprite then gets deleted even  if there is a perfectly obvious internal reference from an animation loop or similar (and AGS already has a function to check sprite usage in the GUI). It might be useful to call this automatically before deleting a sprite.

o It would be convenient if the InventoryItem had an event
 
    UseInvSymmetric(InventoryItem* otherItem)

  If an item is used on another, this would always be called for both items.
  So you only need to implement one for combining two objects.

This is exactly the same as the existing iItem_UseInv functions only that it takes an InventoryItem parameter directly. The "normal" method of usage is just to check player.ActiveInventory. Even given your implementation though I don't see how this would prevent the need for duplication of code/logic.

The key phrase here was If an item is used on another, this would always be called for both items. That is, the engine should raise this particular event twice, once for each item. This is what the "Symmetric" hints at. Of course, the user must then take care not to accidentally implement it twice.

o When importing a sprite with an alpha channel, you first get
  a message box asking you whether to use the alpha channel. Then
  the normal sprite import dialog opens which includes the normal
  transparency options. This is a bit confusing for the user. I
  would recommend to include "Alpha Channel" as an option in
  the "transparent colour" combobox and select it as default if
  the imported image has an alpha channel. This would make it
  more clear what happens and it saves a click too.

There are two options that perform this function. "Leave as is" and "No transparency". Most likely if you're using an alpha channel you're going to use "No transparency". The name of the option itself might be confusing, but there's a calltip-esque prompt that tells you what it does.

Well, the prompt for no-transparency says "AGS will make all transparent pixels non-transparent" which is very off-putting if you wish to use transparency, even when controlled by an alpha channel. Even worse is the prompt for Leave as-is which says "Pixels which have transparent color will be transparent", which is exactly what you wish to avoid if your image may contain all possible color values and relies on alpha channel for transparency. I was rather worried by this. Also, none of the options are meaningful when using an alpha channel so they should at least be grayed out.

o A warning might be displayed within the dialog if the imported
  image has an alpha channel but the game is not configured to be
  32-bit color.

I do get an error (at least in an 8-bit game):

That's because you can't import 32-bit images at all. In a 16-bit game you can: the image will be scaled down and the alpha channel silently ignored.

Maybe this would be easier if showing the room's "Nothing" could populate the properties drop-down with everything?

Yes, getting all objects in the properties drop-down is what meant with disabling filtering. It may get a bit cluttered but you can also begin by typing the first letters of e.g. hMyHotspot. It would have felt more natural for me in the coding phase. While drawing hotspots and walk areas of course the filtering is helpful.

Right-clicking while drawing areas uses the "eraser" which really just draws hotspot 0. This is the same as in MS Paint where right-clicking draws the background color. I would expect it to do this. And if you want a way to clear the current region just use the fill tool instead of line tools. Right-clicking with the fill tool reacts similarly (as expected).

Ok, your expectation is then based on better understanding how hotspot 0 is related to the background than I did Still, I distrust the fill tool because with thin or disconnected regions it can be fiddly and force you to rely on the one step undo.
 
Apropos unexcepted behavior of hotspots and background: Initially I hoped I could have two overlapping hotspots with one of them always being disabled, but it seemed that the area of the disabled hotspot was always treated as background / hotspot 0?

[frogking]

That's because you can't import 32-bit images at all. In a 16-bit game you can: the image will be scaled down and the alpha channel silently ignored.

Actually, for 16-bit games there could be a mode "Transparency from Alpha Channel" which would be the same as "No transparency", i.e. changing all pixel values away from the transparent color by a slight amount, but then writing the transparent color value to all pixels where the alpha channel indicates full transparency. Of course you don't have support for partial transparency including its anti-aliasing effect then, but it would still be a good way of using images in 16-bit games where you do not have exact control over pixel values, such as 3d renderings (or photos, but those rarely have transparent pixels).

[monkey0506]

I think you might be misunderstanding the way "No transparency"/"Leave as is" work. AGS internally uses magenta (RGB 255, 0, 255) as a transparent color. "No transparency" means that any pixels with the exact RGB color of (255,0,255) will be replaced. "Leave as is" means that any pixels with that exact RGB color will be interpreted by AGS as being fully transparent.

As for the sprite import as I said I only tested it on an 8-bit game. But true, it should probably at least give a warning if you're using 32 bit.

With regard to the inventory items I understand the reasoning but that's very inconsistent with everything else and then as you said is reliant upon the user to only define one implementation for each item pair. Short of AGS just defining a built-in function that does the same thing as the code I posted above I still fail to see how this would be useful.

As for what you said about the hotspots AGS uses a bitmap as a mask for walkable areas, regions, and hotspots. Just like MS Paint doesn't support layering, neither do any of AGS's masks. It's been requested many times for this behavior to change, but this is a very sensitive area of the engine and be quite a bit of work. For example if hotspots could overlap how would Hotspot.GetAtScreenXY work with overlapping spots? Some sort of z-ordering would presumably have to be implemented for each of these types to define which one is "on top". And what if you wanted two regions to be able to overlap the same area and both still be active at the same time but only fire off events for the top region? They would have to have some type of method of defining whether or not other events for overlapping areas should be registered. Etc. and so forth.

I don't think I understand the need for this "Transparency from Alpha Channel" though, even for 16-bit games. I've done some testing and it seems that if I import an AA sprite into a 16-bit game the fully transparent areas are flattened against a white background and then the rest of the image is flattened against a black background (when using "No transparency" or "Leave as is"). However, if I select the "Top-left pixel" option (where the top-left pixel is defined as fully transparent) then the fully transparent areas are and the rest of the sprite is again flattened against a black background.

[frogking]

I think you might be misunderstanding the way "No transparency"/"Leave as is" work. AGS internally uses magenta (RGB 255, 0, 255) as a transparent color. "No transparency" means that any pixels with the exact RGB color of (255,0,255) will be replaced. "Leave as is" means that any pixels with that exact RGB color will be interpreted by AGS as being fully transparent.

This sounds like I thought it works, except I didn't know the internal value was fixed to (255,0,255). However, as far as I understand it, this transparent color is not (and should not be) used when the image is loaded into a 32-bit game with alpha channel support. In that case, the alpha channel is stored separately by AGS and only the alpha channel is used for determining transparency. Therefore, it is a bit confusing if the dialog offers to process the sprite with respect to the transparent color, which isn't used anyway.

Regarding 16-bit games, the alpha channel would just be another method for specifying which pixels should get the color 255,0,255 during import. The benefit of this would be that you don't have to worry about accidental usage of the transparent color. If you render a sprite with transparency from a 3d engine instead of painting it by hand, there is no guarantee that the exact color 255,0,255 occurs nowhere in the solid part of the sprite, which means "Leave as is" doesn't work reliably. Using the sprite corners is even more likely to produce unwanted effects."No transparency", of course, will also kill those parts which are intended to be transparent.

And thanks for explaining the AGS basically uses a "labelled image" internally to represent regions. This is of course also makes it consistent that clearing pixels affects all regions, and also that drawing over an existing region affects that as well. In that case, I think a "lock inactive regions" checkbox could be useful. This would allow drawing of new pixels only over hotspot 0 and clearing of pixels only for the currently selected hotspot.

[Pumaman]

Thanks for all your feedback. It's always really useful to have this sort of feedback from people who are new to AGS and haven't just got used to it over time.

I do agree with the vast majority of your suggestions -- as always it's a matter of prioritisation. Once AGS 3.2 is out of the way with the new audio system, hopefully there will be an opportunity to implement some of these type of suggestions.

[Ryan Timothy B]

Ooh.  I almost forgot...

A trivial GUI Suggestion:
One thing I would find very useful (if it would be incredibly easy to implement in the editor) would be the ability to do simple math within the programming pane.  I often create a dozen or so buttons in a GUI, then realize that I wanted to add something else on the left or top of all the buttons.  Normally I have to change the Left or Top location of all the buttons, by doing mental math or using a calculator to Add or Subtract a certain width or height.  It would be so nice if I could, for example, change the Left from 185 to 215 by actually typing this in the editor pane: 185+30.

Edit: I guess it would also be useful for sprite numbers and whatnot.

It's only food for thought, but it would be super cool to have and I know I'd use it often enough.  

[Wonkyth]

Yeah, if arranging a GUI was like arranging a form in visual studio...

[Pumaman]

Yeah, the GUI editor should ideally allow multiple selection, moving controls with arrow keys, aligning controls with each other and to a grid, and all that other goodness. One day!