AGS 3.3 Wishlist

[Trent R]

Making it possible to set custom properties during runtime: like having SetTextProperty.

This has been requested a few times over the years; the reason it doesn't happen yet is to cut down on the size of the save games. But it probably wouldn't add too much data to persist this.

How about separating the two into Run-Time Properties and Read-Only properties (or more likely just a bool checkbox) so that the ones that don't need to be won't bloat the save size.

But I don't know much, so my suggestion might bloat it more.


~Trent

[subspark]

I'm not really sure what you mean about the polygon, but yes the resolution system is under consideration for an overhaul

Oh sorry for the confusion, Chris. I meant drawing the scene onto two triangles like a texture. Two triangles making up a quadrangular polygon.
When referring to widescreen, I generally speak about low-res games being scaled up by filters. I prefer straight up pixel doubling whereas others prefer smoother scaling interpolation. We certainly need both methods to work with all aspect ratios.

Cheers,
Paul.

[Gilbert]

I am not quite sure but I doubt this.
In D3D9 mode I think the engine takes advantage of the mode to draw scaled sprites and the like, so I think it may not be just rendering in software and output to a polygon (or two triangles, whichever you prefer).
In DX5 mode, I think it's not the case either.

[Shane 'ProgZmax' Stevens]

Not quite sure I get what you mean there, Gilbot.  Are you saying you aren't sure that directx renders sprites as flat polys in d3d mode, because if so the answer is yes, it does.  This is something I used to experiment with quite a bit back in dx 8.1 (the performance of sprites blitted to the screen vs rendered to flat polys) and there is a noticeable performance increase in the latter method, not to mention the benefits of direct draw's built-in rotation and scaling for 3d objects.  I'm not sure what the benefits of rendering to two triangles would be over a regular poly, though, at least with flat sprites and backgrounds.


As far as suggestions go, I'll just reiterate my earlier suggestion to overhaul the music engine so the volume functions work across the entire spectrum regardless of the room's music setting (ie a smooth transition from off to loud).  Also, I'd like to see some kind of variable added to PlayMusic that will let you specify that the tune only plays once.  Granted, you can do this with playsound but if it's a music loop and not a sound loop it doesn't make much sense.  A 'looped by default' optional variable would make it so you could play short vignettes and such and wouldn't impact previous games or the way the function works for people who aren't interested.

One other thing I'd really like to see is all of the adjustable internal ags variables placed in the properties panes where appropriate.  I don't see any reason why these variables should remain hidden in such a robust editor, and many of them have practical uses (like speech display length, narrator text color, and so on).  Following along this line of reasoning, I think it would be good for the text color property to have a clickable colored box beside it representing the numeric color visually.  Too many times have I had to go back and tweak the color slightly in one tab and then type in the numbers.  This way you'd be able to click on the box, set the color, then it would be loaded right in and you could see a small square of what it should look like.

I'd also second SSH's suggestions and the multi-dimensional arrays.  I find nested structures and dimensional arrays highly useful, personally!  And for loops, switch statements...

[subspark]

Hey wasn't your name Gilbot V7000a once? Why are you now Gilbert V7000a? Is there a grand prize for the first person to notice this?!

I'm not sure what the benefits of rendering to two triangles

Its not a matter of benefits. In every raster engine, all 3d objects are reduced to triangles. It would be silly to render the screen onto a single triangle because your graphics would be cut in half. It's like getting a sheet of a4, cutting it diagonally from one corner to the other and discarding one of the two pieces. So to speak.

Cheers guys,
Sparx.

[Gilbert]

Hey wasn't your name Gilbot V7000a once? Why are you now Gilbert V7000a? Is there a grand prize for the first person to notice this?!

You are still wrong! And you are obviously not the first person who noticed this, since there were already people calling me that on the forums. I just don't want to go into details about the reason behind the change. 

[subspark]

Heheheh fair enough my friend. Lol.

Cheers,
Sparx.

[paolo]

[...] I second an easier translation method

Thirded.

I would also like to see repeated strings in translation files. At the moment, each string can only be translated in one way, but in most of the translations into English I have done for other people, I run into strings that show up more than once in the game and mean different things in different contexts. For example, in Righteous City II, the Italian word "vaso" meant "plant pot" in one place but "vase" in another - the same word in Italian is used for each, but English uses different words. Similarly, in DoVaDuLa'S BuRn, the phrase "Ciao Jack" means "Hi Jack" in one place and "Bye Jack" in another.

So it would be nice if multiple instances of strings could be supported somehow. The current workaround is to ask the game creator to change one of the strings in the game to something else, so that two different strings are generated in the translation file and can then be translated in two different ways.

It would also help when the translation file is translated without playing the game, as then the translator would be able to see straight away which strings appear more than once and find out from the game creator whether the translations need to be the same or different.

Ideally, strings with the same translation would be mergeable so that the user doesn't have to translate "Yes" or "Hello" or "That didn't work" dozens of times

[SSH]

Yes, well ... pointers to custom structs would be easy to add, except for the fact that the script state has to be saved and loaded in save games, which complicates the matter somewhat. It needs further investigation.

How about a new keyword indicating that some variables don't get included in save games. This would be handy for module writers, perhaps, or others who need to create large "temporary" but static (in the C-sense of the word "static") variables. We then have a "on game load" event handler to make sure that you can set any such variables to a safe state. Then you could add "easy to add" complex data types, as long as they were only declared with this keyword. It would also allow people to reduce their saved game file sizes if they wanted to, by setting some variables that didn't need saving to have this attribute. the keyword "unsavable" springs to mind.

