Let's build a new AGS demo game!

[cat]

We have a github repository for our demo game: https://github.com/adventuregamestudio/ags-demo-game/


Everyone, help us to make a new AGS demo game - we need writers, artists, musicians, coders, testers and project managers!

As discussed in this thread (https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/crowd-sourced-of-an-open-sourced-ags-example-game-collaboration/), we want to build a new AGS demo game.

The game should demonstrate the most common features of AGS and will be targeted mostly to people new to AGS. It should showcase typical adventure game use cases and allow for easily getting them work in your own code. Ideally, the game should also be fun to play.

There has been a crowd sourced game been made before: Draculator II: Byte of the Draculator. Can we do this once again?

The first stages will be mostly discussion where to go. Everyone is invited to join in.

As Crimson Wizard has pointed out, we should start with thinking about what features should be included and what UI to use.
What is the UI that most newbies are using? What is most asked for in the beginner boards?

[RootBound]

I've been following these threads for a couple of weeks and had a maybe crazy but maybe good idea.

Here's a mock-up of a title screen (I couldn't resist  ).



The idea is for the first door to take you to a demo game (nothing meta about it, basically something short, similar to a MAGS entry). The second door would take you behind the scenes of the demo, with a TRON-like guide showing you how things like hotspots, walk-behinds, etc., created the immersion, and perhaps demonstrating small bits of code (no more than 3-4 lines). The third door would demonstrate more advanced capabilities, like the Tween module, Rellax module, custom GUIs, mostly as a showcase, with the code itself maybe heavily commented as a guide.

If this isn't what you're looking for, that's fine. I just wanted to share because I had fun with it. (I adapted Roger's walking animations for both the TRON-like figure and the Mage figure if anyone wants them  ).

Feel free to adopt any or none of the ideas here.

Cheers,
RootBound

[cat]

This looks awesome!

However, I think the demo game should be a rather simple, and not three different things in one AGS project. Newbies would have a hard time to find the relevant part in code if the project is too big.

Your second door makes me think of another concept: When you solve a puzzle or discover a feature, the player character could mention that and give you a pointer where to look this up in the code or the manual.

Example: "Hey, I just picked up an object! If you want to know how to code this, search the AGS project for #pickup."
"Woah, that room is bigger than it seems. Look up "Scrolling room" in the manual to learn how to do this."

[RootBound]

@cat You're right of course -- it would three times as much work to make as well.

But I like your idea of incorporating the tutorial aspects into the game itself. That's a much more efficient way of executing the same concept.

To answer your original inquiry, here are the features I think a demo game could showcase.

Scaling walkable areas
Walk-behinds
Animated backgrounds
Animated objects
Different views for player character
NPCs
Dialogs
Inventory items
Combining inventory items
Cutscenes
Credits
Splash screen
Different music in different rooms
Sound effects
Title menu
In-game menu
Credits
Basic visual effects (character walks off-screen before changing rooms, overlays)
Text input
Built-in UI modes (Walk-to, talk-to, and so on). I don't know what the actual UI should look like, but it seems sensible to me to showcase the built-in modes.

I'm sure there are more features to showcase, but this can get the list started.

Also, I started a different thread and put the assets from the above mock-up there, in case anyone wants to play with them: https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/some-free-sprites-to-play-with/

[Crimson Wizard]

However, I think the demo game should be a rather simple, and not three different things in one AGS project. Newbies would have a hard time to find the relevant part in code if the project is too big.

In the previous thread I made a suggestion to plan 2 demo games: one basic one, and one advanced one, latter using modules like Tween and others for effects.

To answer your original inquiry, here are the features I think a demo game could showcase.

This is about the list I was expecting for a simple demo game.

Perhaps these could be grouped for easier task designation and making checklists; while some expanded further.

For example, "game scenes" task group would include:
- Splash screen
- Title menu
- Credits

The "UI" task group would include:
- Gameplay controls
- In-game menu

The "room composition" task group:
- Animated backgrounds
- Animated objects
- Scaling walkable areas
- Walk-behinds
- Room music

And so forth.

On another hand, for example, "Dialogs" may have subtasks:
- Turn options on and off depending on story stage.
- Different replies (on same option) depending on story stage.
- Different replies (on same option) depending on how many times did you select same option. (e.g. NPC becoming annoyed that you keep asking same question)

[cat]

I would structure this differently. I would go by room and have the player explore each room after another.
For example, the first room would be a title screen, with just a start and load button.

The second room could be a room with a few hotspots or objects. The first task could be to pick up a key and unlock a door. Or maybe pick up two objects, combine them, use them to open a door to the next room.

