Messages

Great job! On to AGS 3.2 it is! 

"break" can be simulated as monkey_05_06 has demonstrated (though I would like to add support for it in future).
"switch" can be simulated by using "else if"s (thoug again, I agree it's not as nice and it would be good to add switch support in future.

I can't say how many times I wanted to use a switch in my code. (I mean, all the if's and else if's are ugly and make the code unclear and bulky.)

Pretty please with sugar on top look into this for the next version! Thanks! 

using AGS 3.1.0 final:


I used to have 1 set of footstep sounds, tied to animating frames. Now, upon removing the footsteps sounds (all frames to sound 0), rebuilding all files and testing it out, I'm STILL hearing the footsteps?!?

EDIT:

after deleting all frames and re-importing the sprites to the view/loop, the footstep sounds finally were gone in the game;

[What it does]

While the more experienced scripters amongst you probably have this all figured out, I reckon the rest of you would have major difficulties getting a character to say something in the background, while animating a speech view and playing a voice clip.

If so, this module is just for you, then!

You'll never want to use the old Character.SayBackground again! 

Module:  Background Speech
Version: 1.1.0 (updated by And-Or)

Download it here!
Mediafire link

Works with AGS 3.2!

What it does

- Plays background speech with text, sound & animation.
- Supports multiple characters

What it doesn't

Lip sync. No can do.

----------------------------

character.SayInBackground(String message, AudioClip* clip, int view, AudioPriority priority=eAudioPriorityNormal);
Similarly as in the previous version, prints the message in "talking style", plays clip and animates the view. The difference is that you can do it for several characters at the same time (as many, as many overlays and channels there are). Also, if you don't want to play the voice, you can pass null as clip. And if you don't want to change the animation, you can pass 0 as view.
The displayed text disappears after a time that depends on the game speed and the length of the text. You can also make the character stop speaking earlier, using StopSayInBackground.

character.StopSayInBackground();
Stops speaking in background (audio and animation).

character.BackgroundTalkActive();
This will tell you if the character is currently speaking in background.

Fixed the verbcoin template. Check out the corresponding thread: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32745.0

Ok, new 1.7.2 version is up.

This one's got a new feature: disable inventory()

And fixes the scrolling room bug. (When I finally got round to checking it out, it took me about 5 seconds to fix. Sorry it took so long, guys! My life's been pretty hectic.)

Basically, I have a large scrolling room and the verb coin won't pop up unless I'm clicking right in the top corner.
My first question is: Is there a way to fix this?
My second question is, if it's not practical to re-jig the verb coin code (the inner workings of which I have no idea about) then what would be the easiest way to adapt a game made with the verb coin template to the more traditional cycling through options interface.

This is a known bug, which was reported by The Monk! a while back. My schedule's been pretty hectic so I haven't gotten around to fixing it yet.

I'll try to find the time to fix it, but you best PM me once in a while to remind me. (with all the stuff I've got going on I tend to forget)

oh, and btw why if we disable/invisible the character in the first room we cant pop the inventory in the next room with player visible?

actually, you can. If you want to disable the inventory (and ONLY the inventory), you'll have wait 'till I release v1.7.1 of the module (which I'm already using, just haven't found the time to upload it yet.)

When you disabled the verbcoin system, using .DisableVerbCoinGUI(true) ALL lines of code in the verbcoin module become disabled.

If you want any response to mouse clicks or what not after that, you'll have to script it yourself. (For which Khris gave a good example)

If you want the character to stop moving on clicks, you'll need to change the global setting "Automatically move the player in walk mode" to false.


Now, here's a thought for you: have you checked out the "act" property? If you use that (set it to 'true') on all your map hotspots, you don't need to disable the verbcoin module. It was designed to specifically allow for interactions with a single mouse click WITHOUT popping up the verbcoin.

I believe I put an example in the template.

I am unable to replicate this bug at this time (due to the fact I haven't used any vertically scrolling rooms yet).

Is it possible for you to send me a 1-room game with basic code which generates this error? (PM me)

In any case I'll look into it when I get some time, but my life's pretty hectic as it is right now, so that may be a while.

Electroshokker, you're right on everything you mentioned except that I think it's actually very safe to use two mouse-buttons in a game. You name laptops and PDA's as examples for environments with only one button but both those devices have two mouse-buttons as well and have had them since decades. So, allowing the player to play your game with one button only and not using them both would actually worsen your design because of over-thinking and -reaction.

ah, but my main point is to allow the player to choose the way he interacts with the game.

In those rare cases a player finds himself with only 1 button (like on Mac OS X), the player should be allow to choose the "one button"-mode rather then the default two-button mode.

By allowing customization of the way the interface responds (rather then changing the interface alltogether), the player will feel far less restricted and will always choose the way he/she thinks works best, thus giving a better gaming experience.


Consider this: most modern games all have a default profile defined for keyboard and mouse interaction, but they also allow the player to customize these.

My idea is to do the same for adventure games, but instead of full customization (except maybe for keyboard shortcuts), the player would be presented with a select amount of choices at the start of the game.

(Preferably the game remembers these settings for next time round, it would be very annoying to have to select the default/left/right mouse/keyboard/... mode every time.)

Example, the verbcoin system:

- default mode (left click pops up the verbcoin, release over the action of choice, right click deselects)
- switch right-left mode (right click pops up the verbcoin, release over the action of choice, left click deselects)
- loose click mode (left click on something pops up the verbcoin, leaves it there, click again to choose your option, right click deselects)
-...

Important is not to allow too many different modes, because that too would confuse the player.

In my case, I'd let the player make only two choices to keep things simple:

mouse or mouse+keyboard
2-button mouse or 1-button mouse

(note: the switch left-to-right mode would be invaluable to left-handed people, I'd think. We musn't forget these. Though I'm sure the OS already allows for these to be switched, which is why I wouldn't include it)

[design your gui to match your game complexity]

Well, this is certainly a most interesting post.

What I learn from this is:

- design your gui to match your game complexity:

*) if you're only going to script one or two actions per hotspot, don't bother creating 8 buttons with lots of different options

*) if you've got a very complex game where almost any type of interaction actually does something (even if it is just to give a funny comment that makes the player laugh out loud), you might consider having a few more buttons

