In my current project I am creating a 2d game (rpg) which should be able to dynamically create new weapons and armor based on different components. So, i.e. a sample weapon would consist of barrel1, grip3, etc. It's much like Borderlands, but in 2d.

I thought about using a library like CImg in order to assemble the different parts (which are images) and then using the created sprite in my game.

Am I on the right way? Is there a better way to accomplish this task?

  • \$\begingroup\$ Just draw them on top of each other. \$\endgroup\$
    – API-Beast
    Apr 26, 2014 at 12:48

2 Answers 2


Have different spritesheets for every weapon-component you load as separate image resources. When you want to draw a character, you first draw the character-sprite, and then the sprites of each weapon-component, one after another.

Keep in mind that in some cases it might be necessary for some parts to change the drawing offsets of other parts. You might, for example, have a silencer-part which fits on the barrel of a pistol, carbine or sniper rifle. You can use the same sprite for each, but would have to draw it at different positions depending on how the barrel-part of the gun looks. That means each barrel-part would need an additional property which says where a muzzle-part would need to be drawn. Or maybe the weapon has multiple barrels. That would mean multiple silencers would have to be drawn with different offsets (Silenced gatling gun? Why not?).

Should performance be a concern, you could use sprite-batching as a performance enhancement. Sprite-batching means to draw each animation phase with all the sub-sprites to an off-screen image and then draw the actual game using that off-screen image as a source. That way, when you have a sprite consisting of 5 sub-sprites, you only need to do one draw-call per frame and not 5. However, converting that off-screen image into a graphic file and saving it somewhere is of little use. Just keep it in the native texture format of the graphic API you are using. The only use I could think of would be to save the complete spritesheet together with the savegame to speed up savegame loading. But considering that we are talking about a 2d game here, I doubt that this optimization would be worth the effort.

Whether or not that library fits your requirements is a technology-question, and what-technology-to-use questions are off-topic here because they are usually subjective.


It is a tree structure at heart. You have the "bare weapon" ("un-enhanced") which has n slots for extensions that will be positioned accordingly in with some translation, rotation or scaling possibly (S1, S2, ... Sn) and once you add an extension, it may open up new slots for extensions that will be positioned relatively to that extension's position.

So if you placed extension A in slot 3 and A has 2 slots then slot 3 is taken and the new slots (3, 1) and (3, 2) will be placed and could be occupied by new suitable enhancements.

So basically you have the root of the tree which is a basic un-enhanced weapon type. It has slots where new enhancements could be added randomly by the generator and possbly some enhancements could be further adorned with more complicated improvements if that enhancement has its own slots. You basically need to randomize recursively and decide in each step what to add. Some slots could be occupied with mundane stuff and on rare weapons they may contain some important improvements.

To position the pieces that you add to the weapon you could wither use a slot specific transformation matrix that will move, rotate and scale the sprite pieces accordingly or use the needed math to position the enhancements accordingly.

The bottom line is that as a data-structure the underlying idea is a tree that grows recursively as new pieces are added in, possibly with some constraints (perhaps you don't want a cannon with a silencer on top of it).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .