Messages

Cool!  Sweet!  Thanks!   

I've still got to bash together the map GUI graphics and at least a rough of the map itself before I can really start assembling that, but with this help I ought to be able to set up all the animating buttons today.  Kick.ash! 

Button.Animate: I have a feeling it's similar to putting a Walk() in rep_exec. Basically, it calls it everysingle frame, which actually doesn't make it walk at all. The manual entry for Button.Animate says "You can abort an animation at any time by setting the button's NormalGraphic property, or starting a new animation on the same button."

Button.NormalGraphic = 47; //Sets it to that spriteslot's number. Simple enough.

A-HAH!  No, I WAS just being dumb on this one -- I tried several different 'phrasings' for the line, but what I didn't notice was that I'd been using == instead of = !  *headsmack*  That ought to solve stopping the animation and resetting the button's graphics, but I'm still not sure how to get it to play while the mouse is over the button.  Should that code go somewhere other than RepEx?  An on_event, perhaps?

Status bar: @OVERHOTSPOT@ is great, but doesn't work for everything. Just keep in mind the GetAtScreenXY functions Also, you could try to dynamically change some of those controls in the script using Clickable, SetPosition, Visible, and other functions.

Right on -- I guess that a stack of buttons and labels in a single GUI really is the tidiest approach for what I'm doing with the status/menu bar (as opposed to creating multiple GUIs that display in the same location).  Nice to have some confirmation that I'm at least researching the right commands!

Map window: You'll often see suggestions for making a world map as a room, and enabling objects as you discover new locations. However, if you want it scrollable, I'd suggest a GUI. I'm not familiar with the code for click and drag (although I do know a forum search will help you), remember to create a function under rep_exec that bounds the edges to the viewport (so you won't see behind the GUI). Also, if you want buttons for look, travel, or even a legend, I'd suggest making a second GUI with a higher X-order so that it won't be dragged out too.

Yeah, a map room seems to be the most common approach; I just don't think it quite fits with the overall visual and structural scheme for this game.  Oddly enough, I've already found a script (which I'm using in a very different game) for clicking and dragging a character, which I believe I can adapt to dragging a map 'object' (not necessarily an Object in the scripting sense) -- maybe.  How to get it to display only within a certain box is the part I'm not too sure about, but I guess I ought to get all the GUI images drawn and the basic display functions coded before worrying about the map sub-functions! 

Episodic feature: A few ideas. 1)You could either create a game template once you set up characters, GUIs, InventoryItems, and rooms shared by all the games. 2) Export a file at the end of the game, which will then be loaded into the sequel. Quest For Glory does this because you have stats to raise, and can continue your character's development in the sequels. Check out the File functions in the manual. 3) Check out RUNAGSGame, but make sure you pay close attention to the manual and it's warnings. (such as the same AGS version,etc)

I'm pretty sure #2 will best work for my purposes, but I'll be looking into all of these suggestions -- on closer analysis, I realize that I need to do a good bit more event-mapping on paper before I know for sure how much information a new game will need to continue from an old.  In any case, it's nice to know that the basic concept of episodic continuation isn't just ridiculous.

Hope I helped.
~Trent

Sure did!     More than anything else, I just needed to get some input from real humans -- been working on this in isolation for too long, my brain is starting to feel as overheated as my hard drive.  Probably why I'm being so chatty and rambling here, too.

You've handed me a good bundle of threads to pull on -- I think I can start hacking away at the code again with a more certain footing.  But for right now I've got to haul myself to bed before my cortex melts.  Thanks!   8)

Well, I've tried a bushel of searches, but everything I've turned up seems to refer to AGS versions before the Button.Animate command was added -- I'm using v3.1.  Hope I haven't missed something blazingly obvious...

What I want seems simple enough: to have GUI buttons with a normal Image, a normal Pushed Image, and an animated Mouse Over image.  This is the code I've tried to accomplish the first step, getting the button to animate on Mouse Over (using just one button, InvUp, for testing):

Code: ags

function repeatedly_execute()
  {
    GUIControl *theControl = GUIControl.GetAtScreenXY(mouse.x, mouse.y);
    GUI *theGui = GUI.GetAtScreenXY(mouse.x, mouse.y);
    if (theGui == gMain) {
      mouse.SaveCursorUntilItLeaves();
      mouse.Mode = eModeSelect;
      mouse.ChangeModeGraphic (eModeSelect, 10); // the Select cursor changes color depending on which GUI it's over
      if (theControl == InvUp){
        InvUp.Animate (2, 0, 15, eRepeat);
      }
    }
    else if (theGui == gMenu) {
      mouse.SaveCursorUntilItLeaves();
      mouse.Mode = eModeSelect;
      mouse.ChangeModeGraphic (eModeSelect, 5);
    }
    else if (GetLocationType(mouse.x, mouse.y) != 0){
      mouse.SaveCursorUntilItLeaves();
      mouse.Mode = eModeAct;
    }
    else {
        mouse.Mode = eModeGo;
    }
  }

