Messages

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! 

Here's a revision of the inventory items explanation:
-----------------------------------------------------

Inventory items, which are typically items the player carries around, 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 called or pointed to from within the script.

An inventory item's main capabilities include the following:
- being added to the set of items that belongs to a character
- being displayed in those sets 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 the set of items available to the current character

 All inventory items may be given to a character multiple times, such that a character may possess any number of copies of any particular item, and each character in the game has a distinct inventory set to which items may be added. "Lost," "inactive," or "used" items always remain present and accessible in the script, and can be re-added to a character's inventory, re-activated, and re-used whenever the game requires.

Bumping this up in hopes of generating more interest. Sadly I won't be able to participate due to other projects.

Thanks, everyone!

Next Sprite Jam theme, coming right up.

Hey everyone:

Just for fun, I modified the default Roger sprites into a mage (Mager?) and Tron (Troger?). I also made red and yellow versions of the default blue cup. (I didn't make a right-facing version of the Tron one, but the left-facing frames can be flipped for that.

Have fun! Hope you enjoy.