Messages

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



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

Didn't have time for digital art, but a pencil sketch seemed very appropriate! Thanks for the prompt.

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?

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.

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. 

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?

Thanks @Creamy and @m1k3 . The game is almost finished. I just need to get my act together, put in a good week's worth of effort, and stop getting distracted by making MAGS entries.

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?

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

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

Code: ags

global script repeatedly_execute_always

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

Great theme. I'll have to think about whether there's an idea I can execute very quickly . . . wheels are turning.

Wow, 3 great entries in 24 hours! Amazing. Thanks for jumping in, everyone!

MY SIBLINGS, THE STONES is a short story-driven adventure game.

A dropout mage arrives by portal to a village whose water has been diverted by a troll. In order to find her way home, she must help the villagers solve their predicament.

Can't wait to share it with all of you!

FEATURES:

-Backgrounds adapted from photographs (thank you OpenGameArt.org)
-Music by Eric Matyas
-Character-driven puzzles
-A subtle mood
-Short-to-medium lentgh

PROGRESS:

-Coding: 50%
-Animation: 10%
-Puzzle and story design: 100%
-Dialogues: 70%
-Game areas: 100%

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.

Thanks, that looks good. I feel like I'm missing something basic, though, because I can't see a way to edit it or paste anything here.

EDIT: I think I got it working. The text should be up now.

I think this is probably the last revision that I have the time and energy to write. I made a GitHub account, but I don't know how to post the text or where in the AGS manual it should go. If someone can tell me the proper place and how to add it, I will put the text there so that others can edit or expand upon it.

Third revision
--------------

Inventory items represent things that a character may acquire and use: a physical object, an idea, a useable skill, and so forth, depending on game mechanics that you want to have. Each character in the game has their own overall "inventory" which is the set of items or skills they are carrying. They can be made visible in the game, or simply work behind the scenes.

In technical terms, inventory items are a built-in game object with a built-in corresponding script class.

Each inventory item has:

* a unique script name, used to refer to this item in scripts; (required)
* a textual name, for describing it to player;
* a graphic, for displaying it on screen;
* a cursor graphic, for setting a cursor when the item is selected.

What can you do with an inventory item?
* add it to a character's inventory
* display it in a character's inventory using a GUI (this can be done with the built-in Inventory Window, a list box, or a custom GUI).
* make the item "active" (selected for use by the player)
* use the item  on game components such as hotspots, room objects, characters, and other inventory items
* remove the item from a character's inventory

In the game script, character own "copies" or instances of inventory items, so any character may possess any number or amount of any particular item. Using or removing an item affects only the specific copy of the item referred to. Other copies of the item remain, and new copies can be created, re-added to a character's inventory, re-activated, or re-used whenever the game requires.

Second revision.
------------------

Inventory items represent something that a character may acquire and use: a physical object, an idea, a useable skill, and so forth, depending on game mechanics that you want to have. They are a built-in game object with a built-in corresponding script class. The user assigns each item an image and, optionally, a cursor, as well as a unique script name which allows each item to be easily referred to and used from within the script. Each character in the game has their own overall "inventory" which is the set of items or skills they are carrying.

An inventory item's main capabilities include the following:
- being added to a character's inventory
- being displayed in a character's inventory via a built-in class of GUI windows
- becoming active in the game interface (so as to be used by the player)
- being used on game components such as hotspots, room objects, characters, and other inventory items
- being lost from a character's inventory

Character own copies or instances of inventory items, so any character may possess any number or amount of any particular item. These copies use the particular item's information as given in the AGS editor, which always remains present. This means that any time an item is "lost," "inactive," or "used," this affects only the specific copy of the item referred to. Other copies of the item remain, and new copies can be created, re-added to a character's inventory, re-activated, or re-used whenever the game requires.

Less than two weeks left. Anybody else interested? We can certainly extend the deadline as needed.

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

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

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

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

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

Congratulations to everyone! 

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.

CONGRATULATIONS to @Pinback, the winner of this month's Sprite Jam! Fantastic entry. It's up to you now to set the theme for the next Sprite Jam. Have fun!

This month's Sprite Jam theme is UNEXPECTED INVENTORY.
------------------------------------------------------

Wait, wait, I can pick this item up?

I can actually add it to my inventory and carry it around? Holy cow!

I'm not sure how I feel about this item!

What is it?? Only your entries can answer the question!



Have fun!