Jump to content
  • Advertisement
Sign in to follow this  
Kimimaru

Matching Weapons with Character Movement/Animations

This topic is 2027 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone! I'm trying to have weapons in my game move as if a character is holding them. I want weapons to be rotated and in certain positions depending on the animation and frame a character is in. For reference, this video demonstrates what I'm trying to accomplish (stop at around 2:52). Notice how the weapon changes positions at different frames of an animation and follows the character's hand.

 

Now for my main question: What would be the most effective way of implementing this in my game? So far I tried hardcoding these positions depending on what the character is doing and I feel there may be a better way to get this done.

 

Furthermore, if I have a weapon that a character wears, like Brass Knuckles, chances are I'm going to need multiple sprites for the weapon when the character is on the floor, punching, walking, and etc. However, when it comes to positioning these types of weapons, can they be done the same way as the weapons your character holds?

 

Thanks in advance!

Share this post


Link to post
Share on other sites
Advertisement

one possibility:

the weapons have frame-sets which exist in lock-step with character movement frames.

 

 

another possibility:

there is some way of encoding the position and rotation of the weapon in each frame;

this could be possibly either explicit side information, or possibly a few "magic color" values in the sprites, say you have one magic pixel color for "weapon goes here", and another to indicate the rotation.

 

say, for example (R,G,B):

0,255,255 (Cyan) = Transparent

255,0,255 (Magenta) = Weapon Control Point

0,255,0 (Green) = Weapon Rotation Point (If within N pixels of the control-point)

 

as the sprites are read-in, their location is found, and then the rotation identified. during drawing each frame, the weapon is also drawn at its appropriate position and rotation.

Share this post


Link to post
Share on other sites

The second method you proposed is very interesting. I'm unsure of how I would change the position of the weapon depending on the animation frame with it, though. Or are you suggesting that I put those colors in the character animations themselves rather than the weapon sprites? Finally, which method do you think would be better (more memory efficient, less time consuming, cleaner code) to implement overall?

Edited by Kimimaru

Share this post


Link to post
Share on other sites

You want the attach points to be part of the character animation not the weapons.

 

You don't need to use colours (although you can) you just need to have data for each animation frame saying where you would attach the weapon and what angle to draw it at. The weapon sprites would need to know where the corresponding attach point is though (so you can place the attach points on top of each other when you draw them).

Share this post


Link to post
Share on other sites

Ah, ok. I can specify the drawing locations of the wieldable weapons in that case. Thanks for the help!

 

For wearable weapons like Brass Knuckles, would it be better to have frame sets that match the characters' animations, considering the fact that each sprite will be different compared to wieldable weapons which never change sprites?

Share this post


Link to post
Share on other sites

You may want to make the main character out of layers in that case, with the arms in a separate layer and swap arms for different knuckles. You probably want to do that anyway since the weapons will want to be drawn behind the holding arm and in front of the body and non-holding arm.

Share this post


Link to post
Share on other sites

yes, about the colors:

if used they would go in the character sprites.

 

basically, since they are just positions, they could also be written down as numbers in a file or similar as well.

 

 

 

You may want to make the main character out of layers in that case, with the arms in a separate layer and swap arms for different knuckles. You probably want to do that anyway since the weapons will want to be drawn behind the holding arm and in front of the body and non-holding arm.

 

going further, it could also be possible to basically compose the sprites in a modular fashion, say each separately movable part of the body has its own sprite, and they are then basically connected together via a 2D skeleton.

 

at this point, the animation frames are basically the position and/or rotation of each bone/joint, and it becomes fairly easily to have a "weapon goes here" bone as well.

 

granted, this comes with the drawback that it is no longer possible to animate simply by drawing stuff in a graphics program.

 

 

side note: for some of my own forays into 2D animation, I had actually used a custom hacked/extended version of JPEG (*1), which among other things, added support for transparency and layers. this could then allow things like procedurally enabling/disabling layers, drawing them in different positions, ... (internally, my engine treated each layer as a separate texture image, with names like "images/foo_image::SomeLayer").

 

