Let's build a new AGS demo game!

[Snarky]

I think including all the UIs is a particularly bad idea, precisely for the reason cat gives: the codebase will be very large and inevitably entangled, the logic necessary to enable switching will add to the complexity, and it will therefore be almost impossible for a newbie to examine and understand (or merely adapt/reuse the relevant bits of) the code, and so the whole pedagogic purpose of a demo game will be lost.

Personally I think any such game should be kept as basic as possible, demonstrating only the bare minimum necessary to get going, and perhaps a few common use-cases and FAQs. For anything more complex or obscure, I think a separate demo focusing only on that particular feature would be much easier to get to grips with.

[Crimson Wizard]

No reason to not have all of them, adjustable through the settings.
And by "all" I mean the ones trivially available through the templates (Sierra, LucasArts verblist, verbcoin, 2 click/bass)

In addition to what Snarky sais above, I can name a reason to not have them all: these control methods imply different amount of verbs. This means that you will inevitably have to script the gameplay to require only minimal amount of verbs for walkthrough, and as a consequence that would make the rest of the verbs (and hence the control styles) redundant.

The only difficulty is to make is clear in code what belongs to which interface. rep_ex and mouse_click would have to be huge if else blocks, clearly separating the logic of each individual interface type.

That problem on its own may be solved by having control styles in separate script modules, as rep_ex, mouse_click and so on may be repeated as many times as needed in the game. You will only have to have a global variable, used to test which is the active style.

[RootBound]

My attempt at a summary of the discussion so far:

-Demo-focused. Can still be interesting and fun to play, but story is secondary. Focus is building familiarity with AGS
-Showcase basic features (listed above) as well as common forum requests (also listed above)
-Use a series of rooms with each room focusing on different features, to make code easy to find
-Rooms can range from very simple to complex, allowing newcomers a clear and gradual progression
-Advanced features, if present, should be showcased separately from the basics, or perhaps put in a different demo altogether
-Something like a chapter menu where player can choose which rooms to explore
-Explanations of each room's features are available within each room, but are optional to read (for example, question-mark button)
-Code should be heavily commented and explained
-UI should be simple and straightforward

Does this sound like an accurate summary of the consensus here?

If so, it feels like we could possibly move into more specifics, like planning which features to showcase in which rooms, what specific UI to choose, and so forth.

[Crimson Wizard]

Does this sound like an accurate summary of the consensus here?

Yes, I fully support the above.

[cat]

Yes, I fully support the above.

+1

If so, it feels like we could possibly move into more specifics, like planning which features to showcase in which rooms, what specific UI to choose, and so forth.

I agree, the next step should be which UI we will use. It obviously should be one of the default UIs that ship with AGS, but I have no idea which would be best.


Oh, btw, what is the targeted AGS version? 3.6.0 I assume?

[cat]

Thinking further about UI: With web port and Android port, I think the UI should be one that is usable on touch. This excludes BASS and Sierra. What about verbcoin and SCUMM? Thimbleweed?

[Crimson Wizard]

Oh, btw, what is the targeted AGS version? 3.6.0 I assume?

I believe that 3.6.0 should be minimal, at least because it supports Unicode, and can build to web/android from the Editor.
3.6.1 is in beta stage, it seems relatively stable, but who knows... Anyway, it will be possible to load 3.6.0 game sources into next 3.6.* updates if they come out later.

I think it should go without saying that the game must not use any backwards compatibility settings, or deprecated script API.

Thinking further about UI: With web port and Android port, I think the UI should be one that is usable on touch. This excludes BASS and Sierra.

Our touch screen emulation supports 2-finger mode, where tapping second finger while holding first acts as a right click.

The SCUMM style is complicated for the contemporary times. The template itself is additionally complex, with extra utilities, although it might be possible to reimplement a simpler variant without anything extra.

If you want to constraint to 1-finger/button controls, then it's either 1-click style, or verb coin and any variants of verb coin (with context menu of sorts) either with hold + drag + release or tap on object + choose verb from context menu method.

[cat]

Our touch screen emulation supports 2-finger mode, where tapping second finger while holding first acts as a right click.

I would have never guessed this is a possible thing on a phone. Some people already don't get that they can right click with the mouse when using a BASS UI, I doubt anyone will understand this on a touch device.

Then verbcoin it is?

