Let's build a new AGS demo game!

Started by cat, Sun 14/05/2023 19:41:43

Previous topic - Next topic

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

#21
Quote from: Babar on Tue 30/05/2023 19:27:19No 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.


Quote from: cat on Tue 30/05/2023 19:35:31The 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.
J. They/them. Here are my most recent games:

Crimson Wizard

Quote from: RootBound on Thu 01/06/2023 12:13:46Does this sound like an accurate summary of the consensus here?

Yes, I fully support the above.

cat

#24
Quote from: Crimson Wizard on Thu 01/06/2023 12:20:01Yes, I fully support the above.
+1

QuoteIf 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

#26
Quote from: cat on Thu 01/06/2023 16:03:34Oh, 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.

Quote from: cat on Fri 02/06/2023 11:58:38Thinking 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

#27
Quote from: Crimson Wizard on Fri 02/06/2023 12:16:23Our 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

#28
Quote from: cat on Fri 02/06/2023 12:47:06I 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

#34
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.

Quote from: cat on Sun 04/06/2023 08:55:00- 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;
}   
J. They/them. Here are my most recent games:

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

Quote from: RootBound on Sun 04/06/2023 15:47:231-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

#38
@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?
J. They/them. Here are my most recent games:

Crimson Wizard

Quote from: RootBound on Sun 04/06/2023 16:14:00@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.

SMF spam blocked by CleanTalk