Topic: Setup program improvement

[Gurok]

You have "Custom saved games path" in basic settings, CW. I think that's an overestimate of how often people will need it. Move it to advanced settings.

Also, some advice. Forgive me if it's overly presumptuous. I think we should take cues from the Unity setup tool:



Ignoring the Input tab, it's:

• The three or four most commonly toggled options
• Options with short labels, like "Windowed" instead of "Run in a window instead of full screen"
• Some visual representation of the game it's associated with

I suggested we move towards this a while ago and made a mockup:





I know the mockup is incomplete and inaccurate, but for the most part, we are pretty close. I kept "Language" as one of the basic settings because I thought that would most often be changed. Similarly, people often toggle the Display Driver setting to resolve compatibility issues. 90% of the settings are fine at their defaults and I think Filter would be fine in Advanced. Just give people nearest neighbour by default. I consider windowed implied when you're in a window-based OS and full screen the exceptional state. I think that's why I put "Full screen" there. I wouldn't really care if we copied Unity directly and had "Windowed".

My dream would be to have it read "cover.png" from the game directory and show the pic above the settings. Pictures are very good for usability. They help people to form positive associations between the window that appeared and their original intent ("I have launched the right program" v/s "where am I now?"). We're both busy though. Ignore anything if it just seems like I'm making more work.

[Monsieur OUXX]

I've been waiting on this opportunity for a long time.
I think the setup screen should be divided into two main areas:
1) visible at all times ("basic")
2) "Advanced" : requires a click to be visible.
...Like Gurok suggested. But I also suggest something about 4:3 and 16:9.

Spoiler: ShowHide

In the "basic" area you could have "full screen" and choose the filter type. The hidden defaults could be "D3D9", "maximum zoom with letterbox", etc.
In the "advanced" area you could be able to revert to DX5, change the zoom level, all the weird things like vertical sync, etc.

On a side note: if you think "maximum zoom with letterbox" is not the best choice, then OK, fair enough, but maybe there should be an option on the "basic settings" panel to choose between 16:9 and 4:3 (and apply the corresponding recommanded settings).

Long things short: hide the things that the player needs to change only if he has technical issues or weird tastes. Make that screen as little confusing as possible.

Oh, and I'm all in favor to add a custom image AND a custom hyperlink to any troubleshooting board on the game maker's forums.

[Gurok]

I think the custom hyperlink would be good, as would a cover image. I recognise though, that these are both new features and would require more time to implement and test.

I don't think anyone would object to someone starting an AGS branch to re-implement setup for a future version. S/he could even allow an AGS game to be interrogated via the command line, thereby enabling external setup applications. It's just a matter of time. It would be a mini project to do so. I can understand where CW is coming from, partly because the goal is to avoid having 3.4.0 development drag on and partly because this is just following through from some of the free-resolution stuff he implemented.

[Crimson Wizard]

I don't think anyone would object to someone starting an AGS branch to re-implement setup for a future version. S/he could even allow an AGS game to be interrogated via the command line, thereby enabling external setup applications.

By the way, I wrote a post regarding this year ago: http://www.adventuregamestudio.co.uk/forums/index.php?topic=49969.msg636517935#msg636517935
I was leaning towards plugin interface though, although I won't object having some info returned to std output, which could be used as an alternative.
The reason why I was thinking about plugin, is that it gives engine little more control over what setup program does. For instance, in the AGS 3.3.5 I modified winsetup's module so that it no longer saves or loads config from the disk on its own, it just gets the strings map from the engine and works with that; and only engine knows where to load and save things at (this would also free setup from need to have a config file parser).
Naturally, plugin interface would require more work, because we would need to design a good API for enumerating and iterating some data from the engine, and send it back.

[Monsieur OUXX]

I didn't mean it as a resource, more like a file with a specific name and that must have a specific size, located in the .exe's folder. If it's there, then display the image. If it's not, then don't. Same thing for the custom hyperlink: if the correpsonding custom entry is in the configuration file, then display it. otherwise don't.

[Crimson Wizard]

I didn't mean it as a resource, more like a file with a specific name and that must have a specific size, located in the .exe's folder. If it's there, then display the image. If it's not, then don't. Same thing for the custom hyperlink: if the correpsonding custom entry is in the configuration file, then display it. otherwise don't.

That's relatively easier to implement on its own, but having picture that may or not be there still would require to overhaul the arrangement in the setup window, which I simply won't do right now.
(Also, I am more than sure that sooner or later users will start to ask to make these resources embedded in the game, because it is easy to occasionally loose external files)
I'd leave such kind of update to when someone will be able to dedicate decent amount of time for remaking setup into the configurable application (as Gurok suggested above). Or at least until next version.

[Snarky]

I don't think anyone would object to someone starting an AGS branch to re-implement setup for a future version. S/he could even allow an AGS game to be interrogated via the command line, thereby enabling external setup applications.

By the way, I wrote a post regarding this year ago: http://www.adventuregamestudio.co.uk/forums/index.php?topic=49969.msg636517935#msg636517935
I was leaning towards plugin interface though, although I won't object having some info returned to std output, which could be used as an alternative.
The reason why I was thinking about plugin, is that it gives engine little more control over what setup program does. For instance, in the AGS 3.3.5 I modified winsetup's module so that it no longer saves or loads config from the disk on its own, it just gets the strings map from the engine and works with that; and only engine knows where to load and save things at (this would also free setup from need to have a config file parser).
Naturally, plugin interface would require more work, because we would need to design a good API for enumerating and iterating some data from the engine, and send it back.

I would have thought that it would be cleaner to separate the setup and engine completely, so they only communicate through the cfg file (which should then be extended – or perhaps supplemented by another file – to provide more information about the game, e.g. the native resolution, game name, etc.). That should also simplify the task of writing external setup applications, since it's much easier to read/write a text file than to deal with some specific AGS API. And finally, it means that if worst comes to worst, you can always edit the cfg file by hand (as for example in this thread!); you can have "hidden" settings (e.g. experimental/debug features) that don't need to show up in the setup app.

Requiring more API calls to the engine, or worse: hiding all this stuff inside the AGS game file, strikes me as a step backwards. (Also, if settings are stored in the game file, doesn't that conflict with this whole security thing about not writing to the install directory?)

[Crimson Wizard]

hiding all this stuff inside the AGS game file, strikes me as a step backwards. (Also, if settings are stored in the game file, doesn't that conflict with this whole security thing about not writing to the install directory?)

I never said about writing settings in the game file. What I meant was that the engine knows where the config file is being written, loads and saves it how it needs, and only passes data to setup program. This way setup program's function is only to display these settings on screen and handle user modifications, then let engine store the settings as engine needs.

[Crimson Wizard]

I've split out all the related posts from the 3.4.0 setup thread (I hope I did not miss any).

I apologize if I sounded rough in above replies, but I am getting nervous from suddenly receiving a list of suggestions when I am just trying to make final fixes in the upcoming release.
I may or may not be able to participate in this discussion, but anyway, I do not have to be the one who does all stuff, so feel free to design/develop new setup.

[RickJ]

Generally, speaking " What color would you make it [the wheel] then?"types of discussions have no resolution just endless discussion. For this reason I would agree with Snarky that it would be best to have a separate setup program that just reads and writes the text file. Put it in a separate VS project and it would serve as a reference design for folks who want something a little different.  Taking this one step further, if there were a hook within AGS to trigger the engine to read and apply the config file then it would be possible to have in-game setup which would be accessible to all game makers.  Just my 2 cents.

[selmiak]

These are interesting features. Is it too early to ask for a skinnable winsetup (for those that can't just write a standalone setup program)?