Suggestions for the next version of AGS

[subspark]

I agree with GarageGothic entirely and believe it is a necessary step forward for AGS development. This whole force letterbox resolution thing has always felt a little loose and while it might be appropriate for older games which were developed for specific aspects I believe now is the time to support automatic aspect correction that is put in the designer's hands.

I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

It's quite easy to understand that this kind of developer control would offer uniformity and consistency to a game and its options rather than force the player to tinker with a completely separate application, when all he/she wants to do is play a game that works.

Cheers,
Paul.

[VK Dan]

I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

I would love to have the settings incoporated directly into the game, but if I remember correctly the reason for having a separate application for the game's setup was to allow people to change things if the game engine was unable to run.

There are possible workarounds, but it seems like a good idea to at least keep the current gamesetup around.

[subspark]

I agree however I feel my point still stands. I'll tell you why.

The only obvious reason why AGS games might not run correctly, or at all, is because the resolution of a game does not account for the different aspect formats or the color depth might not be supported. I you haven't noticed already, the few options in the game setup exe control the things in a game that a developer should account for when developing the game. If a developer chooses to make a 32 bit game, then the option to downgrade the game to 16 bit might not sit well with developers who intend their game to be enjoyed in its true glory. I think that option is by far obsolete. As for resolution, seeing there are only 2 mainstream display formats, 4:3 and 16:10, it is not difficult to imagine support for the developer to make their game adjust itself, automatically, for the monitor the game is being played on.

As for windowed support, this option could also be accessible in the game. Theres no reason why full screen gameplay couldn't switch to windowed gameplay on request rather than having to relaunch the entire game after tweaking settings in the game setup exe. As for sound, this is unlikely to be the cause of a game not running at all these days.

I feel that the game setup exe is a little hackish for todays times and lacks the professional polish that should be seen in a state of the art Adventure game. Having said that, the game setup exe does have its place. Older games not designed to work with both 4:3 and 16:10 screen formats automatically, will always come with an external setup exe, although most of the AGS games I have downloaded choose not to distribute their setup exe.

I think that a game developer should be able to choose whether to include an Editor GUI based game setup or a separate executable depending on what kind of polish the developer intends to give their game.

Cheers,
Paul.

[GarageGothic]

To avoid confusion, I should say that I've never mentioned automatic  aspect ratio correction. I always imagined my suggestion of vertical resolution cropping being implemented as a reverse version of "Force alternate letterbox resolution".

In response to subspark, I think that an external setup program is stilll by far the simplest and techically safest way of controlling game settings - see the automatic detection in early Sierra games for Windows for examples of compatibility hell. There's way more to resolution support than simply aspect ratio. Your video card may support a certain resolution, but perhaps your display doesn't and all you see is a black screen. Or if you run your game windowed you might very well want to use the 2x or 3x filter to avoid straining your eyes. Distributing your game without a setup file is just asking for trouble.

[subspark]

I think the option should still be given to developers to control how their game should display these options.

In all honesty its time for AGS to move with the times and despite the obvious points you have expressed about keeping the game setup exe, my suggestion is simple: Allow the very same options to be incorporated as a GUI in the editor so that those who choose not to distribute the lackluster setup executable in their game installs can present those options without feeling tacky or out of date.

I say lackluster in the sense that it detracts from the game experience and is a token mark of the use of the AGS engine. Before anybody starts condemning me for AGS blaspheme I will say this: While some may argue that removing the need or providing an alternate method to the game setup exe is like choosing to leave CJ and AGS uncredited this is not true and is not the reason for leaving the setup exe out of a game. The whole point of an AGS game is the "game" itself and not what its built in.

Since the game engine is irrelevant to the player in the eyes of a developer, all of the game's settings and options should be accessible from within the game the way the developer wants to present it rather than be forced to present their players with a static and aging options program.

If a developer chooses to include the game setup exe instead of making his/her own GUI with custom graphics this should continue to be supported, however in this case, one method should not cancel the other out, but act as an alternative.

I imagine adding support for a GUI based options screen wouldn't be exceedingly arduous, would it Chris?
Can anyone else see the importance of housing in-game settings inside the game or are we all still stuck in the 90's?

My apologies for being so direct, guys, but I have to be the voice of truth once in a while. 

Cheers,
Paul.

[Snarky]

Maybe you would make your argument more effectively if you didn't come off as an arrogant ass who preemptively belittles other points of view.

Apologies for being so "direct", but... *yawn*

Has anyone denied that the ability to set the config options from within the game would be nice? No. Then why the attitude? However, since save games aren't even compatible across config settings, perhaps changing settings mid-game isn't as easy as all that. (A few people recently asked whether it might be possible to remove this restriction, so stay posted.)

Meanwhile, there's nothing to stop you from writing your own setup app if you don't like the default one provided by AGS. The configuration is stored in a plain text file.

[Shane 'ProgZmax' Stevens]

