Post your Behavior Requests here

#1 I'm working on a for-sale behavior pack, so I'd be interested in putting in time to make peoples' dream behaviors, too!

#2 I have not play with TGB in while I am not sure if this is there. A player health bar would be nice.

#3 Request goes for: component based, goal oriented AI system with path find component (within tilemap trhough A* or HPA* and with general collision avoidance, potential fields outside), group brain behavior like flocking and call for help (within radius, calling entities with this same component and a specific type *string*).

#4 I was kinda hoping for "something that plays a fart sound when it hits a wall" but ok :)

#5 Dude, the fart sound WOULD be awesome though

#6 Here's my own personal requests, though I suspect someone might be able to make these specifics become more generic.

Selections: Behavior would require designation of a 'container' object (or objects) to hold current selections. When an object with this behavior is clicked or drag clicked, it is added to the container. May or may not have user-defined visual indicators of selections and 'rubber band'.

RTS Movement: May work stand-alone (not sure how, but figure some creative coder could find a way :) or require integration with Selection behavior. When an object is selected, user defined inputs tell the object to move to a location (EG: After selected, right click will order movement to that location. EG2: User-defined keyboard "M" followed by left click orders movement)

#7 Nice one Trace.

for the selections, it would be useful I think to seperate out the "selected" behavior from the "selection set". So you would have a seperate object (sceneobject) with a "rubber band" behavior, that behavior would then set a "selector" onto any object within the rubber band region, this selector would automatically assign a group id to the objects too.

I suppose what you could have, is a sceneobject that overlays the whole scene and handles all mouse input (clicks, rubber banding etc). Have seperate behaviors for clicking and click->dragging. Both could query the scene to determine context (on unit, wether a selection is already in place etc).

Actually this sounds very much doable.

#8 I have selection behaviors here ...
MouseSelect behavior which is added on the "mouse pointer object" and draws a nice rect with a specified graphic. This mouse cursor holds its own selection set

and MouseSelectable behavior which is added on anything that can be selected, which support selectable, multiselectable and a "on selected graphic"

Guess what: yes, intend for rts / action adventure mix.

Would just need to clean them up as they are only partly implemented (with more features than just those) and could put them online.

If there is interest, I can put them on the TDN later this week.

#9 When you click it plays a certain sound.

change the "shoot" to accept mouse inputs (have to use mouseshoot).

moves toward object until a certain distance then flys straight.

mostly changes to the stock ones to add a little more. Odds are I'll fiddle with it to see if I can do any of them but hey, two heads are better then one. :)

#10 Phil:

Quote:Nice one Trace.

Thank you Phil. I've been working on implementing these functions in old-style script, using the very outdated RTS genre tutorial on TDN as a base template. I've been wanting to convert them to using behaviors, as this would end up cutting later dev cycles in half.
Unfortunately I just don't know enough about how behaviors work beyond the simple stuff in the Playground. Complex behaviors and behavior interactions are beyond me.

Quote:for the selections, it would be useful I think to seperate out the "selected" behavior from the "selection set". So you would have a seperate object (sceneobject) with a "rubber band" behavior, that behavior would then set a "selector" onto any object within the rubber band region, this selector would automatically assign a group id to the objects too.

Excellent suggestion here, and more evidence of why I'm having a hard time converting my game logic to use behaviors.
It's a matter of breaking things into smaller, and even smaller, pieces. I can't see the less-than obvious breakpoints.

I would go so far as to add extra behaviors for each stage of selection. IE Marc's suggestion:
IsSelectable - Would tag any object with this behavior as elegible for selection.
Beyond that I'm having a hard time figuring out the rest honestly. I can run it through my head using callback scripts, but not how to encode those into behaviors. Either I need more practice/examples, or just more sleep (3am here).

Quote:Actually this sounds very much doable.

Well, if yer willing to whip up even generic behaviors like this, I'd be more than happy to chew them apart to see how they work and how I can use em in my project! :)


Marc: Would you mind if I got a hold of those behaviors (as-is or polished, either way)? I can gnaw on them for a while and see if I can figure out how things work better.

Later all!

#11 I will upload my MouseSelection and MakeSelectable behaviors cleaned up before weekend so you will be able to have a look at one potential approach (what I basically do is missuse a mouse graphic object, use the callbacks on it instead of a "fullscreen object" and get all objects within a pick area or below a specific point and check their behaviors if they are selectable or not. and in case I find a multi selectable, set a global flag $multiSelect. The "is selected" rendering behavior is done through setting a variable on the MakeSelectable behavior and check against $multiSelect, all in the onUpdate of the MakeSelectable behavior)

#12 Marc, in your methodology, how do you support multiple selection sets (i.e. groups of units with hot keys, for instance, select 3 units, press Ctrl 1 and get group 1. Select 4 units and press Ctrl 2 and get group 2. Then toggle groups with 1 and 2.