I think it is a must that the demo game builds upon an existing template. If people start a new game from the template, they should be able to immediately copy code from the demo game to their code.

[Crimson Wizard]

I would have never guessed this is a possible thing on a phone. Some people already don't get that they can right click with the mouse when using a BASS UI, I doubt anyone will understand this on a touch device.

If the problem is guessing, then displaying a simple tutorial on screen as the game starts in the first room may be enough.

After all, there are games with more complex controls (using keyboard or gamepads), and people learn to use these, so why cannot they learn using right click in adventure game? This is somewhat baffling.

EDIT: I might add, it's possible to design slightly different controls for desktop/mobile, using System.OS as a condition.

[the_terrible]

For UI consideration, brewtonians ags_kyrandia is neat, e.g. used in Signal Loss.

[cat]

Don't make me think - right click is hardly used on mobile and web. So, unless there is a really good reason to learn a new UI concept, better use an established one.

[Crimson Wizard]

Well, if it's restricted to one finger/button, then personally I'd vote for 1-click style. People seem to be conflicted about verb coin style. 1-click + hotspot description either around cursor or at the fixed position on screen makes a easy combination.

[cat]

Ok, I just downloaded AGS 3.6.0P1 and wanted to create a new game but there actually is no 1-click style interface 
Is this something that would have to be created alongside the demo game?
I also tried the verb coin, but there it is only possible to open the inventory with right click, a weird design decision imho.

[cat]

Another option:

- Start with BASS, keep right button controls for look interaction, but making it not mandatory throughout the game; i.e. the look interaction just gives additional text, but is not required for progression. Make an additional button (maybe even only for mobile/web?) to bring up the inventory.

[Crimson Wizard]

I'm not sure what is the issue here, is it that we *must* start with an existing template?
We could start even with Empty Game and make 1-click controls there.

- Start with BASS, keep right button controls for look interaction, but making it not mandatory throughout the game; i.e. the look interaction just gives additional text, but is not required for progression. Make an additional button (maybe even only for mobile/web?) to bring up the inventory.

Well, that is also possible.

Inventory could be made always visible, if "pop-down" is not good.

[RootBound]

1-click controls can be pretty easy to implement, right? You basically do something like this?

Code: ags

global script repeatedly_execute_always

if (GetLocationType.GetAtScreenXY(mouse.x, mouse.y) != eLocationNothing){
  if (Mouse.Mode != eModeUseInv){
    if(GetLocationType == eLocationCharacter){
      Mouse.Mode = eModeTalkTo;
    }
    if(GetLocationType == eModeHotspot || GetLocationType == eModeObject){
      Mouse.Mode = eModeInteract;
    }
  }
}
else if (GetLocationType == eLocationNothing){
  Mouse.Mode = eModeWalkTo;
}   

[cat]

It's not a matter of how hard it is to implement (I've made games with single click interface). The question is, if the demo game should use one of the existing templates or not. I think yes, so I tend towards using the BASS template.

[Crimson Wizard]

1-click controls can be pretty easy to implement, right? You basically do something like this?

That looks more like a code for changing cursor graphic depending on a location kind. If you change modes like that, then you will have to remember to create specific events for each object type, which may be confusing.

For a trivial case you only need on_mouse_click:

Code: ags

function on_mouse_click(MouseButton button) {
    if (button == eMouseLeft) {
        if (GetLocationType(mouse.x, mouse.y) == eLocationNothing) {
            Room.ProcessClick(mouse.x, mouse.y, eModeWalkto);
        } else {
            Room.ProcessClick(mouse.x, mouse.y, eModeInteract);
        }
    }
}

Above requires to create Interact event function for any hotspot, regardless of their kind.

[RootBound]

@Crimson Wizard that's definitely simpler. Wouldn't this code interfere with eModeUseInv, though?

EDIT: Oh wait, I see. You simply put the (if player.ActiveInventory == iWhatever) code under the block for hotspot_interact?

[Crimson Wizard]

@Crimson Wizard that's definitely simpler. Wouldn't this code interfere with eModeUseInv, though?

EDIT: Oh wait, I see. You simply put the (if player.ActiveInventory == iWhatever) code under the block for hotspot_interact?

I forgot about this, but you may do both ways, adding a player.ActiveInventory check in on_mouse_click is perhaps more consistent.