ActionMap versus behaviors

#1 Yes, you can use either.

ActionMaps still remain useful for global input (say, in game, escape to bring up menu) even if you control your gameplay via behaviors.

#2 The behavior template is also using an ActionMap. The one you linked to from the fish tutorial is using the GlobalActionMap, which the input guide talks about. It's all really the same thing - you can package keyboard bindings in either behaviors or a class hierarchy structure. Depends really on your programming preferences.

So it's not really a case of choosing one or the other as your subject line hinted at - you have to use an ActionMap. How you implement it is up to you though.

#3 @Mike

Thank you for your reply, and I do see that there seems to be something tying them together. Are you referring to the BehaviorTemplate and then the named ShooterControlsBehavior as the actionmap? I do prefer the behavior approach I believe, but I want to work on a full understanding of the system.

Edit:

After looking back into the code, not just the online tutorial, I found what you meant. In this case, the addBehaviorField just associates a key with a variable that can then be bind to an actionmap? Is that the main goal of using the behaviors for controls?

#4 Whoa, no - the main goal of behaviors is to allow complex object behavior to be assembled from simpler parts.

For example -
The projectile object for an Angry Birds clone would have many simple behaviors with connections between them. A "dealsDamage" behavior, a "playIdleSound" behavior, a "playIdleAnim" behavior, etc. and connections so that when launched the "onLaunch" behavior told the "playLaunchedAnim" behavior to start and the "playLaunchedSound" behavior to start.

Try to break down a given game entity's "things it does" list into it's most basic set of stuff. It moves, it does damage, it plays animations, it plays sounds, it takes damage, it displays a health bar, etc - each of these can be a simple behavior, and the entity can carry them all. Then the behaviors can have connections assigned so that they can communicate amongst themselves, triggering behavior state transitions.

For a high-level overview, check out the description of the Component pattern: http://gameprogrammingpatterns.com/component.html (oddly enough, this is also covered in an even more general programming context in Design Patterns).

#5 Oh, I didn't mean all behaviors. I just was referring to the ones in the example is all. They seemed to specifically focus on using them as controls.

Speaking of that though, are there any limitations on the keyboard events being handled? I currently am trying to manage an issue with a character aiming diagonally using two keys as well as shoot. I am assuming and working on it as if it is a logic error, but as it seems so simple and yet not acting correctly I do want to assure myself it isn't an issue with the ActionMap and events being handled. Is it acceptable to use the onUpdate callback on a controls/ActionMap/behavior type of situation?

#6 Well, not sure how well the system handles "combined" keypresses. Haven't really given it much thought, but it should work fine unless one of your keys is defined as a "modifier" key (like ctrl or shift) - in which case it will be treated differently.

Arrow/WASD for movement (8-dir, I'm guessing?) and space to fire should work - or arrows to move, WASD to fire...

#7 Aiming uses the arrows with 8 directions and the spacebar is to shoot. I guess I must get caught up somewhere. The only slight difference I am using is onUpdate to actually cause the aim to change and bullets to shoot.

I think I will assume now that it is something I am not realizing in my code as it only happens with certain directions.

It actually has the same problem when moving (different behavior cs file) and aiming. It is almost as if one stops and doesn't execute.