...but this doesn't start playing the animation until the mouse is taken off the button -- while the cursor is over the button, it changes to the first frame but doesn't animate.  From the Button.Animate description in the manual, I don't see why this is the case or how to change it.

After that, of course, I want to restore the regular graphics for default and Pushed Image, but again, from the description of what appears to be the right function, Button.NormalGraphic, I haven't been able to figure out how to construct a correct command line.

As for the "lazy questions", there's a huge list of things remaining on my figure-it-out stack, and as long as I'm posting anyway, maybe some of you old hands can point me in the right directions (or at least away from the wrong ones) -- these aren't 'real' questions yet, since I haven't done intensive research on any of them, just some things I want to accomplish and would appreciate any tips or feedback on:

* I have a black status bar that remains always visible on the lower edge of the screen, and I'd like to use this space to display several different types of thing:  game messages (such as @OVERHOTSPOT@ results, "Use Item on [object name]", and so forth); the Main Menu (which is a simple row of text buttons, "[ save ]  [ load ]  [ new ]" etc.); and several of the Menu options themselves (for instance, the Save "window" would just be a line of text, "Name this saved game: _________ [ ok ]  [ cancel ]", similar for Confirm Quit and Confirm Restart).

I can think of several ways to accomplish this, but I'm interested in hearing your thoughts on simple and elegant ways -- ideally, using the smallest possible number of different images, GUIs and buttons/labels stacked atop one another.