- Inventory visibility should match how often it's used.

put your inventory on screen if you're using it most of the time, hide it (but make it accessible enough) if you're only going to use it relatively sparse

- allow for multiple types interaction with a gui control

don't be the guy to create only one type of interface and then FORCE the player to use this and only this way to do stuff. Allow the player to choose from a (limited) variety of types:

*) the simplest being able to switch the left- and right- mouse button functions
*) the ability to use keyboard shortcuts
*) the ability to play the game with ONLY your left mouse button (I mean: laptops, PDA's, ... not everyone HAS 2 mouse buttons and a mouse wheel, you know)

- Use the LOOK function properly if you've got it!

Don't just state the obvious, give the player EXTRA information, as that's what it's for.

------------------------------------------------------------

I, for one, found this article and resulting comments very refreshing. It inspires me to improve my own game even more and check and double check so that there are no "you can't do that" or other blatant annoyances in it.

Though I'm more of a "let's give the player all kinds of options and make sure he WANTS to try out ALL of them" kind of guy, I'll probably give gui design some more thought next time around.

If I find the time I'll most certainly rework my current verbcoin module and game template to incorporate these lessons in the extend it's possible. (after all, it's still the choice of the game creator to use or not use any and all functions)

(And if I find a LOAD of free time I'll work on creating other templates which also include these lessons but for different gui types)

Always nice to get positive comments.

Anyways,

we're still looking for animators, as there's lots of stuff that still needs to be done.

We only need a few more character animations, it's mostly "action" animations (tiny cutscenes) and possibly some ambient animations that need to be done.

We've got pretty much every other angle covered, so:

If any of the following applies to you, please do not hesitate to contact me. (via PM or email, mailadress is on our website)

- If you love Monkey Island games
- If you like to work on a bigger than average community project
- If you like adventure games made in stunning 2D graphics
- You just got waaay to much time on your hands
- You got a little time to spare and like to share your experience

Any help you can give is appreciated. The only requirement is you show something you've recently made.

Version 1.7.0 is up.

- buxfix: message ordering when you've got objects/characters on top of each other. The label gui will display the text property of the instance that is on top now.

- new feature: default messages. enable/disable at your leisure, change the default messages at any point in the game, use in combination with the custom messages if you like.

Hi,

I've been using version 1.6, and I don't know if these points have been mentioned before, so I hope I'm not repeating stuff.

Because the module checks for hotspots before objects, objects situated over hotspots caused the wrong message to appear in the status line. Reordering the script sorted the problem for me. Though I'm not certain of what whould happen if characters overlapped objects or vice versa.

Hmm... good point. Basic AGS order is character => object => hotspot I think, but for characters/objects it really depends on the z-order (and thus the baseline).

I'll fix that in the next release. Thanks for spotting this!

Also, I found I had to individually write "examine x" for every object. Is that the way the module is meant to work? I added a couple of lines which check if the custom repsonse is empty, and if so send a string saying "use/examine/talk activelocation" to the status line.

I think it would be good if that was built into the module, because it would only require users to create custom responses for certain objects (i.e. eat rather than talk for food).

Yes, that's exactly how the module's supposed to work. I used to have a function which filled in a "default" message every time, but since I like to keep it as flexible as possible I removed that and replaced it with properties.

I'll probably add a brand new function which allows you to choose from 3 options:

- no messages
- default messages (customizable through a function call at any point in the game)
- property messages

That way you'll have all the flexibility you need. (and of course you'll be able to switch between these 3 modes in mid-game)

Great module though, keep up the good work!

-Ali

Sure will. If people keep giving suggestions like these, the module will be a great extension to AGS.

And if I ever do get the time I might consider working out other gui templates for AGS 3.0 (If there's a request/need for them anyways).

Major update: version 1.6.0 is up 

- Lots of bugfixes
- A brand new feature: the ability to disable the module at any point in the game

help file on new function:

Code: ags

SCUMM_VERBCOIN_GUI DisableVerbCoinGUI

static SCUMM_VERBCOIN_GUI.DisableVerbCoinGUI(bool value)

Activates/Deactivates the SCUMM Verbcoin GUI system

Example: 

SCUMM_VERBCOIN_GUI.DisableVerbCoinGUI(true);

will disable all verbcoin processing code.

correction: only the objects aren't tinted properly with ambient tinting (they're simply not tinted at all)

characters are tinted just fine. (I'm in 32-bit mode)

If I tint the objects manually (object.tint) it works the way it should.

From the help file:

To turn it off, call this command again but pass the saturation as 0.

Thx! Can't believe I missed that!


btw, Chris: v1.6.0 of the scumm verbcoin template is up

[*bug report*]

*bug report*

dynamic sprite tinting colors differently than object/character tinting

when I do something simple, like:

background.Tint(0, 0, 0, 50, 0); //using dynamic sprite
SetAmbientTint(0, 0, 0, 50, 0);

the objects and characters "stick out" in the resulting screen qua coloring.

(btw, any chance for a RemoveAmbientTint() function?)

Thanks for spotting that -- if you try to Crop a totally transparent sprite the editor gets confused.

This is now fixed in the Final release, which is now available.
Barring any major bugs, this should become the official release of 3.0.2 in a few days time.

Since I didn't spot it in the release notes, I thought I might mention that SCUMM VERBCOIN GUI v1.5.4 has been up a while now; You might want to include the updated template 

Great job with all the improvements and fixes!

Another update version 1.5.4, changes are:

- removed confusing commentary of old (Alarconte, you're NOT supposed to change ANYthing in the module code, it automatically supports any verbcoin size and any resolution)

- fixed another bug: when a couple of hotspots/characters/objects where close together, the label gui would display the wrong text, this was confusing when playing the game.

I don't know how to the template use my oversized verbcoin. It has 141x140 pixels, and the game its shows Cutted.

Increase the overal size of the gui so it matches the size of your verbcoin.

And too I see the change of image button is so slow. Why for?

So you can have verbcoins with buttons of which the images overlap one another. It allows for more flexibility, though it is indeed slower then if you use seperate button images.

to activate a new button (I simple want a button to pickup objects), Is there more needed than expand the button size and all of that? My pickup button (custom_button3) don't "ilumine" (don't get mouseover and is unuseful).

You have to define the new button's image in the globalscript:

Code: ags

SCUMM_VERBCOIN_GUI.verbgraphic(bCustom3, 0);

replace the 0 with whatever sprite number you want it to be.

[Unknown character name: layer]

I thought it was a good idea to review some of my game's dialogs, so I tried to create a voice acting script.

Next thing I know, I get the following error:

Unknown character name: layer

Now, I use player.Say() a lot in my game, so I believe it's related to that.

I suspect since player isn't defined as a character, the export script blocks on it. Maybe you could define player as an internal character named "player"?

(and no, there's no layer.Say anywhere in my code)