Did you have that kind of functionality in mind?

I guess you could implement that by having a selection group id in with the selectable behavior. Then set that id if you get that keypress (using an event) and you are currently "selected".

#13 I do not plan to put the keyboard handling into the MousePointer behavior.
Reason is that there are more than only "group assignement" shortcuts to an RTS and for that reason I prefer having them either in an own behavior or straight within the script on its own. Haven't fully thought of how it would be best, but most likely a behavior that scans for rtsUnit and rtsBuilding behaviors in the selection to get them for its shortcut handling.

The selection id in the behavior would be one way of handling it in the background, but I thought more of a handling within the keyboard tracker behavior. To prevent "realtime retrieving" all the time. Assignements don't change unless ctrl + number is pressed which is handled through the keyboard tracker.

What I haven't added yet, as not fully thought through, is a selection group id on the MakeSelectable behavior for a different aspect: I don't want units and buildings to be selected in the same attempt, or buildings of different types. But I have not fully thought of how to handle them. Priority would be one way and just select the buildings of the highest priority ...

either way, my behaviors can be found at:

tdn.garagegames.com/wiki/TGB/Behaviors/MousePointer
tdn.garagegames.com/wiki/TGB/Behaviors/MakeSelectable

EDIT: Someday I will learn that this board unlike any other, is incapable of making http:// automatically into an url

#14 Thanks for posting your behaviors Marc, I'll get busy chewing them up this weekend. :)

As for saving group selections, I think Marc might be onto something.
Just analyzing the logic flow from a non-behavior aspect, how would you handle it?

Most likely you'd have a method embedded into the onKeyDown (Is it onKeyDown or onKeyPressed or something else? Can't remember) for the number. Within this callback, check if the Ctrl modifier was used, if so check for a current selection from the Selection method/behavior, if found add the objects within that selection to a specified container object. If the Ctrl modifier isn't pressed, look for a saved selection within the container assigned to that number, and if found make the saved selection the new current selection.

Now how can we break this apart into behaviors?
I'm assuming that we're going to be adding the selection/multiselection/whatever behaviors to a specific object in the scenegraph, which may or may not actually be rendered to the window, correct?
If so, we could add yet another behavior to this controller object. One which contains our needed callback methods.

Would this be feasible?

Edit: Since we've started drifting topics from behavior requests into specific behavior designs, I took the liberty of starting a new thread. Feel free to join me over there, or else we can continue to banter here.
New thread at: www.garagegames.com/mg/forums/result.thread.php?qt=65560

#15 Back on topic with a behavior request:Pie menus! Nesting, modular pie menus.

#16 @fucifer - I have a simple health bar behaviour.

@arch_stanton - Pie menus would be cool.

Also a few others like image based life counters. Teleport / Startburst / PowerUpShoot among my more useful ones. If any one is interested in seeing them in action you can download my little asteroids clone here

What I would really like is an behaviour state machine. The machine has behaviours attached to it . It then picks one and applies it to its owner and removing the previously applied one. There are obviously other ways of doing it but it would be useful as a behaviour.

I think the behaviours should really be as simple and easy to combine as possible. With the current set its pretty easy to make some cool objects.

#17 Requesting a behavior to assign a sound file to a collision. I'm new to TGB and scripting and have searched the documentation up and down and cant find anything concerning this. Of all the tutorials I have completed none includes adding sounds to collisions. The only tutorial I found was the one adding music in the background. A behavior would be nice! I'm working on a pong style game and I'm only using behaviors, so any help would be great.

#18 That should be extremely simple.
Have a look at tdn.garagegames.com/wiki/TGB/Behaviors, there's several behaviors there that deals with collision, just pick one (like the " Swap Image on Collision" for example). That will give you the idea on how to call code when a collision occurs. For playing sounds simply look up alxPlay in the documentation. Should take you 5 minutes or so to piece together a behavior.

#19 Magnus, Its a little difficult to call a code that I don't understand. As I said before I'm new to scripting. If it only takes 5 minutes or so would you mind throwing one together for me? I'd be very grateful.

#20 Some other behaviours that could be useful...

Target cycling. Cycle through nearest to furthest enemies highlighting them as you go.
Radar.
Homing Missile Behaviour.
On Remove Show Points Behaviour.

Some of these are kinda related ;) If I get some time I might have a stab at them. I've still got a bit of a headache from making a proximity mine behaviour work correctly. Was kinda fun tho and does work a treat. Definitely an interesting behaviour to work on that one, it has optional target tracking when you are in range / delayed detonations / mounts and code added behaviours.

@flyingpixel - PlaySoundOnCollision should do the trick ... like Magnus said 5 mins. If anyone wants to clean it up and stick it in the wiki be my guest. Any way flyingpixel .. take some time looking over the behaviours that are supplied and playing around with them. You'll learn a more about them doing it yourself... that said, its nice to have some help starting out.

Edit- Updated URL