Then there could be a room with a NPC, you have some dialog, give them an item which unlocks more dialog and the NPC will give you another item.

A room could be about room features - use keyboard controls where you have to carefully navigate a KQ3 like path, including scrolling room, regions, walkable area scaling etc.

A sound room might focus on music, sound effects and voice acting.

The more common features should be showcased earlier in the game, the more difficult ones later. When grouping them per room, it should be easier for the player to find the code for the feature to look up how it's done.

Every room file could have a big comment section on top where the features of the room are explained, how they are used, where to look up in the manual.

[Crimson Wizard]

I would structure this differently. I would go by room and have the player explore each room after another.

My intent was to suggest a checklist of things that should be featured in the game. How they are featured is an open question.

In regards to the rest, I see that the idea here is more of a "technical" kind of a game, where features are artificially divided in scenes, as opposed to having a "regular" game demonstrating the selection of features.

[Crimson Wizard]

Trying to remember things that are asked about often enough...

- Combining character looks out of several sprites, such as add new dresses, to save on amount of sprite variants drawn. (idk if this is considered "too advanced").
- Switching playable characters, maybe temporary for some puzzle, if you don't want to make a multi-protagonist game.
- Flashlight, where you need to search a "dark" room with a circular spot of "light".
- Certain object or item closeups where you may manipulate with them.

Random weird ideas:
- An NPC photographing you, then giving you a photo, which is basically a screenshot of a game (with GUI and cursor hidden) .

Technical stuff:
- Formatting a string and displaying some values on a label or elsewhere.

[Danvzare]

Trying to remember things that are asked about often enough...

Something that I think I've seen a few times, is people wanting to combine items both ways without having to duplicate the code. Like using the scissors on the paper, and the paper on the scissors.

Also I remember when I first started with AGS, I really struggled with implementing doors. Yes, I know it sounds stupid. But at the time I couldn't wrap my head around an object that could be open or closed, you can switch it between both states, only go through it when it's open, and the door's state has to be consistent if there are multiple way to enter the same room. It's obvious to me now, but it wasn't at the time.

[cat]

My intent was to suggest a checklist of things that should be featured in the game. How they are featured is an open question.

Fair point.

In regards to the rest, I see that the idea here is more of a "technical" kind of a game, where features are artificially divided in scenes, as opposed to having a "regular" game demonstrating the selection of features.

True, this should be decided first. Do we want to create a game that is basically a regular adventure game but open source and includes the most common features? Or should it be some kind of tutorial game?

[RootBound]

My thoughts on why a tutorial game might be better than a regular game: Everything that can be done in a regular game can also be done in a tutorial environment - there can still be puzzles, plot, character development, setting immersion, etc., if desired.