granted, a person could also probably do similar using a format like OpenRaster, ...

 

the main reason is mostly that it is a little more convenient as it is possible to use layers in a graphics program for things, and is slightly more compact than, say, a pile of PNG images. though, yes, PNG images also work pretty well.

 

 

*1: basically JPEG + Alpha + extended components (normal/bump/... maps) + a lossless encoding mode + layers + ... basically an implementation of a somewhat hacked version of the format, which was then ported to C# and used as a Paint.NET plugin... (not going to go too much into this here...).

 

I also have a structurally similar format just based around DXTn (and lossy only), which is meant mostly for fast decoding, but haven't really made much use of it yet (nor ported code for it over to C#). note that size/quality is worse than the other format, and this was mostly considered as a possible alternative format for things like video-mapping (and supports a simplistic I/P Frame system as well).

 

 

primarily I am still mostly using conventional JPEG and PNG for images though.

Share this post


Link to post
Share on other sites

I'd stick it all in metadata or script, not encoded in the sprite.

 

This would be especially true if the character is composed of multiple depth layers, you could have the data or script indicate which layer in addition to the attach point and angle.

 

Such a system would be easily extended for new weapon types, you aren't forced to have a small knife and short knife and lead pipe and baseball bat all being held identically.

Share this post


Link to post
Share on other sites

I'd stick it all in metadata or script, not encoded in the sprite.

 

This would be especially true if the character is composed of multiple depth layers, you could have the data or script indicate which layer in addition to the attach point and angle.

 

Such a system would be easily extended for new weapon types, you aren't forced to have a small knife and short knife and lead pipe and baseball bat all being held identically.

 

yep.

 

between metadata and pixels, it is a tradeoff I think.

 

 

metadata, pros:

easily readable (just read-in whatever data);

doesn't interfere with sprite pixel data;

allows more free choice for how the sprites are stored;

if using a dedicated tool, this is probably the best way to go;

...

 

metadata, cons:

without a specialized tool, it may not be readily visible where the control-points are, or how they fit together, making sprite creation slightly more work (have to figure out which exact pixel-locations things are at, ...).

 

 

pixel, pros:

more readily visible in the sprites, if using a generic graphics editor (such as GIMP or Paint.NET), for creating sprites and animations;

if using layers, allows using layer/blending to more readily use the layers as "keyholes" during content-creation (manually drag and rotate, immediately see where it is needed to draw the control-points in the other layers, ...);

...

 

pixel, cons:

basically, we are just generating the metadata anyways, but manually at load time;

requires fussing around with the raw pixel data (to get at the embedded data), hindering the use of simple/straightforward image loading;

requires filtering out the control-pixels (since they would look ugly if visible in the output, *1);

control-pixel colors can't otherwise be used in the sprite itself (requiring caution when drawing);

effectively requires using a format like PNG for storing the sprites (need access to exact per-pixel colors, *2);

...

 

*1: say, each control pixel is replaced by a blended version of the adjacent pixels after each control-point is found/recorded.

*2: formats like JPEG will not preserve exact pixel values, nor, for that matter, per-pixel colors (the color is typically stored at 1/2 the resolution than the brightness, so there would be color bleed-over between pixels and the need for more approximate matching, and "clever" filtering to counteract bleed).

Edited by cr88192

Share this post


Link to post
Share on other sites

Wow, thanks for all the information everyone! For now I have decided to simply hardcode positions that will work for all wieldable weapons.

 

 

I'd stick it all in metadata or script, not encoded in the sprite.

 

This would be especially true if the character is composed of multiple depth layers, you could have the data or script indicate which layer in addition to the attach point and angle.

 

Such a system would be easily extended for new weapon types, you aren't forced to have a small knife and short knife and lead pipe and baseball bat all being held identically. 

 

For the metadata, like a .txt file or something, how would I specify the animation that the values go to? Right now I have the weapon position specified in each animation that requires it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!