We have a github repository for our demo game: https://github.com/adventuregamestudio/ags-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/ (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 (https://www.adventuregamestudio.co.uk/site/games/game/1491/). 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?
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 :-D ).
(https://i.imgur.com/2PmECz7.png)
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 (laugh) ).
Feel free to adopt any or none of the ideas here.
Cheers,
RootBound
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."
@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/ (https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/some-free-sprites-to-play-with/)
Quote from: cat on Wed 17/05/2023 11:30:47However, 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.
Quote from: RootBound on Wed 17/05/2023 12:41:58To 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)
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.
Quote from: cat on Wed 17/05/2023 14:04:51I 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.
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.
Quote from: Crimson Wizard on Thu 18/05/2023 00:34:08Trying 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.
Quote from: Crimson Wizard on Wed 17/05/2023 22:43:22My 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.
QuoteIn 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?
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.
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.
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.
Quote from: Danvzare on Fri 19/05/2023 14:49:50But 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.
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.
Quote from: Stupot on Sun 21/05/2023 01:17:46One 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.
Quote from: Stupot on Sun 21/05/2023 01:17:46Similar 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.
Quote from: Crimson Wizard on Sat 20/05/2023 01:28:47The 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!
Quote from: cat on Mon 22/05/2023 09:16:47What 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?
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)
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
For UI consideration, brewtonians ags_kyrandia (https://github.com/brewtonian/ags_kyrandia) is neat, e.g. used in Signal Loss (https://brewton.itch.io/signal-loss).
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.
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.
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.
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.
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.
1-click controls can be pretty easy to implement, right? You basically do something like this?
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;
}
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.
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:
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.
@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?
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.
I've been thinking about what kinds of rooms might be needed in order to showcase the list of features, and this is what I've come up with (for the "beginner course":
-Room possibilities:
* a "locked room" with a key and a door, or other simple puzzle, perhaps a crate you have to push to get a key off a shelf
* an "outdoor" or "map" area with different entrances to different rooms
* multiple walkable areas not accessible from each other (for example, a garden path with a balcony that can only be accessed from a different room)
* scaling areas, darker or brighter regions, walk-behinds (for example, a nighttime street with lampposts going into the distance)
* an "interface room" (for example, a bookshelf, control panel with levers) with first-person perspective (perhaps with text input)
* "dark room" requiring a flashlight
* a "simple special effects" room with moving objects, animating objects, perhaps areas where an animation happens in front of the player (for example, bubbles rising through a fish tank).
Some of these rooms should allow for at least one multi-room puzzle, even if others might be a single room accessible from a chapter menu.
Any other rooms we need?
Nice ideas!
I especially like having a map screen and an interface room.
The walking areas and scaling room could even be combined.
Some ideas I posted earlier that might have been lost:
Quote from: cat on Wed 17/05/2023 14:04:51the 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 NPC room could include swapping characters.
About the story - I thought it might be a treasure hunt. The goal is to find the magic big blue cup or something. To get it, you have to solve puzzles in each room. Collect a certain number of gems or something to open the final door. After you solve the initial "locked door" room, you get to the map where you can visit various places. The locations could be ordered by difficulty.
Quote from: cat on Mon 05/06/2023 19:59:12About the story - I thought it might be a treasure hunt. The goal is to find the magic big blue cup or something. To get it, you have to solve puzzles in each room. Collect a certain number of gems or something to open the final door. After you solve the initial "locked door" room, you get to the map where you can visit various places. The locations could be ordered by difficulty.
This sounds cool!
If I understand correctly, the first 3 rooms would be:
1: Title Screen / menu
2: "Locked room puzzle"
3: Map
and from the map you have lots of different options.
In the service of "keeping it fun to play," I think a fun way to do the map room would be almost Final Fantasy style, where the player is very small and can walk between different settings without having to go too far. For example, each "door" may not be a literal door, but a path, one leading into a forest, one to a lake with a sunken pirate ship, one into a volcano, one to a town/city, and so on. If the only place that is "locked" is the final room with the blue cup treasure, these could be pursued in any order.
Keeping with the Final Fantasy theme, the initial "locked room" could be getting out of a crashed airship. :-D
If this sounds too ambitious, I understand.
But as I said above, I'd be happy to contribute as much background art as anyone wants (I love drawing backgrounds), and if we get more contributors, different "areas" could be drawn in different styles by different people, which would also help show off the variety of possibilities for using AGS in different ways.
I'm happy to entertain other possibilities if people think something simpler would be easier for newbies or more fun, but I think the coding of the map room would still be pretty simple and easy to explore in the AGS editor.
Any thoughts / suggestions / questions / concerns / alternative ideas?
I have ideas I think would be nice and useful to demo, but I cannot tell whether this is fine for the demo game in question or not. Initially I thought there may be a "simple" demo and then another more complex one, but now when you are discussing this tutorial approach where advanced rooms open up as player progresses, I wonder if more complex functionalities may also be included at some future stages.
One thing that I might propose for consideration is the "maze" made of a single re-generated room (or small number of rooms). Number of classic and AGS adventure games have featured a maze region where character would travel around "cells" inside a larger maze. Only particular locations would be made as individual rooms, but most of the generic cells would be implemented inside a single room that gets reshaped depending on a "cell type".
I like the walking around map!
Thinking further about the map, if the locked room is also just one of the rooms on the map and the first thing where the player gets (after a short skippable cutscene, we should show cut scenes as well) is the map, this would practically be the menu for jumping into various rooms that Crimson Wizard has suggested.
If we do it this way, it would be
1) title screen
2) cut scene
3) map
One more feature we should show off that I think is often asked for, is a timed puzzle.
One other thing that occurred to me that should be decided early on and certainly before any artwork is what resolution the game should be.
Obviously 320 x 200 is the classic, but I also worry that making it super low-res might make newcomers assume the game engine can't do high-res games. Would something like 640 x 400 be better, or this maybe a non-issue?
I agree that we should decide resolution before setting up the project and doing any artwork. I also agree with your concerns. 640x400 is still rather lo-res, but it might be a good middle ground between 320x200 and anything considered high-res. This gives the creator of each individual room background some freedom in chosen style - you could still do fake super lo-res by drawing the background in 320x200 and scaling it up before import.
There's also 640x360 for 16:9 aspect ratio.
@Crimson Wizard 640 x 360 sounds good to me!
Based on
@cat 's idea of a treasure hunt and collecting gems to get to the end of the game, here's a proposal for a structure that encourages (but doesn't SUPER enforce) a progression from easy to difficult:
(https://i.imgur.com/1IlKqwb.png)
As pictured in the image, completing the starting room awards 1 gem. This allows access to the "basic" rooms. Completing just 1 of the basic rooms awards a second gem, which opens up the "medium" rooms. Completing one more room of either "basic" or "medium" unlocks the "advanced" rooms. (I got the idea for this structure from Super Mario World N64 - steal from the best, as they say).
This way the player does need to complete ALL easy rooms to explore the medium, and so one, but there is at least some encouragement in that direction.
As discussed above, the "map room" serves as a kind of chapter menu, with all "gates" to feature-rooms on one map.
If people like this structure, the next question would be - which features go in "basic", which go in "medium" and which should go in "advanced."
Side note: it feels like the question of UI isn't quite settled. Anybody want to weigh in further on whether it should be a default interface or a one-click? One-click is simpler, but newcomers would have to copy the code in order to use it, whereas the defaults come pre-set-up.
Personally I lean toward one-click, but I do see the drawbacks.
What do we think? One-click or a default like BASS? Pros? Cons?
Lurkers, chime in!
I suppose this also raises the question of whether it's possible or desirable to ship AGS with a default one-click interface as one of the built-in options, but that may be a question for another forum.
Have a good evening :)
I dunno if we should lock access to seeing complex features behind complex puzzles. If the purpose is to help the player understand how to implement reflections, for example, and reflections is considered a complex feature, it seems odd to require the player to either complete a maze or figure out which ingredients of a sandwich to give a guard so that they can access that room to see the reflection in action.
Then again, we could just incorporate debug mode into the usage of the game for that use case.
As for the interface, I am fine with not using a default template UI, and designing one from the ground up. As I understand it currently, there is no default interface template that is geared towards mobile (and yes, while the two-tap method exists, I feel that's an incredibly unnatural interaction to expect of the player, even if we give a tutorial for it).
As someone above suggested, we can do a 2 click interface (a modified BASS with a visible inventory), where the second click is for optional descriptive texts (could even be the way to access the tutorial/explanatory texts, since I doubt anyone would be playing the game on mobile if their aim was to learn from its code to develop their own game).
Quote from: cat on Tue 06/06/2023 21:43:06I agree that we should decide resolution before setting up the project and doing any artwork. I also agree with your concerns. 640x400 is still rather lo-res, but it might be a good middle ground between 320x200 and anything considered high-res. This gives the creator of each individual room background some freedom in chosen style - you could still do fake super lo-res by drawing the background in 320x200 and scaling it up before import.
Considering this is probably going to be quite text heavy and include descriptions for how to implement certain features. I think going for 640x400 or a resolution along those lines, would definitely be preferable to 320x200, at least for readability sake. (nod)
(Not that there's anything wrong with pixelated fonts, it's just hard to get a lot of text on screen at once in a low-res game, without it looking overwhelming.)
Quote from: RootBound on Wed 07/06/2023 22:22:07What do we think? One-click or a default like BASS? Pros? Cons?
Lurkers, chime in!
I highly doubt this demo game will be played on a mobile, and I also think it would be beneficial if there was some sort of implementation of the mouse wheel as a code example. So I don't think there's a reason to go for the one-click interface. Although I do think a one-click interface template should be included with AGS one day. But I digress.
As for the interface we should use for this, well personally I think a custom interface which can change between rooms would be preferable. So you can showcase each of the interfaces that come with AGS by default, you know 9-verb, BASS, ect. But considering that might be difficult to implement, the next thing I'd suggest is to just choose the one which seems the most popular to newbies. Which interface do most people gravitate towards when they first start using AGS?
For the record, the first interface I tried to use was a 9-verb template I found. But that was many years ago, and I'm usually in the minority with preferences like that. Besides I haven't tried to use a 9-verb interface in a long time.
Quote from: Babar on Thu 08/06/2023 04:19:03I dunno if we should lock access to seeing complex features behind complex puzzles. If the purpose is to help the player understand how to implement reflections, for example, and reflections is considered a complex feature, it seems odd to require the player to either complete a maze or figure out which ingredients of a sandwich to give a guard so that they can access that room to see the reflection in action.
I agree. I think all rooms should be accessible from the start. Of course, the separate locations should be grouped on the map (e.g. Beginner Village, Intermediate Fields, Advanced Woods) but all available from the start.
Quote from: cat on Thu 08/06/2023 19:42:58Quote from: Babar on Thu 08/06/2023 04:19:03I dunno if we should lock access to seeing complex features behind complex puzzles. If the purpose is to help the player understand how to implement reflections, for example, and reflections is considered a complex feature, it seems odd to require the player to either complete a maze or figure out which ingredients of a sandwich to give a guard so that they can access that room to see the reflection in action.
I agree. I think all rooms should be accessible from the start. Of course, the separate locations should be grouped on the map (e.g. Beginner Village, Intermediate Fields, Advanced Woods) but all available from the start.
Something I might propose as an option is to have walkthrough and tutorial modes, or rather have a proper walkthrough, but also an option to unlock all rooms at once. Of course in such case a walkthrough has to be scripted with a thought that player may arrive to a room without passing previous stages, in which case it might give necessary inventory items, for instance, or have each room self-sufficient and not depending on other rooms.
Then we would be back at your suggestion of having just a menu for quick accessing rooms on the title screen. That's also fine for me.
The real question is: how much adventure game is needed for a demo game? If you want to get a game with good story and great world building, there are tons of them in the database. The demo game should IMHO showcase the most common use cases and how to implement them.
Quote from: cat on Mon 12/06/2023 09:57:14The real question is: how much adventure game is needed for a demo game? If you want to get a game with good story and great world building, there are tons of them in the database. The demo game should IMHO showcase the most common use cases and how to implement them.
Yes, I guess you're right.
So, the rule should then be that
each room is self-sufficient, not requiring visiting other rooms for completing.
Quote from: Crimson Wizard on Mon 12/06/2023 13:35:28Quote from: cat on Mon 12/06/2023 09:57:14The real question is: how much adventure game is needed for a demo game? If you want to get a game with good story and great world building, there are tons of them in the database. The demo game should IMHO showcase the most common use cases and how to implement them.
Yes, I guess you're right.
So, the rule should then be that each room is self-sufficient, not requiring visiting other rooms for completing.
Like Gobliiins. :-D
I think that would be a very good rule of thumb to follow for a demo game. (nod)
Unless we need to showcase how something can happen in one room and affect another. But that's the only exception I can think of.
I see the sense behind making each room self-sufficient and having all accessible from the beginning.
I still like the map idea as a room menu, though. Maybe if one starts out on the map instead of in the "basic" first puzzle room, one could still enter it from the outside?
Anyway, I made an attempt at organizing the features into groups/rooms that hopefully makes sense. That feels like the logical next step to me.
The number of rooms could certainly be expanded or contracted based on what people think is best.
And the titles of each room here are just the "feature" themes. Each room could also have a "story" component (if they are still grouped into "areas" for each difficulty level).
What does everyone think? (Apologies for the gigantic image -- couldn't figure out how to make tables work in the forum post).
EDIT: Instead of straining your eyes, see the post further down with a much better version of this table. :)
(https://i.imgur.com/KLUkFMP.png)
Quote from: Danvzare on Mon 12/06/2023 14:41:07Unless we need to showcase how something can happen in one room and affect another. But that's the only exception I can think of.
Think of room as "location". Each of them could consist of more than one room in the ags sense. Unlocking a door could lead from "lockeddoorroom1" to "lockeddoorroom2" where the gem is to be found.
Yes, replace the "room" with "location" in the rule, and "location" may consist of number of rooms, if changing rooms is necessary to showcase something.
Quote from: RootBound on Mon 12/06/2023 15:13:14What does everyone think? (Apologies for the gigantic image -- couldn't figure out how to make tables work in the forum post).
You could upload a spreadsheet to any file hosting, like google drive, and post a link instead.
In regards to the table, I'm afraid this kind of configuration will result in lots of empty cells, and a waste of visual space. The "group" may be made as a single column, where you print a group's name (or a short tag), perhaps even with a colored background corresponding to a group.
It should be easy to sort the items, keeping them grouped by "group" value.
@Crimson Wizard Yes, thank you. I was looking for a way to make it more efficient and couldn't quite figure it out.
Here's a text version of the proposed feature groupings into rooms/locations:
Beginner 1, "Room Basics"
*Walkable areas (Walkable areas (incl. scaling & non-contiguous)
*Walk-behinds
*Hotspots
*Objects
Beginner 2, "Rooms part 2 and NPCs"
*Dark/light regions
*Scrolling rooms
*Animated backgrounds
*NPCs
*Dialogs
Beginner 3, "Inventory and animations"
*Inventory items
*combining items
*animated objects
*moving objects
*1st person interface room
Intermediate 1, "Sounds and Music"
*Sound effects
*Music
*Voice acting
Intermediate 2, "Keyboard use"
*Keyboard controlled movement
*Text input / text parser
Intermediate 3, "Complicating characters"
*Different views for player character
*Different playable characters
Advanced 1, "special effects"
*"Dark room" with flashlight
*reflections
*shadows
*Partially transparent or translucent effects / windows
Advanced 2, "modules"
*tween module
*Rellax module
*typewriter text module
*Other modules?
As stated above, we can contract / expand the grouping to different locations, whatever makes sense. If different features belong in different difficulty levels then I've done here, that's worth noting too. My intent is for this to be a draft we can revise together until it makes the most sense.
Nice collection,
@RootBound . My ideas in red:
Quote from: RootBound on Mon 12/06/2023 16:21:18Beginner 1, "Room Basics"
*Walkable areas (Walkable areas (incl. scaling & non-contiguous)
*Walk-behinds
*Hotspots
*Objects
*Inventory items - picking up a key will add it to your inventory
*Using inventory on objects/hotspots
Puzzle: Pick up a key, open a door, go to the next room.
Beginner 2, "Rooms part 2"
*Dark/light regions
*Walk-behinds
*Scrolling rooms
*Animated backgrounds
*animated objects
*moving objects
Possible puzzle: Activate a lever to move down an (animated) bridge, walk over to the other side of the scrolling room.
Beginner 3, "Inventory and characters"
*Inventory items
*combining items
*NPCs
*Dialogs
Possible puzzle: The NPC asks for a certain item. In the room there are some items that can be picked up, two have to be combined then give it to the NPC. Should include a somewhat elaborate dialog tree.
Beginner 4(Intermediate?)
*1st person interface room
Intermediate 1, "Sounds and Music"
*Sound effects
*Music
*Voice acting
Intermediate 2, "Keyboard use"
*Keyboard controlled movement
*Text input / text parser
Intermediate 3, "Complicating characters"
*Different views for player character
*Different playable characters
Intermediate 4, "Timers"
*Using timers
*rep_execute_always
Advanced 1, "special effects"
*"Dark room" with flashlight
*reflections
*shadows
*Partially transparent or translucent effects / windows
Advanced 2, "modules"
*tween module
*Rellax module
*typewriter text module
*Other modules?
@cat I think those are good improvements. There were so many "beginner" concepts I wasn't quite sure of the best way to group them. :)
Some more story-oriented ideas:
I think a fun idea could be that the "beginner 1" puzzle could be a "trap door shuts behind you" situation, so that it makes sense to enter the room and then be trapped.
I like your bridge puzzle for room 2 as well. Since it's animated backgrounds in that room too, maybe the bridge leads over a small river, and following the scrolling room eventually brings you to a waterfall. Both river and waterfall could be part of the animated background.
An NPC requiring something that you have to make by combining items could go all sorts of ways--I'm thinking of some kind of workshop (like a machine shop, inventor's lab, magic spell-brewing kitchen, or some other place that would have lots of interesting objects laying around.
Quote from: RootBound on Mon 12/06/2023 20:40:09Since it's animated backgrounds in that room too, maybe the bridge leads over a small river, and following the scrolling room eventually brings you to a waterfall. Both river and waterfall could be part of the animated background.
Nice! And if the scene is at night, we also got the dark/light regions covered with moon shine and shadows.
Here's a partial draft of a 640x360 map/menu screen. I still have the multi-layer version, so text can be changed, things can be renamed, redrawn, moved around, etc.
Treehouse would be the locked door puzzle, Stream would be the bridge puzzle, and Wizard's Hollow would be whatever puzzle involves dialogs and combining inventory items.
In this structure, every room would be accessible from the map and maybe have an "exit to map" icon as a GUI (or as an object in the room), but rooms could also be walked between from each other if the player wants, and would join to form a complete game world.
If people like it, I figure we can add room names as we figure out what puzzles might go with each room.
So the proposed process would be:
-look at what features are sorted into what particular room (@cat's post above)
-figure out a rough puzzle that uses those features
-invent rough room ideas based on that puzzle
-add room to map (I can do this or I can upload the .ase file somewhere)
-draw background for each room (different artists can contribute--whoever's interested)
(https://i.imgur.com/B1PtDLZ.png)
Wonderful map,
@RootBound !
I think the artist also depends on the style the room should be in. For some rooms it does not matter, but the "Keyboard use" room, for example, should be in retro style, so I see this totally made by someone like
@newwaveburritos Another idea I had - instead of filling the inventory up with useless gem items or similar, this could be done with a score counter. This way, also the score feature would be showcased.
Maybe not a bad idea to showcase a few different art styles since you can do whatever you want and as a game dev it's sort of easy to forget that. But I'm happy to contribute a background or some characters or really anything like that.
@cat I had the same thought about the score. A gem icon with 1/10 or whatever next to it and you're good to go!
I also had an idea about the NPC/Combining inventory puzzle. Maybe an NPC (like a Wizard) has a gem for you and will give it if you can complete a challenge that involves asking the right questions to discover which items in the room to pick up and combine. There could be other NPCs milling around (like students or apprentices), whose dialogs change based on what information you're looking for. For example, the wizard says "Make me a summoning circle that will call a goblin" or something, and only by asking lots of questions of everyone in the room can you figure out what items you need and how to construct them from all the simpler inventory objects in the room.
To keep the puzzle doable for newcomers, though, there probably shouldn't be any "dead ends" in the dialog, so that the puzzle is always solvable.
Is that the right difficulty of puzzle we're looking for at that point in the tutorial?
Quote from: RootBound on Wed 14/06/2023 16:40:24(https://i.imgur.com/B1PtDLZ.png)
I don't know if translation is a thing, but we should consider making the labels as separate sprites. The map could also be implemented as GUI with labels.
If it were me, I would suggest creating a bare-bones, minimalist demo game: One or two rooms, with everything needed for a traditional adventure game but nothing fancy going on. Release this separately (on github or similar) as "Demo Game - Basic." Arguably, this game should be the result you (can) get if you follow the AGS tutorial to the end.
Then use that as a basis for all other demonstrations: One version of the demo to demo each feature (or some small number of features), building on top of the common core. Same room, same gameplay, same everything (as far as possible), with the only changes those necessary to demonstrate the feature(s) in question.
And then create a merged project bundle of the most generally useful demo rooms, with some sort of menu to browse and navigate the different features demonstrated. Release this as "Demo Game - Advanced." (Alternatively, this could just be a website that would let you browse and play all the demos from within the browser.)
That way, a learner can see what an as-simple-as-possible AGS project looks like, and when trying to understand each more advanced feature, they will already recognize the basic bits and can focus on the changes.
It will also serve as a starting point for anyone who wants to demo something in AGS: a ready-made template that can be modified to show off whatever it is you want.
Key points:
-Project(s) kept as simple as possible, for pedagogic purposes
-Common core (code, assets, project setup): lower threshold of making future demos
-Extensible concept, not limited by an overall story/game design
-Integrate with documentation/tutorial, make playable online
Quote from: RootBound on Wed 14/06/2023 16:40:24(https://i.imgur.com/B1PtDLZ.png)
This looks great. I like the idea to use labels with the GUI, nice idea!
About tutorials its possible to do the reverse, make the game and then later reverse engineer it in a tutorial, but overall I really like the direction
@RootBound mind is going!
Quote from: Snarky on Fri 16/06/2023 17:16:26If it were me, I would suggest creating a bare-bones, minimalist demo game: One or two rooms, with everything needed for a traditional adventure game but nothing fancy going on. Release this separately (on github or similar) as "Demo Game - Basic." Arguably, this game should be the result you (can) get if you follow the AGS tutorial to the end.
I think Snarky has reasonable arguments, and initially I thought this is what would be done first (https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/crowd-sourced-of-an-open-sourced-ags-example-game-collaboration/msg636650712/#msg636650712), before going into more complex demos.
Overall I feel like I myself got somehow swindled from one idea to another. This happens way too often to me lately, I cannot stay focused on initial thought. But probably that's because I am not actually dedicated to the game design process, and only comment on what others are doing.
The kind of project discussed here may indeed be useful as a big feature demonstration, but I am not certain if it will work for a basic tutorial purpose.
Perhaps, I may propose to imagine you are the absolute beginner to AGS. Try to look at this with their eyes, and ask what do you expect from a "demo game", if your intent is to quickly start your own.
But I don't think I will be participating in this conversation, as I simply cannot stay focused on the problem well enough to provide reasonable contribution.
@Snarky Isn't that what each individual template should be? The BASS template already contains a few inventory items, a room, a character etc.
I think the demo game should go beyond the stuff of the basic tutorials.
I forgot to post this earlier, but here's a game I've been thinking about as of a reference:
https://archive.org/details/openquest
I don't remember all details, but iirc it's either 1 or 2 rooms game with a simple sequence of actions.
It was an original candidate for a new demo game back in mid-2010ies, at least in my mind, but it's made in AGS 2.72 and uses a number of obsolete features, so would need to be upgraded anyway.
EDIT: the archived version does not include the sources unfortunately, and I cannot remember if I had them anywhere.
Another example of a good "simple demo" style, at least imho, could be this game:
https://www.adventuregamestudio.co.uk/site/games/game/1208-awakener/
This is all just for the reference, to illustrate what I had in mind when proposing to make a simple demo game.
Quote from: cat on Fri 16/06/2023 16:56:35I don't know if translation is a thing, but we should consider making the labels as separate sprites. The map could also be implemented as GUI with labels.
You may have GUI with labels, but also a room with objects.
In case of a room you could make a mini-character going around the map, similar to Monkey Island 1 or Hero Quest. (It's theoretically possible to do on GUI, but then you will have to implement your own pathfinding)
In case of GUI, it's easier to setup textual items (with objects you'd have to create sprites, or dynamic sprites with translated text at runtime).
I can see the wisdom in the comments above with regard to keeping things simple and accessible. I had thought this thread was about a demo game to showcase a lot of what AGS is capable of, rather than a very basic simple-game tutorial. I can appreciate the value in both.
Perhaps
@Crimson Wizard was correct at the beginning that the "demonstrate many AGS features" and "demonstrate very basic AGS features" angles should be available separately (although the bigger project could include a version of the smaller).
If so, a possibly good way to proceed could be to start by making the first three "basic" rooms we've been discussing, then release those as the "basics-only" download (also playable online? This can be done simply by building to the web port?).
Work could then continue to extend the game into the "full-fledged" larger one with those same three basic rooms, plus medium and advanced. That way, it saves the work of doing two truly separate projects, and at the end, the basic and full versions are both available.
I also appreciate keeping the beginner more in mind generally, so maybe it would be good to modify the map/menu with some more user-friendly descriptions that make it even more accessible to someone who barely knows what AGS is.
First, the three "regions" could be re-titled as, e.g., "Village of Beginnings: AGS Basics for the beginner" and so on.
Second, there could also be a block of hover text over each room icon, perhaps providing a "difficulty level", a list of the game features showcased, and the room number in the editor where one can find the code and room setup.
This would be in addition to the help icon available in every room, which would expound upon each feature in more detail whenever the user desires.
I don't know if that reconciles the ideas of a basic and a more thorough demo game, but I gave it my best shot. :)
Well, we have to start somewhere anyway. Why not start with the beginner rooms and add intermediate stuff later on? If we find out that we need a separate project with only the first 3 rooms, we can branch off at an appropriate point later on.
Btw, I haven't been using the newer versions of AGS (been some time since my last game) - how easy is it now to collaborate? Is there still that huge sprite file that is impossible to merge? I.e. we need one dedicated person to take care of importing sprites? Or has this improved?
Quote from: cat on Sun 18/06/2023 10:33:18Btw, I haven't been using the newer versions of AGS (been some time since my last game) - how easy is it now to collaborate? Is there still that huge sprite file that is impossible to merge? I.e. we need one dedicated person to take care of importing sprites? Or has this improved?
No, nothing has improved. Rooms storage was improved but it's in AGS 4 alpha.
The only thing that makes it slightly easier with sprites is that now there's a "recreate sprite file from sources" command in the editor, which makes sense if the source images are stored inside the project folder.
And there's still a problem of sprite numbers: if they conflict then you cannot merge game.
But does this mean that the sprite file doesn't have to be checked in? I think this hugely improves collaboration. And size of the repository.
Quote from: cat on Sun 18/06/2023 15:37:56But does this mean that the sprite file doesn't have to be checked in? I think this hugely improves collaboration. And size of the repository.
That is true, it does not have to be checked in.
Although, you have to keep in mind that the spritefile recreation is basically a full reimport, and takes time proportional to the number of sprites and their resolution.
EDIT: Somehow I have a copy of this full-length game source in my temporary possession (i was doing some engine bugs research in it):
https://www.adventuregamestudio.co.uk/site/games/game/2330-mage-s-initiation-reign-of-the-elements/
This is a 640x400 game, with roughly 300 MB amount of sprites in png format.
I made a test on it, first exporting all sprites and remapping "source" link to these exports, and then tried full sprite file recreation.
Recreation takes about 30 seconds on my PC.
NOTE 2: this does not help with room bgs though, unless you are using ags4 where rooms are split into multiple files.
I tried out some VERY ROUGH PLACEHOLDER color blocking to propose a composition for the first room.
Obviously final version would be FAR higher quality.
Does this kind of design work?
*2 walkable areas: 1 continuously scaling (all paths are part of same area even though it is pieces); 1 fixed scaling (balcony).
*3 interactable hotspots to look for key (bench, toadstool, shrine)
*2 objects (door, gem on balcony)
*1 inventory item (key)
*1 possible object animation (door open/close)
*No walk-behinds needed
*No regions needed if light level is normal
*No animated background needed
(https://i.imgur.com/kBAzsAQ.png)
I like the overall concept and the hotspots to look for the key.
I think the door should open to a different room, it could be inside the treehouse. The many paths also seem a bit complicated, different walkable areas will be covered in the next room with the bridge.
Quote from: cat on Sun 18/06/2023 19:49:48I think the door should open to a different room, it could be inside the treehouse. The many paths also seem a bit complicated, different walkable areas will be covered in the next room with the bridge.
Hmm, I have an opposite opinion, imo it's fine to have a number of demonstrated features in one room so long as they don't disperse attention. This makes the demo more "condensed". If there's 1 feature per room, rooms will feel empty.
After all, rooms may be logically divided into visible sections, where each section has a noticeable feature.
If I understand correctly, the "bridge" room is the one where the walkable area gets disabled and enabled? This seems distinct enough to allow more than 1 walkable area in a previous room.
I.e.:
- room 1 shows that you may have several "locations" defined by walkable areas.
- room 2 shows that these areas may be manipulated with, turning them on and off, allowing to walk between; and then shows that you may have other kinds of regions too (looking at your feature list on the previous page).
That is, unless you insist on each room be dedicated strictly to 1 feature / game element and everything related to it.
But imo combining few things in one room makes a more curious exploration experience. This also makes things feel more natural, closer to real game.
The "inside the treehouse" was because I think the main point of room 1 is to show how to open a door and change to another room, a very basic and very important feature that is used in so many games.
Quote from: cat on Sun 18/06/2023 20:17:12The "inside the treehouse" was because I think the main point of room 1 is to show how to open a door and change to another room, a very basic and very important feature that is used in so many games.
Ah, I see.
I wonder if this will be fine if the interior of a treehouse had 2 exits, both leading to room 1, but one placing character at a door and another at a balcony. That would illustrate that you may use ChangeRoom to enter in different places even if you come from one room.
I can draw a revised room outline and simplify the walkable areas. I can also include an "inside the treehouse" mock-up as well. I'm going away for a few days, so that will probably be late next week.
One thing I've seen coming up in the forums, unrelated to any particular room, is different speech views. It seems like both LucasArts and Sierra with Portrait and Background would be useful to include in the demo, and having, for example, a "happy" speech portrait and a "sad" speech portrait for the same character might be called for as well. Maybe that should go in the "complicating characters" room listed above?
For just the first three rooms, probably sticking to one speech view is best, but it seemed worth mentioning.
Quote from: RootBound on Wed 21/06/2023 21:57:05I can draw a revised room outline and simplify the walkable areas. I can also include an "inside the treehouse" mock-up as well. I'm going away for a few days, so that will probably be late next week.
Awesome!
Other than that, I have no strong opinion about speech portraits.
I don't know if we're assigning roles or accepting volunteers yet. But I just want to say that I would gladly make all of the inventory items if you want them in a consistent style. :-D
I rather enjoy drawing inventory items, even when there's a lot of them. And if you've seen any of my games, you probably have an idea as to how I draw them. Just tell me what to draw, the size limitations, and palette limitations if any, and I'll make them. :-D
Then again, someone else might want to do it (or might be better suited for it). I just thought I'd throw my hat in the ring just in case. :)
@Danvzare I think the discussion here has settled on 640x360 as the game resolution, but I'm not really sure if the GUI discussion is still ongoing, so I don't know if the resolution for inventory item images is clear at the moment.
I doubt anyone in this thread is turning away volunteers, though! Right now the only inventory item I am aware of would be a key for the first room. But a gem image for the score counter would be welcome as well, I think (I'm certainly not in charge here!)
As far as pallette limitations go, I think the game has a generic fantasy theme. I'm working on designing forest and treehouse backgrounds but final colors are undecided, and I believe one goal is to show a variety of styles.
@cat any thoughts?
I think it is a good idea to have the GUI and inventory consistent in a rather universal style that fits the general fantasy setting. We will not change the UI graphics for every room.
A general color palette is an excellent idea. While different styles of background (pixel art vs. painted vs. 3D render) will look very different, a common palette that is used by all graphics and also the GUI will help to keep it together nicely. However, I'm really bad at making palettes, so this is nothing I can help with. Maybe create a draft and take it to Critics Lounge?
I'm not great at making palettes either, but I went looking through a bunch of them on Lospec and found a few I think might work:
CC-29 (https://lospec.com/palette-list/cc-29) by Alpha6 (29 colors)
Nanner Pancakes (https://lospec.com/palette-list/nanner-pancakes) by Afterimage (32 colors)
Apollo (https://lospec.com/palette-list/apollo) by AdamCYounis (46 colors)
comfy52 (https://lospec.com/palette-list/comfy52) by bess (52 colors)
I like the middle two best myself, but I can see the benefits of any of them.
I can post this in the Critics' Lounge if that's a better place.
I like Apollo. Do you know anything about license? Can we just use it?
Quote from: cat on Thu 29/06/2023 11:45:27Do you know anything about license? Can we just use it?
That's a good question. Couldn't find anything on the website, so I joined the Lospec Discord and asked the question there. Will let you know what I find out.
Seems like we're fine and that sets of colors can't really be licensed. The image itself depicting the palette maybe could be, but not the actual color scheme.
So if we want to use the Apollo palette and be nice and courteous, we could just add a line to the credits: "Game art uses Apollo palette by Adam C. Younis, available at Lospec.com."
EDIT: did some more digging, just to be safe:
This is from ColourLovers.com, not Lospec, but the priciple probably applies (emphasis mine):
QuoteHow can you copyright a color palette?
FAQ Home | How can you copyright a color palette?
We recently added a Rights Management System that allows members to select several different licenses for the content they share on COLOURlovers, including color palettes. There is often confusion about how somebody can copyright or protect the rights to a combination of colors. You can't really protect or copyright the usage of a combination of colors in new works. Ie, if you take a color palette and then draw an illustration using those colors. But, what is protected is the arrangement of those colors into the rectangular shape that they are on COLOURlovers displayed along with their names. This is treated like a picture or work of art and can be protected... ie, you can't just scrape a bunch of palettes and put them as they are displayed here in a book you sell.
Very interesting, thanks for investigating. I agree about giving proper credit.
So here are the Apollo colors in a totally non-protectable format (I used Notepad++ to create BBCode)
██████████████████████████████████████████████
As for usage, I would suggest the following:
- The GUI and inventory MUST use the exact palette colors
- Pixel art backgrounds and sprites should try to adhere to the palette if possible
- Painted backgrounds should use the palette as main colors and add others as needed
- 3d renders should use textures using mainly the palette colors.
I think this should make a somewhat consistent style while still allowing enough artistic license.
Regarding license: We should think about which license to use for the demo game so every contributor knows what happens with his or her submitted assets.
I think the code should be public domain. The purpose of this demo game is that you can copy parts of it and use it for your own game. Do we need some disclaimer about liability, though?
What about art and music assets? Should they be public domain as well? Or some CC attribution license?
Quote from: cat on Fri 30/06/2023 10:24:42What about art and music assets? Should they be public domain as well? Or some CC attribution license?
I think at least CC BY-NC license should be used (attribution + non-commercial use only), as contributors may not like their art to be reused in commercial games.
About other variants, they are briefly covered by this paragraph:
QuoteAll of our licenses require that users provide attribution (BY) to the creator when the material is used and shared. Some licensors choose the BY license, which requires attribution to the creator as the only condition to reuse of the material. The other five licenses combine BY with one or more of three additional license elements: NonCommercial (NC), which prohibits commercial use of the material; NoDerivatives (ND), which prohibits the sharing of adaptations of the material; and ShareAlike (SA), which requires adaptations of the material be released under the same license.
Giving attribution might be difficult, though. It will be hard to find out the author of a certain sprite. Maybe attribution should be made solely to "AGS Demo Game Contributor" and not each individual person. I hope artist are okay with that.
Of course, the game itself should contain an elaborate credits section that lists all contributors.
Quote from: cat on Fri 30/06/2023 13:17:52Giving attribution might be difficult, though. It will be hard to find out the author of a certain sprite. Maybe attribution should be made solely to "AGS Demo Game Contributor" and not each individual person. I hope artist are okay with that.
Of course, the game itself should contain an elaborate credits section that lists all contributors.
Sounds good to me. :)
Quote from: RootBound on Wed 28/06/2023 12:58:20Right now the only inventory item I am aware of would be a key for the first room.
Would something like this be ok: (https://twentyquidamusements.thecomicstrip.org/files/ags/fantasy_key.png)
I made it with the Apollo palette, and I tried to give it a fantasy style. Although being a key, there's not really much you can do in that regard. :-\
Looks good to me,
@Danvzare !
I'm trying to finish my MAGS entry today but hopefully after that I can keep working on the first room background.
Will post one more mock-up here for design feedback before drawing it in earnest. This is exciting! ;-D
Yeah, it's starting to get serious :)
I had another look at licenses and found the BSD 0-clause license we could use for code
https://en.m.wikipedia.org/wiki/BSD_licenses#0-clause_license_(%22Zero_Clause_BSD%22) (https://en.m.wikipedia.org/wiki/BSD_licenses#0-clause_license_(%22Zero_Clause_BSD%22))
It means the code is basically public domain, but without warranty. People can copy it freely to their projects but cannot blame us if it doesn't work.
Maybe I will talk with my colleague about it next week, he knows quite a bit about open source licenses.
I had a lot of free time today so I finished the next set of mockups. Used the Apollo palette to at least approximate a color scheme closer to what the final version may have.
As always, I'm happy to keep refining the designs if there are any aspects that don't work.
EXTERIOR SKETCH (below):
1 = a single continuously scaling walkable area. Skirts the edges to imply a larger space but doesn't make the player walk off the edge of the screen (maybe that can happen in the bridge room)
2 = door that needs key to open - leads to "inside" room
3 = door to emerge from "inside" room onto balcony where gem is
4 = garden bench (place to look for key)
5 = frog / mushrooms (place to look for key)
6 = shrine (place to look for key)
7 = exit (to map or to bridge room)
(https://i.imgur.com/spUoZqZ.png)
INTERIOR SKETCH (below):
1 = Exit to exterior room (door where key was used)
2 = A single non-scaling walkable area (overlaid here in translucent sky blue to show area boundaries)
3 = Exit to exterior room (balcony with gem)
(https://i.imgur.com/rBdewz0.png)
My main suggestion would be to not have paths too close to the room edges, and have some space between them (unless they lead outside the room of course). I'm pointing at locations 5 and 6 in the first room.
Do you have any kind of a character's placeholder sprite, which could be used for the size reference?
Good point, we should decide on a main character sprite first. Should we use this https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/let-s-build-a-new-ags-demo-game!/msg636655297/#msg636655297 (https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/let-s-build-a-new-ags-demo-game!/msg636655297/#msg636655297) Roger mage to begin with? We can always recolor him or change his appearance.
Quote from: Crimson Wizard on Mon 03/07/2023 03:33:41My main suggestion would be to not have paths too close to the room edges, and have some space between them
Okay, I can do that!
Quote from: cat on Mon 03/07/2023 09:22:27Roger mage to begin with? We can always recolor him or change his appearance.
The full sprite sheet for the mage is available here: https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/some-free-sprites-to-play-with/
I was talking with my colleague about the license. He said that it should be okay to use different licenses for art and code, we just have to write a custom license file. His only concern was that if we use the BSD 0 license, we also do not keep any rights of the name. I don't know if this is really important.
Another organisational question:
I noticed that there is already a repository for an AGS demo game. How should the new demo game be hosted and handled?
Quote from: cat on Fri 07/07/2023 15:52:59I noticed that there is already a repository for an AGS demo game. How should the new demo game be hosted and handled?
Having it under source control is a must, but it does not have to be in the same existing repository from the start.
I suppose that after the new demo game reaches working state, it may be copied over to the official ags repository, replacing old game (and old game may be left in a backup branch).
Wouldn't copying the source to another repository remove the version history of the new development?
Quote from: cat on Sun 09/07/2023 08:03:35Wouldn't copying the source to another repository remove the version history of the new development?
There are various options here:
- copy source files;
- copy whole git repository contents, with history;
- clone (fork) wip repository.
There's an option to rename previous repository to "Old Demo Game" and free "Demo Game" title. Or not rename anything, and call new repository "Demo Game 2023" or something.
Ok, I'll think about it. I'll be quite busy the next few weeks. I hope I can set up a basic project structure in August.
Btw, you can of course continue doing art and planning - no waiting for me required!
Finally found some time to keep working on the background now that my own game launch has died down. Here's the progress so far:
(https://i.imgur.com/CecAiwH.png)
Quote from: RootBound on Mon 11/09/2023 16:47:19Here's the progress so far:
I have same opinion that I mentioned in regards to the previous sketch (https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/let-s-build-a-new-ags-demo-game!/msg636656125/#msg636656125) in regards to the "shrine" location.
Having such a sharp turn backwards right near the room edge will be inconvenient, and also makes the room composition look bad, in my opinion. If it's a small non-scrolling room, then imo it's best to have every place accessible in a direct or semi-direct route from the central opening.
Quote from: Crimson Wizard on Mon 11/09/2023 22:02:28it's best to have every place accessible in a direct or semi-direct route from the central opening.
Would this work better?
(https://i.imgur.com/fsEXXon.png)
Quote from: RootBound on Tue 12/09/2023 02:27:22Would this work better?
I'm sorry for delayed response; yes, I think this might work better.
Hey, I just stumbled upon this one by chance and I love the idea.
For months now, my plan was to propose start making fresh new tutorials for AGS when I finished my first game here, as part of giving back for all the help, patience and kindness I'v encountered in this community.
It came to me because of a demo Crimson Wizard released a while ago (with mirrors, split screen, action,...)
The code was free to use and open source and all that but I wish some tutorial would've explained the whole thing step by step.
Otherwise, the code being very advanced, ""nobody"" would ever use it and all that work for ""nothing"".
I already had some plans started for making beginner tutorials (and a big idea), but I have to finish my game first. :P
I read the thread and I can see this is moving along nicely.
So I'd be glad to help out for this Demo Game project, depending on what you need and what I can do. (nod)
Cheers!
The background still isn't finished (and I haven't even started the interior) but little by little I am making progress. Here's a detail from it, just because I'm happy about this little 13x9 pixel frog. :)
(https://i.imgur.com/PzoqIUZ.png)
Finally finished the room background! (Here's hoping the interior room doesn't take me as long!)
So this is what the room would look like when the player enters it:
(https://i.imgur.com/a28gZhb.png)
HOWEVER, because the doors need to open and close, the actual ROOM BACKGROUND IMAGE would be this:
(https://i.imgur.com/KbGtpal.png)
My thinking is that the purple balcony fence and the leaves above it can be a walk-behind, and both the player and the door object can appear behind it.
Here are the images for the open and closed doors:
Front door (left is closed, right is open)
(https://i.imgur.com/zcrfZdZ.png)(https://i.imgur.com/N6s8oxa.png)
Upper door (left is open, right is closed)
(https://i.imgur.com/xytSUNQ.png)(https://i.imgur.com/GnPmiBh.png)
The door images have a larger transparent area behind them so that whether the door is open or closed, the door object does not need to have its coordinates moved - it would simply have its sprite changed.
The result would look like this:
(https://i.imgur.com/lrAfJeP.png)
I can also upload the doors merged into the background layer if that's preferable. I have everything separated in the .ase file.
How is this looking?? I'm feeling pretty happy with it. :)
I think this is looking wonderfull and mysterious! (nod)
Yes, this is looking nice :).
Is frog going to be an animated object?
Quote from: Crimson Wizard on Sat 25/11/2023 01:03:17Is frog going to be an animated object?
Maybe! If the player clicks on it, the frog could perhaps make a noise and puff itself up.
There, that wasn't too difficult! (Only the first 3 frames are unique).
(https://i.imgur.com/6gKeXOk.png)
And this is a public domain (CC0) frog sound:
https://freesound.org/people/egomassive/sounds/536759/
You might want to use some of these sound effects for the demo, some of them are copyrighted so only can be used for AGS demo.
https://drive.google.com/drive/folders/15A332gdltwEha2MpfrIOaewdDX2jOPJB
The footsteps sounds might be irrevelant since I'm not sure what the path outside is made of. Also their speed needs to be adjusted with characters walking speed. Usually SFX is one of the last things one does. But we'll, I hope some of them will be useful for the demo.
In MHO opinion there are too many opinions and it seems that's why the demo is taking longer than the engine. Can't engine developers come to a conclusion what they need to be in the demo (which offers more than previous demos), then somebody write a story, somebody does the art and somebody does the scripting. Lots of people here make great games for MAGS in less than a month excluding me. Feel free to ignore MHO, because there are already too many opinions in MHO.
Quote from: lapsking on Tue 26/03/2024 16:54:23In MHO opinion there are too many opinions and it seems that's why the demo is taking longer than the engine.
The demo is taking long, because a) nobody is in charge, b) nobody is working on it; simple like that.
Every project needs a director, who would take a responsibility of making a plan and organizing other participants.
From what I see, this demo project does not have a director. That's why it looks like "too many opinions", and having little progress.
Quote from: lapsking on Tue 26/03/2024 16:54:23Can't engine developers come to a conclusion what they need to be in the demo
Why do engine developers have to do this?!
For example, I am not even making games with AGS, I might be wrong about what's causing most issues with it, and don't know what troubles do beginners have. I could have made a mistake by participating in this discussion at all.
I was reading through this thread since Crimson Wizard mentioned it elsewhere and wondering whether to bump it, but lapsking beat me to it. I'd like to help out on this project if I can.
@cat @RootBound and
@Danvzare seem to be the main contributors so far (also CW, but he seems to keep trying to leave and getting dragged back in :grin:). I guess the question is are you still interested in working on this?
* The demo is taking longer than the engine, because nobody is working on it; simple like that.
Well, maybe just simplify it story-wise and art-wise. Even Zack's Adventures graphics are good enough to do the job. It's a game making engine (open-source) with no fundings. The game engine is not responsible to showing off graphics because it's not Microsoft Paint. We have to deal with graphics in other programs. Story-wise it can be as silly as smeone who wants to go out shopping but doesn't remember where his wallet is as usual. AGS doesn't need to show how someone is supposed to write a story. Most probably whoever ends up using AGS have tried few great AGS made games that has ended up trying the engine. To be honest Yaheetzee's games attracted me to AGS about almost 2 decades ago. I was just to busy with other things plus didn't have the push to start till few years ago. So seriously story and art is not a problem. People need to learn engine capabilities which doesn't need brilliant art or story. The graphics can be as rough as those adventure games we had to type verbs and sentences to get a task done. Just a bit more up-to-date than text adventures. Anyway, it shouldn't be your job. But makes everything faster.
* Can't engine developers come to a conclusion what they need to be in the demo. Why do engine developers have to do this?!
I suppose because you are making the engine. You know about the features better than anyone else. I mean in previous posts you were actually giving directions but got distracted by all this hustle and bustle. You don't make games but you know what to do, so others can make games. Nobody knows about the features of the engine as much as you do. You actually wrote what you think should be included in demo. To be honest actually there isn't much problem. But there are things that can be done to make our life easier. For example I remember when on Tumbleweed Timbleweed whatever template I changed the resolution to 1920x1080 the whole dialog GUI became a mess. Maybe I need to learn programming. But then the main bonus of AGS was it's user friendly interface which made it so attractive for random people around the world end up using it. Personally my problem wasn't demo. But if you gift us with a new feature like 1920x1080 resolution what about the messed up GUI on the template. I even don't remember how I sorted it out, it took me more than a week. Just being stubborn I guess, trying everything 1 by 1 randomly. But I think AGS developers shouldn't forget about user-friendly interfaces in AGS 4 for their new features. But anyway, it seems the engine is working thank to tutorials splashed all over the place and kind people in the forums. We are just giving feed back, don't see it like we have expectations. I'm personally more than grateful for everything.
Quote from: OneDollar on Tue 26/03/2024 21:58:17I was reading through this thread since Crimson Wizard mentioned it elsewhere and wondering whether to bump it, but lapsking beat me to it. I'd like to help out on this project if I can. @cat @RootBound and @Danvzare seem to be the main contributors so far (also CW, but he seems to keep trying to leave and getting dragged back in :grin:). I guess the question is are you still interested in working on this?
I think Wizard has done most of his job already, he almost wrote down which engine features he thinks should be there, but maybe he just needs to adjust it with AGS 4.0. I don't think there is much point in releasing a demo for AGS 3.6 anymore with 4 being in development. Maybe Cat wants to be kind enough to come up with the story or finish off the current idea. Rootbound maybe can do the art if he is generous enough, or both art and story. And Danvzare writes the script. I don't know. Or Maybe one person aka OneDollar does everything to make it more practical and faster if he has the time, sure will be remembered as a hero among newbies and in my memory. I'll give you Thai massage to keep you going. (laugh)
Quote from: lapsking on Tue 26/03/2024 22:14:27* Can't engine developers come to a conclusion what they need to be in the demo. Why do engine developers have to do this?!
I suppose because you are making the engine. You know about the features better than anyone else. I mean in previous posts you were actually giving directions but got distracted by all this hustle and bustle. You don't make games but you know what to do, so others can make games. Nobody knows about the features of the engine as much as you do. You actually wrote what you think should be included in demo.
I can tell about the features and how to use them. I can have an idea of what could be in the demo.
But if I will be the one making requirements for the demo, then I will also have to take responsibility of overviewing the progress and result of this work, demand corrections, and basically do management tasks. This will be an additional responsibility for me, which I cannot take now. Besides other things, I'm not in the right state of mind to do this. I'm tired of worrying of things being not how I expected them to be, and have grown weary of arguing with people.
Quote from: lapsking on Wed 27/03/2024 08:21:12he almost wrote down which engine features he thinks should be there, but maybe he just needs to adjust it with AGS 4.0. I don't think there is much point in releasing a demo for AGS 3.6 anymore with 4 being in development.
The basics are still the same in AGS 4.0, and at least half of new features in 4.0 are meant for advanced users. The demo made for 3.6.* will still be usable and useful in 4.0. If a 3.6 version is created, making a 4.0 version would be a matter of adding more stuff to it, like new chapters.
Quote from: lapsking on Wed 27/03/2024 08:21:12To be honest actually there isn't much problem. But there are things that can be done to make our life easier. For example I remember when on Tumbleweed Timbleweed whatever template I changed the resolution to 1920x1080 the whole dialog GUI became a mess.
So, this is a whole different issue then. One problem is that AGS does not support scaling GUIs; that's something that may be added to the TODO list for AGS 4. If there are more problems with "user friendliness" like that, then they also have to be written down and discussed.
Here's a forum thread that I opened for gathering list of major problems that would be nice to solve in the future:
https://www.adventuregamestudio.co.uk/forums/editor-development/ags-4-roadmap-discussion/
Quote from: Crimson Wizard on Wed 27/03/2024 10:25:14Quote from: lapsking on Tue 26/03/2024 22:14:27* Can't engine developers come to a conclusion what they need to be in the demo. Why do engine developers have to do this?!
I suppose because you are making the engine. You know about the features better than anyone else. I mean in previous posts you were actually giving directions but got distracted by all this hustle and bustle. You don't make games but you know what to do, so others can make games. Nobody knows about the features of the engine as much as you do. You actually wrote what you think should be included in demo.
I can tell about the features and how to use them. I can have an idea of what could be in the demo.
But if I will be the one making requirements for the demo, then I will also have to take responsibility of overviewing the progress and result of this work, demand corrections, and basically do management tasks. This will be an additional responsibility for me, which I cannot take now. Besides other things, I'm not in the right state of mind to do this. I'm tired of worrying of things being not how I expected them to be, and have grown weary of arguing with people.
Quote from: lapsking on Wed 27/03/2024 08:21:12he almost wrote down which engine features he thinks should be there, but maybe he just needs to adjust it with AGS 4.0. I don't think there is much point in releasing a demo for AGS 3.6 anymore with 4 being in development.
The basics are still the same in AGS 4.0, and at least half of new features in 4.0 are meant for advanced users. The demo made for 3.6.* will still be usable and useful in 4.0. If a 3.6 version is created, making a 4.0 version would be a matter of adding more stuff to it, like new chapters.
Quote from: lapsking on Wed 27/03/2024 08:21:12To be honest actually there isn't much problem. But there are things that can be done to make our life easier. For example I remember when on Tumbleweed Timbleweed whatever template I changed the resolution to 1920x1080 the whole dialog GUI became a mess.
So, this is a whole different issue then. One problem is that AGS does not support scaling GUIs; that's something that may be added to the TODO list for AGS 4. If there are more problems with "user friendliness" like that, then they also have to be written down and discussed.
Here's a forum thread that I opened for gathering list of major problems that would be nice to solve in the future:
https://www.adventuregamestudio.co.uk/forums/editor-development/ags-4-roadmap-discussion/
I don't know exactly what's going in one's like including my own. You are doing more than what one should does. And I totally understand why you try your best not to get dragged into the matter. But it seems how the demo production was going on has a problem. As I said in the beginning (which wasn't directed at you) IMHO there are too many opinions. Everybody doing everything and nothing. While IMHO it's better to trust someone on the management and someone on the game making and let it go. Also simplifying everything. Usually people prefer to make art for their own stories. So maybe these responsibilities should be merged. I'm currently avoiding any opinions because I'm 24 hours in conflict with my own opinions as you can see! No room for an outsider opinion or might never get anywhere. So I totally understand if anyone wants to avoid my opinion too. I don't how I can be useful in the matter beside ranting, because there are already lots of people willing to participate. Doesn't look like my fART or story is much needed here. Danvzare or OneDollar can get the whole thing done in a month or so.
It will be great to add GUI scaling to TODO list for AGS 4. Thank you Wizard. I mentioned it here because it was referring to first post by PPAentertainment I replied to but ended up coming out in an irrevelant place.
Cheers
I can't help but point out that under the approach I suggested—a very simple, barebones demo game (for example taking the BASS template as a starting point), extended to make separate demos for individual features—this would not have been a problem; anyone could quickly make a demo for whatever they liked, and there wouldn't be a need to agree on anything.
Quote from: lapsking on Wed 27/03/2024 10:58:25It will be great to add GUI scaling to TODO list for AGS 4.
As I mentioned in another thread (https://www.adventuregamestudio.co.uk/forums/index.php?msg=636659073), I think this can be implemented fairly easily in a module without adding it as an engine feature—and therefore I don't think it
should be added to the engine.
Sorry for keep ranting but I have an idea if it doesn't make things more complicated. Why not dedicating a MAGS to AGS demo? Without story or any other limitations, the topic can be AGS demo with a list of features that needs to be integrated or something. Whoever wins the MAGS, his game will be used as the demo and if needs a bit more editing people can discuss it when they vote or something.
Edit: you can give it a topic for the story too if it makes it more interesting or just optional or without any topic. The previous winner can give the topic for AGS demo or just one month gap without topic dedicated to AGS demo. I don't think I can win MAGS again to be able to choose the topic, that one was pure luck. But if I could, I would just win for the sake of choosing AGS demo for next month.
Quote from: Snarky on Wed 27/03/2024 13:05:51As I mentioned in another thread (https://www.adventuregamestudio.co.uk/forums/index.php?msg=636659073), I think this can be implemented fairly easily in a module without adding it as an engine feature—and therefore I don't think it should be added to the engine.
Well, the scaling property may be useful for dynamic effects, it's an expected feature of game objects in contemporary engines. In AGS 4 GUIs may already be
rotated, added as a part of rotation feature support (with correct handling of click coordinates for interaction), I don't see why won't they be scaled.
Quote from: OneDollar on Tue 26/03/2024 21:58:17@cat @RootBound and @Danvzare seem to be the main contributors so far
Cat and RootBound, yes, definitely. Me... all I've done is made a single simple inventory icon. :-[
That being said, I'm still for making all of the inventory items. Just tell me what to make. :-D
Or if there's some other way I can contribute.
@Danvzare we still need an inventory item image for the gem to be picked up, if you like.
@lapsking because the demo game will hopefully have wide open-source distribution, we want to be very careful about licensing, so it would be best if sound effects were public domain. I realize that's more work, but we do want to be as careful as possible. :) That said, I forgot we may also want a frog rabbit sound.
Quote from: RootBound on Thu 28/03/2024 13:56:02@lapsking because the demo game will hopefully have wide open-source distribution, we want to be very careful about licensing, so it would be best if sound effects were public domain. I realize that's more work, but we do want to be as careful as possible. :) That said, I forgot we may also want a frog rabbit sound.
I'll send you the toad and hare and whatever sound effects you need after the game came to existence. You shouldn't be worried about SFX right now.
You can also add some mushrooms to your rose garden ;)
That's how one turns story upside down just with SFX. You keep working on backgrounds and story meanwhile. Do your best. Make it the biggest mock-up for eternity. You'll go down into history. You are already getting there without the game.
Quote from: RootBound on Thu 28/03/2024 13:56:02@Danvzare we still need an inventory item image for the gem to be picked up, if you like.
How are these?
(https://twentyquidamusements.thecomicstrip.org/files/ags/gem.png) (https://twentyquidamusements.thecomicstrip.org/files/ags/gem2.png)
If you'd prefer a different shape or colour, just say and I'll redraw it. :-D
I think they look a little flat, but I suppose that's just the nature of cut gems.
I think they look a little flat.
[/quote]
Looks as flat as Persian Carpets which influenced Gauguin's flat paintings. Well done, now I think you know better how your inventory item is.
@Danvzare the gem looks great. Is it using the color palette from earlier in the thread? If not, that's the only change I would suggest. :)
Quote from: RootBound on Thu 28/03/2024 14:42:37@Danvzare the gem looks great. Is it using the color palette from earlier in the thread? If not, that's the only change I would suggest. :)
I think the gem looks better with the contrast. Maybe even a bit more contrast.
I'd also like to suggest a GUI since it's one of the only big decisions left before we could cobble together a prototype:
1) A small menu button in one corner of the screen. Click it to open a menu bar that contains save, load, and exit options, and an inventory window.
2) two-click interface with no need for scrolling through modes. Left click to walk, interact, or talk to (determind automatically depending on whatis under the cursor), or use inventory (if active). Right click to put away inventory or examine.
3) code this in a fairly simple way that does not require a separate two-click handler script, so as to keep the code accessible to newcomers.
Any thoughts, suggestions, changes?
I mean really, you haven't came to conclusion with these things yet but you have found your eternal toad voice? I think you guys were much faster and successful without me. I'm leaving, have fun.
@lapsking, sorry, I forgot I had already found that sound file. This thread wad inactive for a couple months and I should have gone back and re-read it. Apologies.
Quote from: RootBound on Thu 28/03/2024 16:19:25I'd also like to suggest a GUI since it's one of the only big decisions left before we could cobble together a prototype:
1) A small menu button in one corner of the screen. Click it to open a menu bar that contains save, load, and exit options, and an inventory window.
2) two-click interface with no need for scrolling through modes. Left click to walk, interact, or talk to (determind automatically depending on whatis under the cursor), or use inventory (if active). Right click to put away inventory or examine.
3) code this in a fairly simple way that does not require a separate two-click handler script, so as to keep the code accessible to newcomers.
Any thoughts, suggestions, changes?
IMO that sounds good. I know there are concerns about two button interfaces, but I don't think the demo should be embedded in a website or played on mobile. It's not a demo of "Here's what the engine can do, download it now", it's a "Here's how to make all the basic features of an adventure game work". Users should be downloading it alongside the editor (ideally installing as an option alongside the editor), opening and running from inside the editor, while also going through the scripts to figure out how that thing they just saw works. In that context it's being played on a computer and I think it's fairly safe to assume two buttons are available?
As a catch all you can add
4) Use an inventory item on itself to put it away.
5) Don't build puzzles that
require examining items.
There were also conversations about using one of the existing interface templates as a starting point. My argument against that is a) they already have their own demos and documentation, b) the simplest template is probably BASS and that has some legacy bagage with its naming (TwoClickHandler, Lightweight BASS Stub) and extras we might not want (inventory pop-up), and c) it might be easier to comment code written for specifically for this project?
Feel free to disagree, I know I'm wading in here to something you've been kicking around for months.
Quote from: RootBound on Thu 28/03/2024 14:42:37@Danvzare the gem looks great. Is it using the color palette from earlier in the thread? If not, that's the only change I would suggest. :)
Yep, it's using the palette.
Quote from: lapsking on Thu 28/03/2024 14:49:30I think the gem looks better with the contrast. Maybe even a bit more contrast.
Ok, will do.
(https://twentyquidamusements.thecomicstrip.org/files/ags/gem3.png) (https://twentyquidamusements.thecomicstrip.org/files/ags/gem4.png)
More contrast, and still using the same apollo palette. :-D
I've been working on the "inside the tree house" background more, and it's almost done.
I still need to finish the sketched out areas (alcoves on second floor and chandelier).
If anyone has any requests for changes, please let me know. :)
(https://i.imgur.com/UGzlx1X.png)
ALL RIGHT PEOPLE, HERE WE GO...
Sorry, indoor voice.
I built a working prototype! I've tried my very best to put everything people wanted into this build, so that is not *my* demo game but *our* demo game, as discussed in this thread. So without further ado...
AGS QUEST: AN AGS DEMO GAME (download link below)
(https://i.imgur.com/LuGuhOR.png)
(https://i.imgur.com/NOy5DLD.png)
Please test it, read through the comments in the code, see how it feels with regard to everything that's been discussed in this thread. Is this demo a good represenatation of the most basic features AGS has to offer? Is it too complicated? What's working well here? What's not? The more feedback the better!
You'll notice the GUI graphics are all default--this is because I really couldn't tell if there was any agreement about GUIs, so if the GUI needs to change, it certainly can be!
If you have any suggestions for refining the code, feel free to copy and paste them here. That way I can merge everything without ending up with a bunch of different versions of the game.
DOWNLOAD GAME PROJECT FOLDER HERE (https://www.mediafire.com/file/3lygtdk249how7j/AGSQuestUncompiledProject.zip/file) (UPDATED WITH BUG FIXES FROM BELOW).
That's looking beautiful!! (nod) Love that frog (laugh)
When I'm on the balcony, I can interact with the entrance door, open or close it.
Also from the balcony, if the door is open and I click to enter, I will walk down trough the tree and then enter.
If I use the key to leave the house, once outside I can't go back inside or select the key in the inventory and the cursor is stuck on Walk mode.
Quote from: Rik_Vargard on Sun 07/04/2024 16:25:22When I'm on the balcony, I can interact with the entrance door, open or close it.
Also from the balcony, if the door is open and I click to enter, I will walk down trough the tree and then enter.
If I use the key to leave the house, once outside I can't go back inside or select the key in the inventory and the cursor is stuck on Walk mode.
@Rik_Vargard I fixed both of these, and thanks to you pointing them out I also found a fixed a third bug (clicking on the forest exit from the balcony still played the ending). Thank you very much for testing! It's much appreciated.
HERE IS THE UPDATED VERSION: https://www.mediafire.com/file/3lygtdk249how7j/AGSQuestUncompiledProject.zip/file
The original link above has also been updated to reflect the bug-fixed version.
In addition, for anyone who wants to suggest changes to the design, code, or code comments, here is a handy copy of the SCRIPT FROM EACH ROOM, along with a screenshot:
ROOM 1: SPLASH SCREEN
Spoiler
(https://i.imgur.com/ukUOYgX.png)
// room script file
//If you look at the Blue Mage character, you will see that the character's starting room is room 1 (this room).
//If you open the room editor for this room, you'll see that the room property "Show player character" is set to FALSE.
//This can be useful for menu rooms, close-ups of small room areas, or anywhere else the player character might be hidden.
function room_Load() //This function is called when the room first loads, before it fades in.
//To create this function, go to room actions (lightning bolt icon) and find "Enters room before fade-in."
{
gSubtitle.Centre(); //Positions the GUI gSubtitle in the middle of the screen.
}
function room_AfterFadeIn() //This function is called when the room is fully faded in.
{
WaitMouseKey(GetGameSpeed()*2); //Pause script for two seconds, unless a mouse button or key is pressed.
player.ChangeRoom(2); //switch player to room 2.
}
ROOM 2: MAIN MENU
Spoiler
(https://i.imgur.com/ZeJjqNe.png)
// room script file
function room_Load()
{
gSubtitle.Visible = false; //Hide the text GUI that was visible in the previous room.
gTitleMenu.Visible = true; //Show the title GUI.
Mouse.Mode = eModePointer; // Set mouse mode as pointer
}
ROOM 3: FOREST
Spoiler
(https://i.imgur.com/LuGuhOR.png)
// room script file
bool IsDoorLocked = true; // define variable for door state
function room_Load() // called before the room fades in
{
gDescriptions.Visible = true; // hover text GUI at bottom of screen
oGem.Scaling = 25; //Adjust size of gem object
if(player.x == 90 && player.y == 130){ // if player is entering from balcony
oDoor2.Graphic = 10; // make sure balcony door is open
}
}
function room_FirstLoad() // called only once, after the first time the room fades in
{
StartCutscene(eSkipAnyKey); //start cutscene, allowing keyboard to skip
cBlueMage.Walk(360, 176, eBlock, eWalkableAreas);
cBlueMage.Say("That looks like the Red Mage's treehouse.");
cBlueMage.Say("He said he'd leave a key outside for me somewhere.");
cBlueMage.Say("I guess I'd better look for it.");
EndCutscene(); // skipping cutscene will skip to here
Display("Click on different parts of the room to walk, examine, and interact with your environemnt.");
gGameMenuOpener.Visible = true;
// In-Game menu opener GUI. The properties of this GUI have it set to appear in the bottom right corner of the screen.
}
function room_AfterFadeIn() //called immediately after the room fades in
{
Mouse.Mode = eModeWalkto;
}
function room_RepExec() // Lines here get run every game loop, unless the game is in a blocking state
{
//No repetitive actions were needed in this room.
}
function hBench_AnyClick() // called when player clicks on bench (this function is created by hBench hotspot properties in room editor)
{
if(player.y < 270){ // if player is far away from the hotspot
player.Say("I need to get closer.");
}
else{ // if player is closer
player.Walk(88, 286, eBlock, eWalkableAreas);
player.FaceDirection(eDirectionLeft);
if(player.HasInventory(iKey)){ // called if player already has key
player.Say("There's nothing under it now.");
}
else{ // called if player doesn't have key yet
player.Say("A stone garden bench.");
player.Say("It looks like there's something under it.");
player.Say("Aha! This is the key the Red Mage left for me.");
gInGameMenu.Visible = true; // Show the inventory GUI so that
WaitMouseKey(GetGameSpeed()); // the player sees the item when it
player.AddInventory(iKey); // becomes added. Add inventory item. Play powerup sound.
aPowerup_by_maodin204.Play(); // Then hide the GUI afterward.
WaitMouseKey(GetGameSpeed()); //
gInGameMenu.Visible = false; //
player.Say("Now I should be able to get into the treehouse.");
}
}
}
//Next few functions are called when player clicks on the different hotspots in the room.
//Created from each hotspot's properties pane.
function hPond_AnyClick()
{
player.Say("A pretty garden pond.");
player.Say("I don't thonk the Red Mage would make me dig through water for the key, though.");
}
function hFlowers_AnyClick()
{
player.Say("Flowers that bloom only at night.");
player.Say("They make the grounds feel magical without needing magic.");
}
function hForest_AnyClick()
{
if(player.y > 135){ //if player is not on balcony
if(player.HasInventory(iGem)){ // called only if the player has the gem inventory item
player.Say("I suppose my tasks in this forest are done.");
player.Walk(416, 144, eBlock, eWalkableAreas);
gCredits.Visible = true; // open credits GUI
Mouse.SetBounds(gCredits.X, gCredits.Y, gCredits.X+gCredits.Width, gCredits.Y+gCredits.Height); // lock cursor over GUI
}
else{ // called if player does not have gem
player.Say("The path leads back where I cam from.");
player.Say("I'm not ready to leave yet.");
}
}
else{ // if player is on balcony
player.Say("I need to get down to the ground if I want to leave.");
}
}
function hBalcony_AnyClick()
{
if(player.y > 135){ // if player is at ground level
player.Say("I expect that balcony has a lovely view.");
player.Say("I can't get there from here.");
}
else{ // if player is at balcony level
player.Say("It is indeed a lovely view from up here.");
}
}
function hShrine_AnyClick()
{
if(player.x < 250 || player.y < 260){ // if player is far away from the hotspot
player.Say("I need to get closer.");
}
else{ // called every time the player clicks while close enough
player.Walk(565, 260, eBlock, eWalkableAreas);
player.FaceDirection(eDirectionUp);
// called only the first time the player clicks while close enough
if(Game.DoOnceOnly("First shrine click")){
player.Say("It's a shrine to the mystical source of the magic we mages use.");
player.Say("We respect our magic and don't use it lightly.");
player.Say("This is a place to honor that.");
WaitMouseKey(GetGameSpeed());
player.FaceDirection(eDirectionDown);
}
//back to every time the player clicks while close enough
player.Say("The shrine adds a meditative ambiance to the garden.");
player.Say("There doesn't appear to be a key here.");
}
}
function hToadstools_AnyClick()
{
if(player.y < 260){ // if player is far away
player.Say("I need to get closer.");
}
else{ // if player is closer
player.Walk(100, 340, eBlock, eWalkableAreas);
player.Say("Very large toadstools. Probably poisonous.");
player.Say("A great place to hide a key, but there isn't one under any of them.");
}
}
function hWindow_AnyClick()
{
if(player.y < 276){ // if player is far away
player.Say("I need to get closer.");
}
else{ // if player is closer
player.Walk(112, 280, eBlock, eWalkableAreas);
player.FaceDirection(eDirectionUp);
player.Say("The window is a little high up.");
player.Say("And anyway, it would be rude to spy.");
player.Say("After all, the Red Mage said he'd leave a key for me.");
}
}
function hTreehouse_AnyClick()
{
player.Say("It's a majestic home. I look forward to experiencing the inside.");
}
//click on frog object
function oFrog_AnyClick()
{
if(player.y < 260 || player.x > 250){
player.Say("I need to get closer.");
}
else{
aFrog_by_egomassive.Play(); // play frog sound effect
oFrog.SetView(2); // allows frog object to access the desired animation
oFrog.Animate(0, 5, eOnce, eBlock); // animate frog
}
}
//click on front door object
function oDoor1_AnyClick()
{
if(player.y < 135){ // if player is on balcony
player.Say("I can't reach it.");
}
else{ //if player is on ground
player.Walk(190, 254, eBlock, eWalkableAreas);
if(oDoor1.Graphic == 8){ // if door is already opened
if(player.ActiveInventory != null){ //and player is using inventoty
player.Say("The door is already open. I don't need to use anything on it.");
}
else{ // if not using inventoy
aDoor_Close_by_kyles.Play(); // play door close sound
oDoor1.Graphic = 7; // change door sprite to closed door
return;
}
}
if(oDoor1.Graphic == 7){ //if door closed
if(IsDoorLocked == true){ // if door closed and locked
if(player.ActiveInventory == iKey){ // if using key
aUnlock_by_kyles.Play(); // play unlock sound
player.Say("The key works!");
aDoorOpen_by_splicesound.Play(); // play door open sound
oDoor1.Graphic = 8; // change door sprite to open door
IsDoorLocked = false; //set state which affects future interactions
}
else{ // if door closed and locked, player is not using key
aDoor_Close_by_kyles.Play(); //play rattling sound
player.Say("It's locked.");
}
}
else{ // if door closed but unlocked
if(player.ActiveInventory != null){ //if using inventory
player.Say("The door is already unlocked.");
}
else{ //if not using inventory
aDoorOpen_by_splicesound.Play(); // play door opening sound
oDoor1.Graphic = 8; // change sprite to open door
}
}
}
}
}
//click on gem object
function oGem_AnyClick()
{
if(player.y > 135){ // if player is at ground level
player.Say("It's a gem of some kind. I can't quite see it.");
}
else{ // if player is on balcony
player.Say("Here's the gem the Red Mage mentioned.");
gInGameMenu.Visible = true; // Show the inventory GUI so that
WaitMouseKey(GetGameSpeed()); // the player sees the item when it
player.AddInventory(iGem); // becomes added. Add inventory item. Play powerup sound.
aPowerup_by_maodin204.Play(); // Then hide the GUI afterward.
WaitMouseKey(GetGameSpeed()); //
gInGameMenu.Visible = false; //
player.Say("This means I've completed the required tasks of the demo game.");
player.Say("So whenever I want to, I can leave by following the path out of the forest.");
oGem.Visible = false; //hide gem object
Display("To exit the demo, follow the path out of the forest, or click the EXIT button in the menu.");
Display("To explore how the game was made, talk to the Red Mage or use the AGS editor to explore the various elements of the game.");
}
}
//click on entrance hitspot revealed by door object changing to open sprite
function hEntrance_AnyClick()
{
if(player.y > 140){ //if player is on ground floor
player.Walk(180, 254, eBlock, eWalkableAreas); // walk to door using walkable areas
player.Walk(160, 254, eBlock, eAnywhere); // walk through doorway (off walkable area)
player.ChangeRoom(4, 438, 342, eDirectionLeft); // change room to specific coordinates
}
else{ // if player is on balcony
player.Say("I can't get there from here.");
}
}
//click on balcony door
function oDoor2_AnyClick()
{
if(player.y < 135){ // if player is on balcony
if(player.ActiveInventory == null){
if(oDoor2.Graphic == 9){
aDoorOpen_by_splicesound.Play();
oDoor2.Graphic = 10;
return;
}
else{
aDoor_Close_by_kyles.Play();
oDoor2.Graphic = 9;
}
}
else{
player.Say("The door isn't locked.");
}
}
else{ //if player is at ground level
player.Say("I can't get there from here.");
}
}
//click on doorway hotspot revealed by door object changing to open sprite
function hBackDoorway_AnyClick()
{
if(player.y < 135){ //if player is on balcony
player.Walk(93, 128, eBlock, eAnywhere);
player.Transparency = 100; // player character disappears into doorway
Wait(1); //make sure disappearance happens before room fade-out
player.ChangeRoom(4, 200, 146, eDirectionRight); // go into the interior room at specific coordinates
}
else{ // if player is at ground level
player.Say("I can't get there from here.");
}
}
ROOM 4: TREEHOUSE INTERIOR
Spoiler
(https://i.imgur.com/NOy5DLD.png)
// room script file
//Called before room fades in
function room_Load()
{
oChandelier.SetView(4); // give chandelier object access to animations
oChandelier.Animate(0, 4, eRepeat, eNoBlock); // animate chandelier, looping
if(player.y == 146){ // if entering from balcony
player.Transparency = 0; // undo disappearing that happened in previous room
}
}
//Next few functions: click on the various hotspots in the room
function hFrontExit_AnyClick()
{
player.Walk(433, 344, eBlock, eWalkableAreas);
player.ChangeRoom(3, 180, 254, eDirectionRight); //go outside, to specific coordinates
}
function hWashBasin_AnyClick()
{
if(cBlueMage.HasInventory(iGem2)){ // if player already has the hidden gem
player.Walk(321, 133, eNoBlock, eWalkableAreas);
player.Say("The sink is empty.");
}
else{ //if player doesn't have hidden gem yet
player.Walk(321, 133, eBlock, eWalkableAreas);
player.FaceLocation(321, 100);
Display("You found a hidden gem in the sink!");
gInGameMenu.Visible = true; // Show the inventory GUI so that
WaitMouseKey(GetGameSpeed()); // the player sees the item when it
player.AddInventory(iGem2); // becomes added. Add inventory item. Play powerup sound.
aPowerup_by_maodin204.Play(); // Then hide the GUI afterward.
WaitMouseKey(GetGameSpeed()); //
gInGameMenu.Visible = false; //
cRedMage.Say("I don't know why I left that there.");
}
}
function oBackDoor_AnyClick()
{
if(player.ActiveInventory == null){
player.Walk(200, 146, eBlock, eWalkableAreas);
if(oBackDoor.Graphic == 47){ //if door is closed
aDoorOpen_by_splicesound.Play(); //play sound
oBackDoor.Graphic = 48; //siwtch to open door sprite, revealing exit hotspot behind door object
return;
}
else{ //if door is open
aDoor_Close_by_kyles.Play(); //play sound
oBackDoor.Graphic = 47; //switch to closed door sprite
}
}
else{ //if using inventory on door
player.Say("The door is unlocked. It doesn't need anything used on it.");
}
}
function hCupboard_AnyClick()
{
player.Say("It's a nice-looking cupboard.");
cRedMage.Say("It is. I inherited it from my mother.");
}
function hTable_AnyClick()
{
player.Say("The table isn't particularly noteworthy.");
}
function hChair_AnyClick()
{
player.Say("If anyone is sitting there, they must be invisible. But that would take a lot of magic.");
cRedMage.Say("No one is sitting there.");
}
function hTeakettle_AnyClick()
{
cRedMage.Say("The tea isn't ready yet.");
}
function hStove_AnyClick()
{
player.Walk(324, 287, eBlock, eWalkableAreas);
player.FaceDirection(eDirectionUp); //face the hotspot
cRedMage.Say("Be careful, the stove is hot.");
player.FaceDirection(eDirectionDown); //turn around
}
function hRug_AnyClick()
{
player.Say("I like the colors.");
cRedMage.Say("Why thank you.");
}
function hUpperExit_AnyClick()
{
player.Walk(200, 146, eBlock, eWalkableAreas);
player.Walk(155, 140, eBlock, eAnywhere);
player.ChangeRoom(3, 90, 130, eDirectionDown); //go out onto balcony at specific coordinates
}
function hLight_AnyClick()
{
if(player.ActiveInventory == null){ //if not using inventory on chandelier
player.Say("The flicker of its flame can be mesmerizing.");
}
else{ //if using inventory
player.Say("I can't reach it. And I should probably leave it alonf anyway.");
}
}
function hBed_AnyClick()
{
player.Say("It's a small space, but the bed looks very comfortable.");
cRedMage.Say("It's all right.");
}
function hShelves_AnyClick()
{
if(player.ActiveInventory == null){ // if not using inventory on shelves
player.Say("Ancient books, orbs, and other arcane objects... a fitting collection for a master mage.");
cRedMage.Say("Some of it is just for decoration. I'm more of a spell-caster than a user of... that stuff.");
}
else{ // if using inventory on shelves
cRedMage.Say("Thank you, but please keep it.");
cRedMage.Say("To be honest, I've got to clean some of these old things out.");
}
}
RED MAGE DIALOGUE
Spoiler
(https://i.imgur.com/RgtsRi4.png)
// Dialog script file
@S // Dialog startup entry point
RedMage: What would you like to learn about?
return
@1
RedMage: Rooms have a few different kinds of areas. Which would you like to explore?
option-off 1
option-off 2
option-off 3
option-off 4
option-off 5
option-off 12
option-on 6
option-on 7
option-on 8
option-on 9
option-on 13
return
@2
RedMage: Objects are interactive items placed in the room.
RedMage: Inventory is items you are carrying that you can use.
RedMage: Which would you like to learn about?
option-off 1
option-off 2
option-off 3
option-off 4
option-off 5
option-off 12
option-on 10
option-on 11
option-on 13
return
@3
RedMage: What makes a character unique as a game element is the ability to walk, talk, carry items, interact with other game elements, and move from room to room.
RedMage: Characters are also always linked to VIEWs, which group together sets of animations like walking, talking, and anything else you want associated with a specific character.
RedMage: If you look in the AGS editor at the VIEW assigned to the blue mage, you'll see all the animations currently assigned to the blue mage character.
RedMage: You can create a very complex gmae using characters alone, but of course things get even more fun when you add objects, hotspots, and other things for characters to interact with.
return
@4
RedMage: GUIs can display text, buttons, inventory items, lists, and other information and controls.
RedMage: Each button or control performs actions by calling a script when the player uses it.
RedMage: If you look at the In-Game Menu GUI for this game, you'll see that each control has its own function in the global script.
RedMage: Reading the AGS manual will help a lot in understanding all of the different GUI controls and what they can do.
return
@5
RedMage: Every event that happens in the game really happens in a script.
RedMage: The scripting language used by AGS is tailored for point-and-click adventures, and is meant to be as straighforward as possible.
RedMage: AGS uses room script files and a global script file. For basic game functions, this should be all you need to make everything happen in your game.
RedMage: If you look at the room script for each room, you'll see that it programs what happens with all of the objects, hotspots, and other elements that belong to that room.
RedMage: The global script controls things that aren't limited to one room, like characters, GUIs, and broad functional components like mouse clicks.
RedMage: If you take some time to read through the scripts in this game, you'll see they have many comments explaining what they do.
RedMage: By learning even a little bit of how to use AGS script, you can very quickly make your game playable and full of interactions.
return
@6
RedMage: Walkable areas are the places you set in the room where you want characters to be able to walk.
RedMage: Press Ctrl-A to see the walkable areas in this room, and try the same thing in the room outside.
RedMage: Areas can be set to have characters grow smaller toward the top and larger toward the bottom, or they can have the character always be the same size.
RedMage: If you look at the rooms for this game in the AGS editor, you can see what each walkable area in each room is set up to do.
return
@7
RedMage: Hotspots are areas you draw onto a room that make an area of the room interactive. Hotspots do not move, and do not change the look of the area that they are on.
RedMage: You can make anything at all happen when the player interacts with them.
RedMage: They can trigger any event that you can write in the script, and can be one of the main tools used to progress the game.
RedMage: The door hotspots in this room will move your character to a different room.
RedMage: In the previous room, clicking on the bench triggers finding the key, and clicking on the shrine triggers movement and dialgoe.
RedMage: In this room, you have door hotspots and background hotspots. See what happens if you click on the stove.
RedMage: The Room Editor will show you all the hotspots that have been put in this game.
return
@8
RedMage: Regions are fairly simple. You can use them to determine light levels or color tinting of an area, or trigger events when the character walks on or off.
RedMage: If you step into the shadows at either end of this room, or go to the shrine outside, you'll see the light level of the character drop.
RedMage: If you want to, for example, make a background with streetlights at night, all you would need would be two regions, one with a light level set higher and one set lower.
return
@9
RedMage: Walk-behinds are parts of the background that you set to appear in front of the character if the character reaches a certain area.
RedMage: Walk-behinds are most useful for background elements that don't move, like a pillar or a counter.
RedMage: When you walk out the upper doorway of this room, you'll see the character pass behind the left side of the doorway.
RedMage: And if you click on the stove behind me, you'll see that the table shows up in front of the character.
RedMage: The table and doorway are parts of the background image, and are set to appear in front of the character once the bottom of the character is above the bottom of the walk-behind.
RedMage: The Getting Started with AGS Tutorial in the manual will give you more details on Walk-behinds and how to set them up.
return
@10
RedMage: Objects are interactive items placed in the room that are not part of the background image.
RedMage: They can move, animate, appear and disappear, and be interacted with in many ways, all of which can trigger scripts.
RedMage: The frog and the gem in the previous room are objects, and so are both of the doors in both rooms.
RedMage: As you saw, using the mouse in Interact Mode did not open the front door when it was locked, but using the Key inventory item did.
RedMage: These two different interactions triggered two different scripts.
RedMage: Using the Key played a sound, triggered dialogue, and changed the door object sprite from an image of a closed door to one of an open door.
RedMage: It also revealed the entrance hotspot that was hidden behind the door object.
RedMage: The chandelier in this room is an object that has been set on a looping animation.
RedMage: In general, if you have anything that you want to be able to move, animate, or disappear, using objects is a good way to go.
return
@11
RedMage: Inventory items are items that a character is carrying, and so they are not part of a room.
RedMage: You can use them on other characters or on parts of the room, or even change how things happen just by having one.
RedMage: The gem room object on the balcony outside will disappear when you click on it, and a gem inventory item will appear in your character's inventory, which is shown in this game's In-Game Menu.
RedMage: In your own game, you could also add an inventory item that is simply a skill, and you can program your interactions so that having this skill will change things even if you don't 'use' the item.
RedMage: For example, there is a hidden item in this room. If you have it already, I will say one thing. If you don't, I'll say something else.
if(player.HasInventory(iGem2)){
RedMage: It looks like you found it! Good job.
}
else{
RedMage: It looks like you haven't found it yet. Look around and see if you can find it.
}
RedMage: Every character has their own inventory, and can carry as many items as the game needs. They can also carry multiple copies of the same item.
RedMage: Having the gem on the balcony and having the key are the two conditions needed to 'complete' this demo game.
return
@12
RedMage: We are in a dialogue right now. Dialogues contain options of things to say, and uses a simplified scripting language to make writing them quick and easy.
RedMage: Dialogues can also trigger other in-game actions if you want them to, and any in-game action can also start a dialogue. It's up to you.
RedMage: This game keeps it simple by starting a dialogue when you click on a character.
return
@13
option-off 6
option-off 7
option-off 8
option-off 9
option-off 10
option-off 11
option-off 13
option-on 1
option-on 2
option-on 3
option-on 4
option-on 5
option-on 12
return
@14
RedMage: I hope this was helpful. Looking at this game in the AGS editor will help to make all of this clear.
RedMage: Keep in mind that you can also learn aboout all of these things in the AGS Manual, and the Getting Started with AGS Tutorial.
stop
It would be much better to put the game's source in the online repository with source control, such as git or svn.
This way it will be safe, and will allow anyone to clone, download, and suggest changes in organized way.
@Crimson Wizard do you mean put the zip file (which contains the uncompleted game project folder) on git, or put the folder itself there uncompressed? And do you mean add it to the official AGS repository or somewhere else? Thanks.
@Danvzare Would you be willing to make a blue cup inventory item that the player starts with? Just for old time's sake. ;)
Quote from: RootBound on Wed 10/04/2024 16:23:10@Crimson Wizard do you mean put the zip file (which contains the uncompleted game project folder) on git, or put the folder itself there uncompressed? And do you mean add it to the official AGS repository or somewhere else?
The files should not be compressed of course, that would defeat the purpose of the source control, as it needs to be able to detect changes with each update. Repository would contain simply the contents of a AGS project folder.
When it comes to AGS project, there's a general recommendation to NOT put certain things in repository, as they may be generated by the Editor, and will only unnecessarily increase the size of repository (by a lot). These files need to be added to "ignore" list. This includes:
- AudioCache folder; the project should have a subfolder with original sound/music files instead, referenced by audio clips as "source file".
- acsprset.spr file; the project should have a subfolder with original image files, referenced by sprites as "source files" too.
Both AudioCache and acsprset.spr may be regenerated when the project is opened in the editor, so long as source image file have relative paths inside the project.
- any backup files (.bak), and user settings (*.user files).
- folders with compiled game: Compiled and _Debug.
It does not have to be any official repository at this point, and the source may be cloned to another place anytime later.
Quote from: RootBound on Wed 10/04/2024 15:48:28HERE IS THE UPDATED VERSION: https://www.mediafire.com/file/bbpyfh7a3qb0npm/AGSQuest.zip/file
Unfortunately I do not have much spare time now to comment on the game itself, but I will comment on a project folder organization.
In the long run, and considering the game source will be eventually available for share and modifications, it's essential to have external assets well organized.
AGS saves the paths to source files for sprites and audio items, which allows to fully rebuild the resource "cache", so long as the source files are available. If the files are located inside game folder, then the paths are relative, and kept regardless of where you move the project to (different folder, or different computer).
But if you rearrange source files later, then these paths will get broken. They may be restored afterwards (there are few ways to do this, I think, both from the Editor, and editing project file Game.agf by hand). But this may be a tedious task in case of large number of assets.
For this reason it's best to come to at least basic folder structure early.
My suggestion is to have subfolders inside Assets, at minimum sprites and audio should be separate, and any unused or temporary resources should better be move to their respective folder (files not related to the game which happen to be there should be excluded from repository).
There's no need to overthink this, so any simple rule for the folder structure will do, so long as it's kept throughout the development.
For example:
Assets
- Sprites
- Characters
- Inventory
- GUI
- Rooms
- Room 1 - AGS Logo
- Room 2 - Main Menu
...etc
- Audio
- Music
- Sounds
- Room 3 - Forest with Treehouse
...etc
In terms of the rooms, something that I may mention is that AGS has state-saving and non-state-saving types of rooms, where non-state-saving are assigned a number of 301 and above.
Menus and intro screens do not have to be state-saving, so it may be "cleaner" to have them 301+. This is not really essential, but may hint a person who studies this demo game about this difference.
EDIT: Oh, sorry, another thing that I noticed, is that sounds are made as WAVs, but it
looks like they were cut from larger sounds presented as OGG. I think using OGG format is generally better, because the compression is higher, and also AGS had some issues with certain wav formats in the past. It's also better to keep at 44100 Hz, and an average bitrate (I noticed that some sounds there are 96000Hz, which is unnecessarily high).
But so long as the folder and file structure is maintained, it will always be possible to update the source file(s) keeping the filenames, and have it refreshed in the game's item either automatically or by command from Editor's menu.
Quote from: RootBound on Wed 10/04/2024 16:23:10@Danvzare Would you be willing to make a blue cup inventory item that the player starts with? Just for old time's sake. ;)
Here you go:
(https://twentyquidamusements.thecomicstrip.org/files/ags/bigbluecup.png)
I'm rather proud of how this one turned out.
Just tell me if there's anything you want altering. :-D
By the way, I love the demo.
Some updates:
-As Crimson Wizard recommended, I've reorganized the assets into sensible subfolders, reimported the sprites and sounds with these new source paths, and also replaced the .wav sounds with .ogg. I've also removed all of the extra files from the project folder that would not be needed for further development, so as not to waste space in whatever repository the project ends up in.
-I also added custom button graphics and a title image, both of which could easily be changed if people want a different GUI or title. I also changed the cursors to the icons from the BASS template, and added a custom game icon for the .exe. These changes are aesthetic but will make the game more presentable in its current form.
-I added Danvzare's blue cup inventory item, and added more UseInv interactions throughout the game, including making more use of the unhandled_event function for tutorial purposes.
-I've compiled Windows and Linux versions of the game so that it can be easily downloaded and played by interested newcomers.
-I've and also created an optimized project folder with the AudioCache folder removed and other files that can be recreated if a user downloads the project folder. I've tested this to make sure the sprites do in fact get restored from the new source path.
Questions:
1). Is the current demo game actually in a good enough state to make publicly available to new AGS users? I believe it is, so even if the project continues to evolve and change, having a version 1.0 released sounds like a good idea to me. But if people feel like it isn't ready to release, please say so. I'm not sure how many people have even tested it.
As I said, I personally believe the demo game is now fully playable and presentable. If others do agree, I think it would be good if the source could be hosted in the AGS repository so that it's in a permanent and accessible place that several developers already have access to. (The uncompiled project folder is only 2.2 megabytes at the moment, and the the compiled Windows .zip is 3 MB).
2). Should the demo game be made available on the AGS website? If so, should a .zip of both the compiled and uncommpiled versions be available there? If the purpose of the demo game is to make it available to new users, I feel like it should be easy to find and download.
3). Is anyone else interested in further refining and developing this project? I'm personally feeling ready to move on to other things, as I have put in a lot of time and effort, and I expect to have less time available for this project moving forward.
Quote from: RootBound on Sat 13/04/2024 16:13:10If others do agree, I think it would be good if the source could be hosted in the AGS repository so that it's in a permanent and accessible place that several developers already have access to.
This may certainly be done. We have a "organization" on github, which is a kind of a supergroup for AGS-related repositories. It includes templates, old demo game, etc. I can add a new repository there, and grant access permissions specifically to you, and anybody else willing to work on this project (that requires having a github account).
The game releases may be also hosted within the repository, at least for starters (there's a "Releases" page where one can upload an archived compiled game).
@Crimson Wizard sounds good. Once that's available, just let me know, and I will upload the compiled and uncompiled versions to the proper pages. I have a GitHub account as RootBoundAGS.
In the meantime, here is the latest version of the project folder, for further testing and comment:
https://www.mediafire.com/file/3lygtdk249how7j/AGSQuestUncompiledProject.zip/file
And here are Windows and Linux compiled versions:
Windows: https://www.mediafire.com/file/1xbathmg8odaqoq/AGSQuestCompiledWindows.zip/file
Linux: https://www.mediafire.com/file/gbrchqvmebm7mx2/AGSQuestCompiledLinux.tar.bz2/file
And here's a screenshot of the new title screen, just for fun:
(https://i.imgur.com/VbkGJWo.png)
Quote from: RootBound on Sat 13/04/2024 17:15:51Once that's available, just let me know, and I will upload the compiled and uncompiled versions to the proper pages. I have a GitHub account as RootBoundAGS.
I was not able to find that account, could you double check that?
I found only this:
https://github.com/rootbound
but I don't know if it's yours.
Quote from: RootBound on Sat 13/04/2024 17:15:51In the meantime, here is the latest version of the project folder, for further testing and comment:
https://www.mediafire.com/file/3lygtdk249how7j/AGSQuestUncompiledProject.zip/file
This looks fine; few more files could be removed:
- sprindex.dat - that's a quick index for sprite file and useless without one (it will be regenerated along).
- template.ico and template.txt - these come from starting template, but are useless for the game.
After the files are added to repository, it would be nice to configure ".gitignore" to avoid re-adding compiled and generated files.
I might suggest this list:
/_OpenInEditor.lock
/_Debug/*
/Compiled/*
/*.bak
/*.user
/*.dmp
/acsprset.spr
/backup_acsprset.spr
/sprindex.dat
/AudioCache/*
Hmm, no that profile isn't me.
https://github.com/RootBoundAGS this is my profile.
I've removed the files you listed from the uncompiled project folder. Here's the archive with those files removed.
https://www.mediafire.com/file/h40pbcl9gexh9m2/AGSQuestUncompiledProject%25282%2529.zip/file
Quote from: RootBound on Sun 14/04/2024 22:17:41https://github.com/RootBoundAGS this is my profile.
This link is giving me 404 error :/
EDIT: double checked, and github does not let me send an invite to your account, telling that it does not exist.
Quote from: Crimson Wizard on Sun 14/04/2024 23:14:05Quote from: RootBound on Sun 14/04/2024 22:17:41https://github.com/RootBoundAGS this is my profile.
This link is giving me 404 error :/
Hmm. Maybe my account isn't fully 'registered' somehow. I'll try to figure it out.
@Crimson Wizard if you go to the list of "followers" on the AGS repository, I am listed there, but my account is flagged as "spammy." (wtf) I sent an email to GitHuib asking them to unflag it. I don't know whether you can give me access before it is unflagged or not. :-\
Quote from: RootBound on Mon 15/04/2024 17:10:36@Crimson Wizard if you go to the list of "followers" on the AGS repository, I am listed there, but my account is flagged as "spammy." (wtf) I sent an email to GitHuib asking them to unflag it. I don't know whether you can give me access before it is unflagged or not. :-\
I tried sending an invite, but your name is not recognized as a valid username.
Are you sure that your whole account is not "private"? I don't remember exactly if it's possible to do, but if it is, then others won't be able to access it.
Quote from: Crimson Wizard on Mon 15/04/2024 17:37:48I tried sending an invite, but your name is not recognized as a valid username.
Are you sure that your whole account is not "private"? I don't remember exactly if it's possible to do, but if it is, then others won't be able to access it.
Sadly I can't find any setting like this. And I have no idea how long it might take GitHub to respond to my email.
If this difficulty persists, it might be faster and simpler for someone who already has access to the AGS repository to simply download the latest .zip file I uploaded, extract it, and then upload the folder to the AGS repository.
Once it's in the repository I'm happy to write a "Completed Games Announcement" thread for the first release of the demo, with links to both compiled and uncompiled versions, explaining the open source tutorial nature of the project and inviting more people to contribute to its ongoing development. If everyone thinks that's a good idea, that is.
I found some time to play through the game and have a quick look through the project, though I ran out of time to properly read through the room and global scripts. It's good, I like it a lot! You've ticked off a lot of the suggested feature list while keeping the game small enough that it hopefully isn't too daunting for a new player to look through.
I noted down some suggestions while playing. Hopefully they doesn't come across as too harsh as I think the overall demo is really nice. These are also just my two cents and I would like to see more feedback from others too.
Spoiler
Typos:
- environemnt > environment in the opening Display text.
- thonk > think when looking at the pond.
- cam > came when looking at the deep forest.
- Teakettle > Tea Kettle?.
- gmae > game in the Characters explanation.
- dialgoe > dialogue in the Hotspots explanation.
- Not really a typo, but Red Mage talks about 'Dialogues' a lot. I'm in two minds about this as I think that's the correct spelling (even in American English?) for conversations, but the AGS editor uses "Dialogs".
- This is really nit-picky, but "Wash Basin" capitalises both words whereas other objects tend to have the second word in lowercase ("Deep forest", "Stone bench", and "Bed nook").
Views:
- Should characters have a talking animation to demonstrate speech views?
- "Different views for player character" was suggested as a demo feature, is it worth adding e.g. a simple pick up animation for finding the key or a 'hand out using' type animation for unlocking/opening the door to demonstrate things like Character.LockView and Character.Animate?
- The MageRed view has (blank) sprite 0 set for loop 1 and 2 (left and right), but no sprites set for loop 3 (up). For consistency I think the sprites should be removed for the other two loops where they're not being used.
Music:
- Another suggested feature in the original list, and the game feels a bit empty without some kind of music or at least ambient forest sounds.
Possible scripting bug:
- Looking at the toadstools when standing near the entrance says "I need to get closer" then walks the character there. However looking at other areas (the window, the shrine, the bench, and the bullfrog) only says "I need to get closer".
- Additionally you can use items on the toadstools from across the screen, unlike the other areas.
Inventory:
- Combining items is another suggested feature, and at the moment it's not possible. I think this is common enough requirement for games to add it in.
- I'm not sure if it's worth building a puzzle requiring it, but even allowing the use of cup on key and getting a generic "That doesn't work" would demonstrate how to do it.
Font:
- I think it would be worth switching this from the current pixely font to something at the native resolution to help readability.
GUIs:
- Nit-picking once again, but GUI elements are named inconsistently with, for example "btnQuitYes", "ButtonCloseCredits", and "Button1". We should at least rename the ButtonX and LabelX elements to indicate what they do, but I'd prefer a consistent naming convention.
Cursors:
- Pick up is set to the bullfrog sprite, which I enjoyed, but maybe it should be sprite 0 as the mode isn't used?
- Delete Usermode1 and Usermode2 as they can be deleted and aren't used in game?
Red Mage dialog(ue):
- I would like to see some more feedback on this, as to me it feels like it might need some more thought.
- It dumps a lot of information at the player with not much time to read it (side-note, is it worth implementing a dialog speed slider?) though of course the player can re-select a topic.
- I think some of these options need to be simplified and/or go into more detail. I think a lot of this is too complicated for someone who hasn't done the tutorial and/or played around in the engine already, and don't really add anything for someone who has.
- I think we need to decide who this is written for and what knowledge they're supposed to have going in, then re-write for that person. IMO I would assume a player who has a vague understanding of point-and-click games but hasn't read the tutorial, and talk in more general terms about the components that make a game. I would use code comments (suggestions below) to go more in to detail about how things are actually used.
- It demonstrates dialog trees and scripting which is useful on its own though.
Code commenting:
- As I said I ran out of time to properly read through the scripts this evening.
- What I did wonder about is code commenting. I can see you've added a lot of comments to the code, but my suggestion would be to write somewhere between a sentence and a paragraph of comments at the start of every function saying when it's run, what it does, and if necessary how it does that. Maybe also add a topic or list of related topics to look up in the manual for more information?
- For example, something like:
/* The game_start() function is run at the very start of the game, before any
rooms are loaded or anything is shown on the screen. This makes it useful for
doing any setup we need to at the beginning of the game.
Look up 'game_start' in the manual for more information.*/
function game_start()
{
/* Here we use the built-in GUI.Gentre function to make sure the below GUIs are
centred on the screen. We can set the GUI positions manually in the GUI editor,
but this is a handy shortcut. Note that this works even though the GUIs are
invisible at the start of the game.*/
gQuit.Centre();
gOptions.Centre();
gCredits.Centre();
// We also set a highlight color which is used when displaying dialog options during conversations.
game.dialog_options_highlight_color = 54575;
} - Maybe the manual reference in that example is redundant as it's literally just saying "search the function name", but might be useful to provide related topics to look up or references for custom functions, or even just to remind people to read the manual?
If others agree with any of my suggestions I'm happy to have a go at some of these, or maybe put together some examples of dialogue re-writes or code commenting to better illustrate what I'm thinking. I'm a little tied up with MAGS at the moment, but if it's helpful I'm happy to contribute once that's out the way?
@OneDollar I agree with almost everything you've suggested.
-A speech view and combining inventory are definitely basic features that should be included (Maybe allow the gem to be put in the cup for combining items?).
-Consistency in GUI naming is good too. That's a helpful nitpick.
-I forgot about the frog cursor lol. That was a debug tool (if the frog appears as the cursor, something is wrong). I don't believe you can delete cursor modes, though? I guess I've never tried it.
-I looked for music but couldn't find anything in the public domain that I actually liked.
-A bigger font is fine too, but should also probably be in the public domain.
-As far as the Red Mage dialogs go, I wrote them for an imaginary player who is playing the demo game from within the AGS editor and so can learn more about how the editor works from reading the dialogs. I also tried to limit the dialogs to explaining "what elements are" (ex. What is a hotspot?) rather than how to use the elements in detail. Basically to help users recognize things when they see them in th editor. I don't know if that's the best approach or not. At the very least, there's now an existing framework of dialogs for people to tweak.
-As far as code commentary, I don't really have a strong opinion on how much there should be. I'm all for explaining thoroughly, but a lot of stuff (like explaining the game_start function) is in the manual, so I would consider whether it might be better to direct the user there?
Thanks for testing and commenting! We need more people to contribute to the project so anything you want to do is helpful!
EDIT: One thing to keep in mind though is that if the font is enlarged, this would affect the GUIs, which would have to be redone to accommodate the bigger size. If only the dialog font is changed, nothing else would need to be resized.
@cat ,
@RootBound Could someone remind me, was the type of License decided for this project?
If it's uploaded to repository, I'd also like to add a license text there as well.
@Crimson Wizard licenses mentioned earlier in the thread were CC-BY-NC and BSD-0. The idea was also floated to have different licenses for the code vs. art.
I don't think a firm decision was made. I'll let cat chime in with anything more detailed since I wasn't deeply involved in that aspect of the discussion.
Quote from: cat on Fri 30/06/2023 10:24:42I think the code should be public domain. The purpose of this demo game is that you can copy parts of it and use it for your own game. Do we need some disclaimer about liability, though?
What about art and music assets? Should they be public domain as well? Or some CC attribution license?
Quote from: Crimson Wizard on Fri 30/06/2023 11:09:02I think at least CC BY-NC license should be used (attribution + non-commercial use only), as contributors may not like their art to be reused in commercial games.
Quote from: cat on Fri 30/06/2023 13:17:52Giving attribution might be difficult, though. It will be hard to find out the author of a certain sprite. Maybe attribution should be made solely to "AGS Demo Game Contributor" and not each individual person. I hope artist are okay with that.
Of course, the game itself should contain an elaborate credits section that lists all contributors.
Quote from: cat on Fri 30/06/2023 21:19:04I had another look at licenses and found the BSD 0-clause license we could use for code
https://en.m.wikipedia.org/wiki/BSD_licenses#0-clause_license_(%22Zero_Clause_BSD%22) (https://en.m.wikipedia.org/wiki/BSD_licenses#0-clause_license_(%22Zero_Clause_BSD%22))
It means the code is basically public domain, but without warranty. People can copy it freely to their projects but cannot blame us if it doesn't work.
Maybe I will talk with my colleague about it next week, he knows quite a bit about open source licenses.
Quote from: cat on Thu 06/07/2023 12:48:20I was talking with my colleague about the license. He said that it should be okay to use different licenses for art and code, we just have to write a custom license file. His only concern was that if we use the BSD 0 license, we also do not keep any rights of the name. I don't know if this is really important.
So, I think we might want to use different licenses for code and art. Opinions?
Edit: Just saw
@RootBound 's post. I think it pretty much sums it up. No firm decision yet.
I will say one more things, with regards to attribution. The credits for the current demo build name contributors for everything, including the original Roger sprites and BASS icons, as well as the sound effects (which are public domain), so I think attribution may not be difficult as long as any new sprites and sound files have their authors added to the list of credits that's already in th game. I don't think there are any uncredited assets at the moment.
EDIT: Actually I didn't credit the default fonts. But these might be changed anyway.
Alright, I will upload the latest project version to the repository later today.
After that it will also be possible to open bug/task tickets there.
@Crimson Wizard thanks very much. I know you already have a lot on your plate and I wish I could have just done this myself without complication.
Given
@OneDollar's comments I suppose it would be prudent to hold off on a completed game thread until some more bugs are fixed.
Well, here it is:
https://github.com/adventuregamestudio/ags-demo-game/
I may give access permission to people who would like to maintain and keep developing this game.
Thanks,
@Crimson Wizard !
@RootBound I cloned the project and tried it. The graphics are beautiful and I like the comments (in-game and also in code!) and explanations. There are, however, some things with the UI, that I don't like. I have a few comments and questions:
- Having a one-click interface is fine, but I don't like the changing cursors, especially if they are tied to the type of location. I sometimes use objects just for the purpose of walk-behinds, and I want to look at them but without interaction. The proper way to do this is to use custom properties for each object/hotspot. However, this is an advanced feature that shouldn't go into the very first entry level room. I think the cursor should be replaced by just a simple pointer with a highlight (outline or color change) when hovering over something interactive. If we DO want to show special inventory cursors in one of the more advanced rooms, this is fine for me, but the code should go into the room's repeatedly_execute function.
- The icon for the menu is only temporary, I assume? I thought this was a counter with value 0 first. I also find the location of the inventory button and the menu itself a bit weird. None of the default templates have the menu on the right side - what was the reason for that? Please keep also in mind that if we add translation at some point, the words for the buttons can be much longer in other languages.
- When opening the project in AGS editor, I got a message that I'm using a newer version of AGS. Which is the intended version? Is it the last stable?
- How do we work on this? Of course, we will discuss things first, but afterwards? Just make a fork and then pull-requests? Who is responsible for merging them? Should we have something like "room-owners", i.e. every room has a person who decides what goes in? Or is this all a community effort?
Quote from: cat on Thu 18/04/2024 18:41:34- When opening the project in AGS editor, I got a message that I'm using a newer version of AGS. Which is the intended version? Is it the last stable?
The project is done in 3.6.0. It may be upgraded to 3.6.1 if that's wanted.
Quote from: cat on Thu 18/04/2024 18:41:34- How do we work on this? Of course, we will discuss things first, but afterwards? Just make a fork and then pull-requests? Who is responsible for merging them?
I would prefer if there were at least 1 maintainer/manager, that is - a person responsible for keeping the game runnable, assigning tasks and checking and merging (or rejecting) pull requests. I honestly don't want to be the one, I'd wish someone would volunteer for this, in which case I shall grant them write permissions for this repository.
After that I can add more people there by this manager's request, if necessary.
We also may add automatic game building process using Github Actions (i think?). This would allow to test that game compiles at all times, and have it uploaded to "releases" page on github.
@eri0o did this for his own games, and for our test games in other repository (we use them to test the engine, they are not playable).
Quote from: cat on Thu 18/04/2024 18:41:34Should we have something like "room-owners", i.e. every room has a person who decides what goes in? Or is this all a community effort?
Having a person responsible for a room makes sense in terms of
working on it. But I think the final decision should be done by a manager who has a full picture in the head, otherwise things may get inconsistent and messy.
@cat1. The highlighted cursor is probably a good idea that makes things simpler and less jarring. I suggest keeping the inventory items as cursors though since this is a common feature, but all the other cursor modes could still just be a highlighted pointer. That's my opinion anyway.
2. All the GUI graphics are placeholders. I just wanted the GUI to have a presentable look with custom sprites. Everything about it can change.
3. GUI placement was arbitrary. I just prefer GUIs that appear from the bottom rather than the top. The right hand side also just felt natural to me. It can be placed somewhere else, but I don't see any reason it has to be the same as any of the default templates.
4. I don't quite understand how GitHub works, so I can't really answer that. I know
@OneDollar had suggestions to possibly implement later, but I was the only one who chimed in on them. At this point it seems like changes should be proposed in the thread and if no one offers differing opinions, they can be implemented. Not many people are engaged in the project at this point.
EDIT: I also agree with Crimson Wizard above that things ought to be kept consistent somehow, and having someone in charge would probably help that. I don't think I have the GitHub skills or the time to do it, though.
Patches to the game may be made outside of github too. That's a bit less convenient, but if they are contained in few specific files only, then a person might send them to the manager, who merges the changes and commits to repository.