Let's build a new AGS demo game!

[Crimson Wizard]

https://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.

[RootBound]

https://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.

[RootBound]

@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."    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. 

[Crimson Wizard]

@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."    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.

[RootBound]

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.

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.

[OneDollar]

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:

Code: ags

/* 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?

[close]

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?

[RootBound]

@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.

[Crimson Wizard]

@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.

[RootBound]

@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.

[cat]

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?

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.

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.

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)
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 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.

[RootBound]

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.

[Crimson Wizard]

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.

[RootBound]

@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.

[Crimson Wizard]

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.

[cat]

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?

[Crimson Wizard]

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

- 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).

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?

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.

[RootBound]

@cat
1. 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.

[Crimson Wizard]

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.