Thanks Arc, I'll look through those later.

---


CaveCricket, I've gone with your idea but modified it a bit.



As you can see, the various components are shown up the top.
The barrel-receiver combinations are in the first set of boxes. This is what I suggest we use as a base for each gun. As you can see I have labelled 5 HDFirearms, each with three sprites. Each sprite has the same offsets.

Shown in the bottom two tables are all possible combinations of stocks, scopes, and grips. To the left they are shown attached to a receiver (just to help me with offsets), and to the right as they would appear in the attachable's sprite.
On the top left some example combinations are shown.

And now with my E-Z-Fill grid squares, it's no longer a hassle to paint a background pink! Just select the paint bucket tool and go crazy, knowing that the integrity of your spritesheet is protected by our wonderful squares.

This project is going to have a ♥♥♥♥ load of sprites.

Also the barrels seem a bit long, almost as long as the Coalition Heavy Sniper's.

Not really, you'd just have the individual gun bits.
Should be about 12 per gun manufacturer or so.

Not to mention having 4-5 duplicates of each sprite with different colors.

Yeah, that's kinda what I'm talking about.
Having multiple frames on already-attached attachments.

But wait... I think I see a bit of flaw in the idea: is the barrel destructible? If yes, then it'd be weird seeing the gun still fire rounds at the muzzle while the barrel is gone.

What if the sprite is more like this:
-base sprite is a 'bare minimum' gun, for pistols this won't be a problem but to rifles they may have to have a 'naked barrel'. Bare minimum on this case would be grip, trigger, firing mechanism (central 'box'), bare barrel, magazine.
-attachments would be scopes, silencers, bayonets, stock, foregrip (which includes additional barrel details). Each of them would have multiple frames with different variations on each one.

This way, if you want to add color effects, you could have them on a select few attachments, maybe only the foregrip/barrel and the stock would have additional colors, for example.

And if we take it further we could make it a kind of collaborative gun project: make the gun moddable, as in modders could add their own sprites into the gun.

Maybe even have the Lua file have a 'parts manifest' of sorts, like the ones used by Weegee to add factions in his missions. The idea being each part 'sprite' affects the gun's performance, for example if it has scopes it has longer aim, with different scopes having different aim length additions. Silencers would modify the firing sound, foregrips and stocks would modify the shake, etc.

So, for example, there'd be a part in that Lua file which has the stats for each part, and what sprite they'd be having.

Something like this perhaps, this is in pseudocode:


...whoah that was some stream of consciousness. So what'd you guys think about it?

...so do a simple check on trying to fire, and destroy the whole thing if the barrel is gone? Or just make it so it can't fire. Orrrrr make the barrel destroy the rest of the gun when it breaks?

I like the manifest idea, though none of the weapons are silenced in Borderlands. You'd have to get new sounds, or use ones from the smaller, weaker-sounding guns for some of them.

I like the idea of having a bare-bones base thing for the gun. On scopes, since there currently isn't an easy way to adjust SharpLength, I was thinking if there were preset combinations of scopes to gun bases.

My overall take on this, component-to-stat wise:

Gun base = Rate of fire
Grips = Hip-fire accuracy
Stock + Grips = Sharp-aim accuracy
Barrel = Bullet spread
Scope = SharpLength
Magazine = Ammunition type and RoundCount

Overall idea on the randomized gun system:

You have the bare-minimum gun base, as suggested by carrion, with basically has a cut down barrel, grip, and receiver (there are base-to-scope preset combinations). The base gun has 3 attachments: Grip, Stock, and Barrel. On creation of the gun, it randomizes all 3 of the attachments, and randomizes the type of base it will be (for RoF and SharpLength) Firing is all Lua-driven.

For sounds, there could be 2 groups of sounds: A base sound of what the ammunition sounds like, and a sound overlaid for the effect that the barrel has on the sound.

As for the Incendiary and Acid munitions, I'm not too fond of those, but I'm willing to script them.

SharpLength can be modified in a lua script.

Barrel could also determine muzzle velocity and thus indirectly modify firepower, even if all barrels for a given weapon type are the same length or maybe only vary by one or two pixels.

In Borderlands itself, the barrel of a weapon also tends to increase or decrease the amount of recoil generated - a heavier barrel makes for an overall heavier gun, physics, etc. etc.

Oh, that's new. Guess that solves one complication, eh?

Well, isn't this supposed to be inspired by borderlands, not a direct copy?
And we could pass the sounds through an audio filter or something to get a 'silenced' feel.
Or just have each silencer their own set of sounds.

Wow that's a lot of sprites, and a lot of combinations of the same basic components, making every possibility manually and then make them into separate .bmp files must be long and boring work, so to spare you that in the future I just wrote a program that does all that automatically: you give it the base sprite of the weapon, the sprites of the different attachables and it makes every possible combination of the main sprite and one to three attachables. Here it is (the readme.txt explains it all):


I hope this helps.

Uh, we're not trying to make all the separate combinations into separate BMP files. I think Ketten was simply showing what all the combinations look like.

Well using that technique I could also automatically generate the .ini files related to the generated images, that would allow for more customization and variety than lua generated weapons, and would make each gun be a single entity (which is better because of the MOID limit). Tell me if you're interested.

Preset weapons defined in INI code removes the novel of the mod in my opinion. Also, since the attachables can be GetsHitByMOs = 0, there's no issue with the MO limit.