But a tutorial has a few added benefits--one, it allows for a lot of flexibility in terms of demonstrating AGS capabilities (for example, rooms with many walk-behinds, many non-contiguous walkable areas, a variety of room-design concepts, even multiple examples of different GUI types if that's what people want to include, without necessarily being beholden to aesthetic consistency in the way a non-meta game might need.

Two, it "breaks the ice" a little more for people who are thinking about getting into gamedev with AGS. By which I mean, a regular game shows the engine potential, but a tutorial both shows the potential AND gets the player started in understanding how it's made, so that they don't "go in cold" the first time they open up the editor.

Just my two cents. I know I'm still new around here, so I expect there's a lot I'm not considering.

Whatever the direction turns out to be, though, I'm happy to draw/animate some background art, design rooms for demonstration of edges, walkable areas and walk-behinds, and potentially also contribute art for custom GUIs.

[Crimson Wizard]

Well, the tutorial game sure has its benefits, as it does not throw everything into the user at once, but allows to acquaint yourself with AGS gradually.

[Danvzare]

I'm personally of the opinion of having a tutorial game. One where you can look at the code for each individual room and get a good idea of how they were coded.

I remember when I first started with AGS, I liked to look at the example rooms that came with templates, to see how to do basic things (I even ended up making one myself as a personal notepad of snippets of code).

Something like that can also be its own little (albeit simple) game. After all, to demonstrate picking up a key and using it on a door, it's best to actually have a room where there's a key on the floor which you can pick up and use on a door.

But that's just my two cents on the matter. There are definitely good reasons to have a demo game that's meant to be a showcase of what you can do with the engine, rather than a tutorial game which tells you how you can do things with the engine. It all depends on whether we want to inspire newcomers or help them get acquainted.

[Crimson Wizard]

But that's just my two cents on the matter. There are definitely good reasons to have a demo game that's meant to be a showcase of what you can do with the engine, rather than a tutorial game which tells you how you can do things with the engine. It all depends on whether we want to inspire newcomers or help them get acquainted.

There may be two demo games, one made as a tutorial, and another for showcasing more advanced stuff mended together.

The tutorial game could have a "chapter" menu which teleports you to the wanted room, with description of what that room does.

[Stupot]

Similar to what cat suggested above, why not have it as a regular demo, but every time you perform an action, a dialog appears asking "Would you like to learn more about [implementing doors]?" The player can click 'yes' if they want to see some tutorial tips (that maybe pops up in a large GUI). Otherwise, they can click 'no' if they think they can already handle it.

As the game goes on, these tutorial screens would all be added to a list in a separate menu (or just all visible from the start anyway) for users to click on if they decide later that they want to learn more.

These screens would include some simply-worded explanations, some cute animations, and guidance for where to find more detailed instructions, as cat mentioned.

——-

One thing that must be kept in mind is this: This is a project for beginners. It should be a fun and interesting game, as all games should be, but the tutorial aspects must be clear and welcoming. Something that absolute newcomers to the very concept of game design will actually use and learn from.

[Babar]

One thing that must be kept in mind is this: This is a project for beginners. It should be a fun and interesting game, as all games should be, but the tutorial aspects must be clear and welcoming. Something that absolute newcomers to the very concept of game design will actually use and learn from.

Is this a given? Does it need to be a "fun and interesting game", or will this get in the way of it being a showcase/demo/explanation game? Which is prioritised (because, for example, I can't imagine a fun and interesting game constantly interrupting me to ask "Do you want to see how that was done?")?

If we want a "fun and interesting game", I recommend collaborating and just making a fun and interesting game, totally normal, like any other game, except it happens to be open source, and source be very nicely and documented and organised, and covering all the requirements listed above. The issue here would be finding a way to combine all the possibly incongruent features (multiple interaction methods, keyboard control, etc) into a single experience, but I'm sure the AGS community is up to that if we put our mind to it.

The other option is a game where the primary purpose is to showcase all the features, perhaps even at the cost of not being "fun and interesting". I'm imagining something like the previous demo game that we had, which was basically what people are suggesting now- barebones 'plot' with a few interactions to showcase how puzzles can work, each room having specific features showcased, rooms had signs so the player could walk to the ones they were interested in. Perhaps each feature would have a short in-game explanation as well (although I'm not sure about the effectiveness of going too far in making it into a "tutorial", text explanations in-game would be hard for someone who has their own game and wants to know how to implement a feature). Coupled with that, it would also obviously be open source, and all these features could be investigated in the well documented code.

[cat]

Similar to what cat suggested above, why not have it as a regular demo, but every time you perform an action, a dialog appears asking "Would you like to learn more about [implementing doors]?" The player can click 'yes' if they want to see some tutorial tips (that maybe pops up in a large GUI). Otherwise, they can click 'no' if they think they can already handle it.

This will become annoying quite soon. What about a big question mark button in the corner where you can click to get more information?
Most of the explanation should go in a big comment block at the top of each room script file anyway, I think.

The tutorial game could have a "chapter" menu which teleports you to the wanted room, with description of what that room does.

I like that idea!

[RootBound]

What about a big question mark button in the corner where you can click to get more information?
Most of the explanation should go in a big comment block at the top of each room script file anyway, I think.

I like this. It makes me wonder what what the rest of the UI should be, as that hasn't come up much in the discussion so far. The original post asked what UI most newbies are using and what gets asked about most often in the forums. I don't think I know the answers to these questions, but just to jumpstart the UI aspect of the discussion, what do people think of the following options?

Some graphical interface ideas:
1. Default pop-up like the BASS template.
2. Old-school verb list at the bottom.
3. Mostly hidden UI, such as a corner button that brings up a menu.
4. A few different small buttons that are always visible, such as a button to bring up the save/load dialogue, a button to bring up an inventory bar, a button to adjust game controls like volume, a pause button, and a button to quit (along with the question mark possibility above).

Then there's the clicking:
1. One-click interface (type of interaction changes depending on what is under the mouse).
2. Two click interface (something like walk/talk/take for left click and look for right click).
2. Two click with right clicking to switch between all the interaction modes (a built-in feature that may be worth showing off). There could also be a "learn more" mouse mode which displays the tutorial information for that object.

Obviously there are many more possibilities than this. What are other people's thoughts / ideas?

[Babar]

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)

[cat]

I like the idea to make the interface adjustable through the settings.

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.