As Snarky mentioned, as long as savegames do not support changing resolutions, having the ability to change resolutions in game would be useless ;(.

[subspark]

I wasn't being benevolent to GarageGothic, Snarky. I agreed with his reccomendation that the setup exe has its place. I do tend to ramble on a bit sometimes so you'll have to forgive me for that.

Why don't you give me a break Snarky, please. Honestly mate, you seem to read into my text reply as if I am speaking it aloud in some smartass tone of voice.
I'm sorry but may I suggest you learn some restraint because your reaction here is clearly out of place.
I don't have an issue with you, why have you got it in for me? 

As Snarky mentioned, as long as savegames do not support changing resolutions, having such a feature in game would be useless ;(.

If this is the case I guess it's not as straightforward a process as I imagined. As Snarky mentioned, however, there is scope to work toward removing this limitation. Cool.

Cheers,
Paul.

[EDITED by mod] Double posting.

[Pumaman]

There's no reason that the setup options couldn't be available for use in-game, but the main reason for having an external setup application has already been mentioned -- imagine this situation:

You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

[Lt. Smash]

There's no reason that the setup options couldn't be available for use in-game, but the main reason for having an external setup application has already been mentioned -- imagine this situation:

You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

yes but there could be an array (system.SupportedResolutions) or something else. Then check in-game what resolutions are available and just show these ones. And in case of emergency you could use the external setup.

[Shane 'ProgZmax' Stevens]

This is just a curiosity on my part, CJ, but I'm wondering how challenging it would be for you to allow a toggle for dialogs that would allow (or not allow) action going on in the background while the dialog options are available?  I ask because, as it stands, environmental effects and background animations will just freeze-frame while you're selecting a dialog option and it looks a bit odd.  Would this be something overcomplicated to change, or to at least provide a setting to switch between the current method and a non-blocking one?

[Dave Gilbert]

This is just a curiosity on my part, CJ, but I'm wondering how challenging it would be for you to allow a toggle for dialogs that would allow (or not allow) action going on in the background while the dialog options are available?  I ask because, as it stands, environmental effects and background animations will just freeze-frame while you're selecting a dialog option and it looks a bit odd.  Would this be something overcomplicated to change, or to at least provide a setting to switch between the current method and a non-blocking one?

If animations could be played while the dialog options are up, that would be a HUGE boon.  It's always looked strange that everything on the screen freezes when the dialog options appear, especially during environmental effects like rain.

[Dualnames]

Yep, it's useful if you want to make M(ags)trix. Auto-bullet time effect on dialogs.

[Pumaman]

Yeah, there's no particularly good reason why the game is paused while the dialog options are displayed, it has just "always done it this way". I suppose it would make more sense for the game to be blocked but with rep_exec_always running (and thus animations, etc as well) like in most other blocking scenarios.

[Shane 'ProgZmax' Stevens]

In that case, I think it would also be useful to have a variable to track whether a dialog is running or not!  Then you could do nifty things like make the person being talked to get bored if you wait too long to respond, or tweak idle animation times...lots of things, really!  8)

[naltimari]

In that case, I think it would also be useful to have a variable to track whether a dialog is running or not!  Then you could do nifty things like make the person being talked to get bored if you wait too long to respond, or tweak idle animation times...lots of things, really!  8)

I had to make my own dialog engine because of this... well, actually there are a couple of other issues, like the user does not have access to his inventory during a dialog, because every GUI is 'disabled'.

If only the dialog data structures were available through scripting... that would be great.

[naltimari]

I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

That's an interesting topic. I agree with subspark that we should have a way to change the resolution in-game, through scripting/custom GUIs. But resolution-independent savegames should be discussed first! Otherwise it would be somewhat useless, if you know what I mean...

You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

It would be up to the game designer to prevent this, confirming that the resolution actually works, just like Windows XP does, for example. If the user can't confirm, the game 'downgrades' to the old resolution.

And, regardless of where the display configuration is, the 'mrs. player problem' could happen anyway, not because she decided to change the resolution, but because the default resolution, chosen by the game designer, did not work, for whatever reason.

To prevent that, there should be a 'safe mode' shortcut to the game, in which the game would be invoked in windowed mode, and THEN the user could be led to the setup screen.

[Dave Gilbert]

Couldn't the in-game setup and the regular WINSETUP.EXE work in tandem?

[Vince Twelve]

I had to make my own dialog engine because of this... well, actually there are a couple of other issues, like the user does not have access to his inventory during a dialog, because every GUI is 'disabled'.

Me too!  I like my custom dialog system because I can use normal scripting for advanced things and not have to resort to run-script X.


My (completely unrelated) suggestion (I haven't tried 3.01 yet, so forgive me if any of this is already addressed):

I have lots of animations and I get really tired of
-click "new frame"
-double click blank frame
-click on sprite window
-use scroll wheel to scroll down
-double click appropriate sprite
-repeat

For one, I think that when you double click a blank frame to open the sprite window, I shouldn't have to click on it to scroll it.  Two, I think that the last frame used should be centered in the window instead of placed on the bottom or the previous scroll position should be retained.

[Next useless paragraph removed, because as nat points out.  I'm dumb!]

[subspark]

nd changes the resolution to 640x400 using your GUI

Not at all my good Chris. As I mentioned earlier it would be up to the game developer to enable what game modes to display to the player maximizing compatibility for the developer's intended audience. Just as Naltimari reinforced.

Ideally I imaged that the developer could choose to use either a fully customizable in-engine dialog based setup screen or the default basic dialog executable. Not in tandem, but rather an alternative to one another.

Paul.