2
\$\begingroup\$

I am trying to design different weapon behaviors.

Right now, there are 3 different types of weapon behaviors that i would like to implement.

  1. When not pressing anything, weapon fires at a regular slow interval. When mouse Pressed, weapon fires at a rapid interval
  2. when not pressing anything, weapon does nothing. when mouse pressed, weapon charges up. when mouse released, weapon fires
  3. when not pressing anything, weapon charges up automatically. when mouse Pressed, weapon fires, and then automatically the weapon charges up.

I'm sure there are more to add, but I'm just starting to learn about composition. Can someone explain to me how I might generally write such behaviors for the weapons in a composition over inheritance manner? I'd like to be able to simply swap out one weapon behavior for another just to see how the game might change, and I don't want to have to keep copying and pasting code which is what I seemed to be doing.

I'm guessing that I should use an interface (I'm using Java) called WeaponBehavior perhaps? So then should every base weapon implement this interface? And then i put that interface somewhere within my weapon.run() loop that I have made? (Heroes have weapons, and when heroes run, they run their weapons). Or is it that there is a behavior object instead? I think this is what I'm confused about.

I'd just like to know what skeleton code might look like as opposed to what I am currently doing, which is making the behaviors for each specific weapon that inherits from some base weapon.

abstract Class Weapon //implements WeaponBehavior??
{
// should I have an object called WeaponBehavior instead of implementing an interface?
Weapon()
{
}

void run()
{
  update();
  //behavior somewhere here?  
  render();

}
void update()
{
  //does behavior go in here?  
}
abstract void render();//how does the weapon look
abstract void fire(); // this has to be called at some point
abstract void handleMousePress(); //  


}
\$\endgroup\$
1
  • \$\begingroup\$ Game programming requires special considerations for inheritance and composition, because unlike in many other environments where you can say "Object does this with that", it's more often a case of "Object does this by changing the state of that shared object, which must only be done in these conditions." Because a game can be a complicated state machine where parts must share resources like the GPU settings and resource manager and user input threads, the ideal inheritance models don't always fit in. Something to consider as you read the answers here and elsewhere. \$\endgroup\$ Oct 5 '16 at 17:05
2
\$\begingroup\$

Something like the input handler using Command pattern should work. The goal is to isolate weapons and their basic operations like fire(), charge() from the weapon's input behaviour, like the ones you've described.

The example on that page, which is typically encountered, is to translate basic input events - like mouse clicks, key presses - into game commands, like jump/fire. Doing so allows you to easily extend support to other input devices or remap controls. Your scenario is slightly different, with a different goal: of modelling different weapon behaviours.

The role of this handler - let's call it WeaponBehavior - will be to take mouse inputs, and translate that to weapon operations.

Either inheritance or composition will work here; if you choose to use composition, you will pass off mouse events to the weapon's behaviour component:

weapon.getBehavior().handleMousePress();

And you never have to operate the weapon directly - all will be handled by the behaviour component. Since this is using composition, you can replace that behaviour dynamically to get different input handling characteristics for the same weapon.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for this. As a followup question, suppose then i want the same weapon behavior but then for an AI instead and it doesnt have a mouseinput. But it might fire on some enemy when it has a target acquired under one weapon behavior type, but another weapon behavior type migth be like a spray n pray continuously firing type. . would the function handleMousePress need to be generalized to something to include human players and AI? \$\endgroup\$ Oct 5 '16 at 21:14
  • \$\begingroup\$ The input handler I linked is often used for AI; instead of being driven by an input device, you can hook up an AI routine instead. You could do the same thing and have an AI-specific weapon behaviour, and the AI handles whether to charge, for how long etc. The weapon then needs to validate the inputs and make sure it can't fire a weapon that isn't charged but needs to, and so on. \$\endgroup\$ Oct 6 '16 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.