* I want to have a Map window in which one can zoom the view in and out (between three discrete scale images; it doesn't need to animate between them), and drag or scroll the map image around (ideally, by grabbing and dragging it in the manner of Google Maps); on the map I'd like the locations to highlight on Mouse Over, and be available for the "Look" and "Go" commands (with a routine to check whether your character has a clear path to "zip" to a new location).  Again, I do plan to work this out on my own, but there are so many sub-tasks involved that I'm finding the whole thing a little overwhelming -- any advice on how to get started with this particular complex of functions would be greatly appreciated.

[ edit: I looked up some map-related threads, and though I've gotten some ideas, the most specific issue I have is that I want to have the map visible through a window on the screen -- that is, NOT taking up the whole screen, and with the current room still visible around the edges of the GUI. ]

* Finally (for now), because this game involves a LOT of characters, objects and locations, I plan on constructing it as a series of Episodes, each being a self-contained game covering a given amount of the overall story.  To make that work, I want the player to be able to continue from their save of the previous chapter (structurally, the game is mapped out such that each chapter has a range of beginnings based on the possible endings of the preceding).  I don't EVEN know where to begin on this; is there a reasonably simple way to set up such a thing?  In particular, is there anything I should be considering right from the start with an eye toward making the game work this way?

Thanks for any help you feel like giving!  

Fair enough, I wouldn't have posted if I didn't want people's common cents.

I do see your point, though, and I've also been reading up here on people's likes and dislikes in games.  The way this game is emerging, I think there are elements that mitigate against the frustration factor:

To begin with, very little of the game depends on having specific objects; when you do need a specific thing, it's always made very clear in the storyline and NEVER involves objects from outside the current level.  More often, those goals that involve your inventory at all can be accomplished by multiple means -- I haven't got any screwdrivers, hammers, crowbars or crates in the game, but if there were, all three of the former would be able to open the latter.

Which relates to the second point, that most of the challenges in the game aren't inventory based at all, but depend rather on dialogue with the other characters -- that is, when you run into a locked door in this game, it's more often a matter of getting permission to go inside than it is a matter of working out how physically to open the door.

On a more pragmatic level, throughout most of the game you've got more storage space than you need -- in fact, most of the time your character Pixie has some sort of living space of her own where she can store extra things (there's a mini-map teleportation system so that going back to your room for stuff isn't too much of a hassle; I'm considering even putting Pixie's room(s) on the inventory bar as a sort of bottomless pocket).  There are a few key points where I twist the screws on what you can carry, which are mostly designed to raise the suspense during scary parts where Pixie has lost her former home and some of the comforts you've been led to take for granted have been knocked out from under you.

For the most part, the limited inventory spaces serve as a checklist rather than a prohibition -- for example, in the first chapter you get a basket with twelve spaces, and the goal of finding a dozen Easter eggs around the farm, so the empty spaces in the basket serve as a visual meter of your progress.  Most of the inventory space types, apart from the pockets on your actual garment, have similar functions, as places to keep specific classes of thing.  Your pocket space itself, with (in most outfits) twenty spaces, is in almost every chapter more than enough to hold the total number of objects available.

None of this matters, of course, if the player is just turned off by the notice on the basic Help page that says "INVENTORY SPACE IS LIMITED,  NOT ALL OBJECTS ARE IMPORTANT", but for players to whom a limited inventory isn't an immediate deal killer, I think the limited spaces will remain mostly transparent and unobtrusive through most of the game.

In any event, even if I decide to make the inventory bottomless, I still want to represent it visually using the format above.

Sorry to ramble on like this, but I do find that nailing some of these principles down in words really helps to work out parts that are still vague or broken.  Thanks for the input!

Just as a point of interest, what is "the way you want the inventory to behave"?

Aheh, your reply came in even as I was going to edit my original post.  Thanks again for asking the little question that made me stop and go, "Wait, what am I up to here?"

What I should have done in the first place is more like this:

My inventory concept is based around this board...



I know what I want it to do, and in view of my deepening realization of just how new I am at this, I'll skip trying to explain the various ideas I've had toward getting there.

You begin the game wearing overalls with five pockets, each of which can store up to four "size points" worth of item, represented by the little gold rings.  The rings light up to show how many points worth of space are currently occupied, which isn't strictly the same as the number of objects.

As the game goes on, your character changes clothes, picks up baskets or backpacks, and otherwise changes the number and nature of the storage spaces you have, calling up different icons in the bottom of the little pits.

Naturally, I want inventory objects to appear in the little pits.  Ideally, you'd also be able to move them around from pocket to pocket just for style, but it doesn't much matter in the game where you carry things as long as you've got space left.

Left-clicking on an inventory item should pop up a larger image in the large green display, and a text description in the dark green bar up top.  The gold buttons, from the left, allow you to Drop, Nibble, Combine, Break or Use the displayed object, where Use closes the interface and gives you the item as a cursor (right-clicking an object automatically Uses it, as well).  A variety of other buttons appear above that when an object has other actions available.

So that's how I want it to work, and I won't say I've got no idea how to do it, but the ideas I do have are elaborate and clunky.  The idea about creating a separate room to do it in was sort of a blue-sky sketch of a concept for approaching it without using iItems at all, or in a limited way, but my original question was spurred by frustration that I didn't even know enough to set up the experiment.

Any suggestions for more elegant ways to work this would be deeply appreciated.

Thanks!

But it does beg the question, why not just use a GUI?

That's probably the best question; I'm not totally committed to this approach by any means, and I sure wouldn't say I know what I'm doing yet in AGS.  From various threads, though, it appears as though the most common workaround for getting an inventory to behave the way I want involves creating a bunch of invisible dummy characters, which doesn't seem to be any simpler or more efficient than creating a dummy room.

In part, I'm experimenting in this direction just because it involves more commands and processes that I've already figured out how to do, but I'm certainly open to better ideas. 

In any event, I figured that even if I discarded this approach, learning how to do it would still give me some insight into related concepts, which it has -- seeing this in code has really cleared some very basic things up for me.  Thanks!

Well, I've searched and searched, but I've finally reached a question I wasn't able to work out for myself...

I've got a room accessible from anywhere that's supposed to act as a sort of psuedo-GUI to handle inventory in a novel way, but I'd like to create the illusion that it's just a pop-up.  To that end, the inventory room's background features the inventory panel, and a blank gray space; I want to fill the gray space with the player's previous room background image (presumably using dynamic sprites / drawing functions).

But I just can't figure out how to phrase it.  How can I tell this room to call up the player.PreviousRoom in such a way as to get the BACKGROUND image from it?

Ooh, I just thought of another hair-puller -- In Myst, there's a point where you can't progress until you've found a certain door, which is HIDDEN IN THE DARK behind the ONLY DOOR IN THE GAME that doesn't automatically close behind you.

Myst and monkey-related puzzles collide in disaster in the fourth Myst game: there's a puzzle in which you have to decipher the cries of a bunch of monkeys and use a device to replicate their danger call, but you have to do it in the proper cadence -- and the controls just aren't that easy to use.  I found out later that there's a patch to slow the damn thing down, but all the sites referring to it mention that you've still got to be ridiculously fast to get it right; I just couldn't be bothered.  Never finished that game.

Oh, and as long as we're on the topic, how about roughly 87% of The 7th Guest?

(If any of you didn't happen to catch the thread, a strongly related topic has come up before on the forum, which became >this post< in the AGS Wiki.)

There's one thing I just remembered has been annoying me to no end, something that seems to be used in damn near every horror game (most of the examples I'm thinking of are Flash games or shooters, but I think the same rule applies in adventure games) -- the %^&*% INSANE PERSON'S JOURNAL ENTRIES.

Usually they're pages scattered all over the game, yet curiously in chronological order.  They all tell the EXACT SAME STORY: Part One, "Oh, I love my new house/job/asylum cell, but that one person I love dearly is acting strange..."; Part Two, "Strange noises and events continue, poor Bill was killed with the passcode in his pocket, I'm worried about Loved One, I hear screams in the night"; Part Three, "I pray only that someone will find this record and end this terrible evil, it's coming to get me now argh argh argh".

The worst part is that the damn things never advance the story, because the Disturbed Journalist is always too busy being ominous and vague to actually write any details worth knowing.  But you usually have to read them anyway, because sometimes -- SOMETIMES -- there will be vital puzzle information in them.

Well, at least, the writer thinks that putting clues in the journal entries means you'll have to read them, put that isn't exactly true -- in fact, all you have to do is scan the pages for numbers, pictures, and lists of capitalized (or bold, or otherwise distinct) text, because the text itself has never been used to convey any more information than character names.  What's scary is that I don't know of ANY exceptions to the rule of "scan for numbers, pictures and lists".

Anyway.  Done venting.  But I can't believe I didn't think of this last night, it annoys me so much. :

PS regarding good writing salvaging a bad puzzle: Similar issues come up in any artistic field -- it's always true that a stylish, original, or just plain clean and honest approach can salvage something that's become hackneyed.  But lists like this are still a very useful tool, not as "Things that Must Never Be Done", but as warning signs -- if you spot an old overused trope in your work, it's a warning to pause and ask whether you ARE doing something fresher, better, or even deliberately sarcastic with it, or just putting it there because "that's what goes in this sort of scene".

PPS regarding the key-n-paper trick: maybe I'm just being provincial, but has anyone even built a door with this kind of lock in the last thirty years?  The only place I've ever even seen a keyhole you could look through was on the basement door of a very old house -- all the other locks in the house had been replaced with modern ones, which you just can't poke a key out of.

Admittedly, a lot of games are set in very old houses, often set back when the houses were new.  But even then...who locks a door and leaves the key in it?

Anything where you have to find a key to get into a room, to find the next key to get into the next room, to find another key, yada yada.  This is more common in little puzzle games of the move-crates-and-get-to-exit type.  I'd go so far as to say that the appearance of a Gold Key anywhere in the game had better have a damn good excuse.

I don't know if it's overdone really, but I dislike puzzles which hinge on a typically nice character doing something mean and destructive, which happened a lot in Grim Fandango -- Manny may be willing to shoot people, but he doesn't usually act like the kind of guy who would pour scalding coffee on a mildly offensive bystander or force his best friend to vomit.  It would be fine in a game where the main character is just nasty in general, though.

I think that recipes in nearly any form -- especially gathering ingredients for a magic potion -- are pretty tired in the genre.

And of course, crate stacking is a trope that just has to die.

I think highly of Myst in this category -- I've always liked the way the puzzles in that game didn't feel like they were set up just for the sake of puzzling, but rather, made sense as an intruder trying to get around the home of a paranoid wizard.

I finally got to play Grim Fandango for the first time a few days ago, and while I really enjoyed the story, setting and characters, I found a lot of the puzzles just frustrating and ended up using the UHS hints for most of it.

I don't think the problem was in the puzzles per se, though; rather, there just wasn't enough information in the dialogue and descriptions.

The worst puzzle in the game (IMHO) requires you to give two separate items to a carrier pigeon, but when you give the bird one item, the ONLY feedback that you get is that the bird takes it; Manny doesn't say anything and the bird doesn't do anything until the bird has both items.

Just a couple of extra lines, something like "It looks like he needs something to deliver" or "Looks like he needs to know who this is for", would have brought the puzzle down from bloody impossible to merely tricky.

True, additional hints would make the game easier, which probably isn't what the designers wanted, but withholding information seems like an artificial way to raise the difficulty.