An alternate or additional suggestion is to have the "const" keyword added, which allows extra types (e.g. Rick's function jump table).

[Pumaman]

Fine tuning the output of the translation sources. It would be very nice to have one file including character names which is sorted by rooms and GUIs, so there won't be so much confusion anymore when translating.

This has been requested a few times, and does need doing.

I wish for a pointer to function data type.  This would be useful in creating custom event handler and other modules where it is useful/necessary to call a function defined in a room or global script from the module.  This would also make it possible to construct a jump table (i.e. index into an array of function pointers to execute the function) which is also useful for custom event handlers.

Again, this is a very reasonable suggestion and I can see how it would be useful.

I meant drawing the scene onto two triangles like a texture. Two triangles making up a quadrangular polygon.

Well yes, that's how 3D rendering works. But I'm still not sure what your request is.

When referring to widescreen, I generally speak about low-res games being scaled up by filters. I prefer straight up pixel doubling whereas others prefer smoother scaling interpolation. We certainly need both methods to work with all aspect ratios.

Well, a lot of game developers here seem to hate smooth scaling, and wouldn't want people to play their games antialiased. So any implementation would have to work with pixel-doubling scaling, hence the resolution problem.

As far as suggestions go, I'll just reiterate my earlier suggestion to overhaul the music engine so the volume functions work across the entire spectrum regardless of the room's music setting (ie a smooth transition from off to loud).

Yes, this is definitely something that needs to happen... the sound/music volume system is a bit random to work with.

One other thing I'd really like to see is all of the adjustable internal ags variables placed in the properties panes where appropriate.  I don't see any reason why these variables should remain hidden in such a robust editor, and many of them have practical uses (like speech display length, narrator text color, and so on).  Following along this line of reasoning, I think it would be good for the text color property to have a clickable colored box beside it representing the numeric color visually.  Too many times have I had to go back and tweak the color slightly in one tab and then type in the numbers.  This way you'd be able to click on the box, set the color, then it would be loaded right in and you could see a small square of what it should look like.

These sound like reasonable suggestions, certainly.

I would also like to see repeated strings in translation files.

Hmm yeah, I understand the problem here but there's no easy fix, since AGS's translation system is based around direct string replacements. I'll have to have a think about how this could be implemented.

How about a new keyword indicating that some variables don't get included in save games. This would be handy for module writers, perhaps, or others who need to create large "temporary" but static (in the C-sense of the word "static") variables. We then have a "on game load" event handler to make sure that you can set any such variables to a safe state. Then you could add "easy to add" complex data types, as long as they were only declared with this keyword.

That's certainly a possibility, interesting idea.



Anyway, thanks for your input, guys. As always, there are lots of good suggestions and only a limited amount of time to implement them, so don't get your hopes up about any particular feature making it into 3.1.2

[Shane 'ProgZmax' Stevens]

You can do it, CJ.  We have faith in you!

[Ghost]

I'm just repeating stuff I mentioned somewhere else, but this time in the right place !

* return of the "outline GUI elements" and "lock GUI elements" to make moving/placing/resizing as easy as it used to be

* renumbering of views, and (if possible) of characters and inventory items as well, so that there is total control over how they are "grouped". So that, basically, all the tabs where you create objects are as flexible as the Rooms tab.

[RickJ]

With regard to the suggestions made by SSH and myself,  please take into consideration that although these ideas will mostly be of interest to module developers, they will be used by and be of benefit to everyone (whether they know it or not).

[subspark]

Well, a lot of game developers here seem to hate smooth scaling, and wouldn't want people to play their games antialiased. So any implementation would have to work with pixel-doubling scaling, hence the resolution problem.

I totally get you now. My request in the general sense is this:
Isn't there any way for AGS to use 3D rendering to render the scene onto a polygon while still allowing for pixel perfect doubling or quadrupling without blurry or antialiased results? Perhaps the user can choose to turn anti aliasing off?
Emulating pixel doubling in 3d rendering must be possible if the calculations are measured correctly?! Am I correct?

I appreciate all your hard work on AGS Chris.  I think I speak for everyone when I say you're a true phenomenon! LucasArts would have LOVED you back in the early 90s. Jeepers.

Cheers,
Sparx.

[Dualnames]

Well, ok,well as Ghost said lock..helped stuff back there.

But to what's been troubling me..
a lot.. mostly when I want to do stuff..

this:
gInventory.Controls[].AsButton

instead of a guibutton[] array, guilabel[] array.. I know that's a lot to ask..but well, I'm just asking.

[Vince Twelve]

I would like an IsWalkableAreaEnabled function.  I just came upon a place where I wanted to do this and was surprised that it wasn't in there.  Not sure about a work around yet...

[Shane 'ProgZmax' Stevens]

GetWalkableAreaAt (int x, int y).  It returns 0 if no walkable area is there.  You could store the coordinates for the walkable area's center somewhere and call this to check whether it is active or not.  I'm pretty sure it works with RemoveWalkableArea().  I agree that an actual function for this would be better, though.

[Gilbert]

I agree with adding that function. Though there are workarounds, which are mostly with storing the status with variables, it would be annoying to do so if you need to en/disable walkable areas in more than one room.

[Vince Twelve]

Yeah, that's a good work around ProgZ, unfortunately, I'm going to need this in pretty much every room and I don't want to have to enter in coordinates for every walkable area I use.   For now, I'm just leaving this feature out.  But if an IsWalkableAreaEnabled function shows up soon, then it's back in!

[Trent R]

You could set the WalkTo points in the editor and use those. Again, a bunch of work but then you won't have to manually script all the coordinates.

~Trent