How I add weapons to Dead Pixels.
I’ve realised that I don’t go into many details about the backend of Dead Pixels, which is a shame because I like to read about that kind of thing with other peoples games.
So in this blog post I’m going to show start to finish how I add a new gun to the game. In this case it’s going to be a sniper rifle.
So first I add the items name to the code in an enum called itemNames.
I called it simply sniperRifle1. This is just a simple name for for the back end of the game.
Next I add it to the item database. There are 11 fields I must fill out for it here.
- Name: This is the simple name I used before.
- Clean Name: This is the name I want to be shown in game.
- Description: This is the item description used in game. (weapons do not have a description)
- Weight: This is the items weight.
- Buy Price: The items default buy price
- Sell price: Default sell price (It’s easy isn’t it?)
- Type: This is the item type. In this case it’s weapon.
- Chance of being in a building: This is a number that represents how common the item is. The higher the better.
- Chance of being in a store: Same as above but for stores.
- Max amount: This is the maximum amount of the item you will find when raiding a house. This stops you from finding 4 of the same shotguns in a house.
- Level: The level represents what street the item should start appearing in stores and items. There is still a chance of it appearing before then but it is very slim.
Once the sniper rifle is in the items database I add it to the weapons data base as well. There are 19 fields in the weapons database.
- Name: Again this is the name we put in the code. (sniperRifle1)
- Damage: This is the default damage of the weapon.
- Shots per second: This is how fast the gun fires.
- Range: This is the horizontal range of the gunfire.
- Width: This is the vertical range of the gunfire. for example the rifles have a very low width where as the sawn-off shotguns have a very high one.
- Penetration: This is the percentage of damage left as the shot goes through each zombie.
- Ammo: This is the type of ammo the gun uses.
- Stun Time: This is how much time a zombie is stunned when they are hit by a shot from the weapon.
- Melee stun time: This is how long a zombie will be stunned if you melee them with the weapon.
- Vol: This is how load the gun it. Load guns will alert nearby zombies to your presence.
- Gun Sprite height: This is where the gun is on the player sprite sheet.
- Flare sprite: This is a number which represents which muzzle flare is to be used when the gun fires.
- Gib: This is if the weapon “gibs” the zombie when they die or not.
- Sound: This is the sound the weapon makes when it’s used.
- Reload Sound: This is the sound the weapons makes between shots.
- Ammo used: This is how much ammo is used with each shot.
- Fire: This is if the weapon sets zombies on fire or not.
- Shock: This is if the weapon gives zombies and electric shock or not.
- Freeze: This is if the weapon freezes zombies or not.
Now it’s time to do the sprite work.
I separate out the legs, head and body to make things easier. Each new kind of weapon needs it’s own set of body frames containing 6 frames.
- The 1st is the normal idle frame.
- 2nd is the melee frame. (This frame is twice the width)
- 3rd is reloading.
- 4th and 5th is for throwing grenades.
- And 6th is for the gun firing.
Of course this is just the frames for one character. Currently there are 10 in the game so sprites for all of them must be done. So each new type of weapon needs 60 frames, but if it’s a similar weapon to something else i can use the same set of sprites for multiple wepons.
Finally I test it and make changes as necessary.
And thats how it’s done.
CSR-Studios 
What program do you use to draw the sprites, just wondering?
December 17, 2011 at 11:19 pm
I use a free program called paint.net.
It’s maybe not the best for pixel art but I’ve used it for years.
December 19, 2011 at 4:58 pm
How is the database incorporated in xna?
Do you have to do a lot of processing, or is it sorta built in (like the language stuff?)
December 18, 2011 at 5:23 pm
I use csv files. They are read in and converted to the appropriate value types when the game starts.
Someone once referred to it as a ghetto database. Which I kind of like.
December 19, 2011 at 5:12 pm
I’d be interested in seeing (+ possibly stealing :)) the code if you ever fancied writing a little article about it.
It seems like the kind of thing they should really have included in xna by default.
December 19, 2011 at 5:24 pm
Is the sniper rifle already in the game now? I haven’t seen it yet.
December 20, 2011 at 8:55 pm
It will be added very soon in an update.
December 21, 2011 at 1:57 am
I would probably have chosen the enum method myself. But I’m surprised you don’t just store the string in game.
I would have thought you wouldn’t need to reference individual weapons in code very much more than setting starting weapons, in which case you could avoid having to keep the enum (and requiring keeping it in sync with the data) by just having a flag in the database for starting weapons etc, and querying the weapons db in game to get the right weapon(s).
This isn’t intended as criticism btw, It’s really cool that your sharing, and I just like discussing code 🙂
And you could have just appended the code to the bottom of your article for all to abuse! 😀 (even if I didn’t get a follow up email, I probably would have noticed it eventually 😀 )
December 21, 2011 at 11:54 am
I have thought of using a string rather than an enum. I like the idea of not having to change the code to add new items.
There are a few places I reference individual items in the code most could be removed with some changes to my DB files or new files, except for usable items. Most of them use code that no other item uses, so I couldn’t easily make a new part of the DB listing item and effect.
Also I kind of like that the game will crash when it starts if I spell an item’s name wrong which is a nice way to make sure that my spelling will never cause a problem.
December 21, 2011 at 1:17 pm
Regarding unique effects of “Usable items”, in my (probably twisted) logic are game behaviours, whereas the items themselves are game data. You could list (assuming you need more than 1 per item) an items behaviours in a db field, and parse it out to link up with a behaviours enum.
But given how much text I would need to fully explain myself, your way is probably more sensible 😀 . If you have mostly unique behaviours, you would end up with pretty much the same thing anyway.
I’m used to working with engines that don’t complain sensibly when incorrect data happens in addition to a general desire to avoid duplication – hence my dislike of trying to maintain data in two places.
You could also encode values for special properties for items by having a list of behaviour objects within your ingame items database item, and then parsing something like
name, behaviours
“fishing rod”, fishing=10
“super fishing rod”, fishing=20
“smoke grenade”, smoke=5 radius=10
when parsed, this could find a do_fishing_behaviour and set its effectiveness
and a do_smoke_behaviour and set its radius and power
then when the player uses said item, it just calls act or whatever on the items behaviour(s)
[Sorry I’m totally abusing your site to psuedo code my future projects :D]
December 21, 2011 at 2:01 pm
For a sequel/future game I’d probably go for something more like that, but I don’t feel like gutting the current system in Dead Pixels for around 13 items.
Since release I’ve already gutted and replaced the code for how I store buildings and cut-scene data, I’ve made some classes static (should have been like that from the beginning) and I’ve added a custom controls system with support of keyboards.
December 21, 2011 at 3:01 pm
If it ain’t broke, don’t fix it …. too much 😀
December 21, 2011 at 4:20 pm