Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
44 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to General and Gameplay Programming

2D Shooter Weapons/Projectiles

Started by
19 comments, last by Sean_Seanston 14 years, 1 month ago
Quote:Original post by theOcelot
Speaking of Weapon points, do they need to be a different class from your generic point at all?


Well apart from the basic X and Y I have 1 or 2 other variables that seem to make sense being there for what I have planned.

Quote:Original post by theOcelot
All your ideas on this one sound fine, but isn't that a separate concern that only Weapon needs to worry about? Of course weapons will have a lot of variety in how multiple attachment points are treated or even supported. But if you've already got it loading from XML, that's probably not too hard.


I suppose it probably would be best for the Weapon to deal with it... I'll have to see how to implement it that way though. It'll need some way of associating a point's unique ID with a firing order. I suppose it was always going to need to include some info on the points to use anyway so I'll just add something to that.

Quote:Original post by Captain P
Using a static object means that there's only one that's shared between all Weapon instances. Doesn't sound like a good idea, since you want multiple weapon and projectile types.


Yeah... I'll have to look into this. I'd thought of making Weapon an abstract base class but I haven't entirely decided yet. I suppose I could probably use XML to make the differences between the weapons. I might use that Type idea.

Quote:Original post by Captain P
I think Command & Conquer: Tiberian Sun made it's units manage their projectiles. Destroying a unit would also remove it's projectiles, heh. :)


Yeah, good point. How might you go about managing Projectiles then? A set of static functions in the Projectile class maybe? With 1 vector/list of Projectiles for all projectiles that exist.

However, then I suppose I'd need more data in the Projectile class to say who the Projectile belongs to or at least what team it's on. How would you manage that? You could have different lists maybe but then we're kind of at square one again.
Advertisement
Quote:Original post by Sean_Seanston
I suppose it probably would be best for the Weapon to deal with it... I'll have to see how to implement it that way though. It'll need some way of associating a point's unique ID with a firing order. I suppose it was always going to need to include some info on the points to use anyway so I'll just add something to that.


I'm confused about this firing order thing. Surely you don't plan on having repeated weapon firings cycle through all occupied weapon points, and therefore all installed weapons? I'd think you would just have an active weapon, direct all firing notifications to it, and let it worry about which of its firing points to use.
My Project: Somnopatru (SVN Repo) | Single Responsibility Principle | Other OOD articles
Quote:Original post by Sean_Seanston
Yeah, good point. How might you go about managing Projectiles then? A set of static functions in the Projectile class maybe? With 1 vector/list of Projectiles for all projectiles that exist.

Nope, no static functions - no need to go for a 'global' approach. If you have an object that manages all bullets, enemies and player(s) - say, an instance of a World class - then give every Weapon a reference/pointer to that object. They can then tell the world that they want to add some bullets. The world provides a function for this, addProjectile(...), and stores the given projectiles in it's player bullet list. The weapons then only need to care about creating projectiles whenever they receive a fire command 'from above' (e.g. the weapon system that contains them, or the plane itself).

Quote:However, then I suppose I'd need more data in the Projectile class to say who the Projectile belongs to or at least what team it's on. How would you manage that? You could have different lists maybe but then we're kind of at square one again.

For a game like this, with relatively few different groups, I'd just keep a list of player projectiles, a list of enemy projectiles, a list of enemies and a player. It's not very scalable, but this kind of game doesn't really need that - unless you have some specific ideas in mind of course. ;)

The World then manages all these objects: it updates them and can check for collisions between them (player-projectiles versus enemies, enemy projectiles versus player, enemies versus player and that's it).


As for the term 'weapon', I think there's some confusion going on here. It can be used in the sense of a weapon type: a 'blaster' fires straight forwards with strength 10. It can also be seen as a turret: the 'blaster' weapon at level 3 would fire sidewards too, so it has one turret facing forwards and two facing sidewards. The same goes for 'weapon slot': is a slot a turret position, or a more generic slot that accepts a weapon with the first meaning? So the player would have a primary and secondary slot, but a weapon that occupies that slot can have multiple turrets spread across the fighter?

Let's call them Weapons, Turrets, Slots and TurretSlots - then, a Weapon has a type, a Turret belongs to a Weapon, a Weapon is mounted in a Slot and a Turret is mounted in a TurrestSlot. Here, a Turret has a cooldown timer, it's type determines what that timer should be reset to, and a Weapon keeps track of which of it's Turrets should fire next. Wooh! I just thought that was worth clearing up. ;)
Create-ivity - a game development blog Mouseover for more information.
this sounds like a great idea. as for the projectiles, oyu should use a method like so:



first you want to know how many bulllets you want on the screen. call this variable anything you like, and set the number.



now, use a for statement.

for (int i = 0; i < bullet_count; i++){




now in the statement, you should have a bool value array for every bullet. i would call it shown.

for (int i = 0; i < bullet_count; i++){
if (!shown){
shown = true;
break;
}


so now you fire a bullet.



next, you should have another for statement or inmplement it somewhere in there.


it should be like this:


for (int i = 0; i < bullet_count; i ++){
if (shown){
bullet(); // call to the projectile
}
Quote:Original post by theOcelotI'm confused about this firing order thing. Surely you don't plan on having repeated weapon firings cycle through all occupied weapon points, and therefore all installed weapons? I'd think you would just have an active weapon, direct all firing notifications to it, and let it worry about which of its firing points to use.


Yeah, I think that's basically what I'm thinking. I must not be explaining it right.

What I mean anyway is:
I need (or would like) the ability to have certain weapons fire their points in some order, e.g. a missile weapon that fires a missile from the left and then from the right like in Desert Strike.
So, if the Plane knows about the Weapon, it can tell the Weapon to fire and the Weapon knows about the WeaponPoints and can use the fireOrder in those to determine where the weapon should fire from.

I think that's basically what you're saying.

Quote:Original post by Captain P
If you have an object that manages all bullets, enemies and player(s) - say, an instance of a World class - then give every Weapon a reference/pointer to that object. They can then tell the world that they want to add some bullets. The world provides a function for this, addProjectile(...), and stores the given projectiles in it's player bullet list. The weapons then only need to care about creating projectiles whenever they receive a fire command 'from above' (e.g. the weapon system that contains them, or the plane itself).


Right. I think I basically have something like that in my "GameplayState" class. Since it already handles the logic and rendering etc. of the gameplay, I suppose it should manage the Projectiles.

Quote:Original post by Captain P
For a game like this, with relatively few different groups, I'd just keep a list of player projectiles, a list of enemy projectiles, a list of enemies and a player. It's not very scalable, but this kind of game doesn't really need that - unless you have some specific ideas in mind of course. ;)


Ya, you're probably right. Sometimes I have the tendency to try to take future planning too far.

Quote:Original post by Captain P
Let's call them Weapons, Turrets, Slots and TurretSlots - then, a Weapon has a type, a Turret belongs to a Weapon, a Weapon is mounted in a Slot and a Turret is mounted in a TurrestSlot. Here, a Turret has a cooldown timer, it's type determines what that timer should be reset to, and a Weapon keeps track of which of it's Turrets should fire next. Wooh! I just thought that was worth clearing up. ;)


Yeah, that sounds about right ^_^

Quote:Original post by dantheman1337
first you want to know how many bulllets you want on the screen. call this variable anything you like, and set the number.


Well I was figuring on more of a dynamic approach with vectors. That way there can be as many bullets as needed and if they no longer exist they can just be removed.

Actually, which is better for removing an object anywhere in a dynamic container? std::vectors or std::lists? Or is there something even better?
Quote:Original post by Sean_SeanstonActually, which is better for removing an object anywhere in a dynamic container? std::vectors or std::lists? Or is there something even better?


First, if you only have a few hundred projectiles it doesn't matter which you use. It is faster to delete from a list, however, the relative slowness of iterating through the list will offset anything gained from the faster deletion. What is likely to be fastest is doing "array deletion" to the vector by copying the last element to the index being deleted, then deleting the last element. Vectors are contiguous memory like arrays, so if you delete from the middle all the remaining vector elements will be moved forward 1 slot.
Quote:Original post by Sean_Seanston
What I mean anyway is:
I need (or would like) the ability to have certain weapons fire their points in some order, e.g. a missile weapon that fires a missile from the left and then from the right like in Desert Strike.
So, if the Plane knows about the Weapon, it can tell the Weapon to fire and the Weapon knows about the WeaponPoints and can use the fireOrder in those to determine where the weapon should fire from.

I think that's basically what you're saying.


What I'm saying is that Weapon doesn't need any help from the points, or any data attached to them, to decide which one to fire at a given moment. In my view, the Weapon should define its own firing order, not use one handed to it by Plane.

I mean, alternation is as simple as having a bool firingOnRightSide and flipping it every time you fire.

My Project: Somnopatru (SVN Repo) | Single Responsibility Principle | Other OOD articles
For all intents and purposes, a weapon in this kind of game is just a projectile generator. As far as weapon placement goes, here's what I would do:

First off, in your Plane class, I'd put either a pointer to a Weapon object (if a Plane can have only one Weapon at a time) or a pointer to a list of Weapon objects (if otherwise) and a pointer to the currently selected Weapon in that list. Like TheOcelot said, the Weapon class should have a pointer to a "parent" Plane object. But to be honest, I think a better thing to do here is to have a pointer to a Point object instead that is equal to the Plane's Point object. The advantage here is that you don't have to worry about the Plane interface -- you can concentrate on the behavior that you want to use for the Weapon (namely getting x and y coordinates). Finally, the Weapon class should have a pointer to another Point denoting the offset from the "parent" Point, which represents the Plane's center.

While I think firing delays should be stored in Weapon objects, I think the overall firing behavior should be part of the Plane objects. If the Plane is ready to fire its Weapon, it will tell the "World" to spawn a Projectile with the properties denoted by the Weapon. Then that Projectile will be updated and rendered like all other Projectiles.

In the case of multiple gun ports and the like, the Plane would simply have multiple Weapons that can fire at the same time. For missiles that alternate between sides, the location of the Projectile to be spawned (which the Plane gets from the Weapon in order to notify the World) can alternate between two different offsets.

Hope this helps! Let me know if there's anything you'd like me to clarify.
I've a question about the Flyweight system:

Should the Flyweights have functions to access their variables or should the instances of a Plane or whatever just copy the values of a Flyweight into their own copies of those variables?
One of the points of the Flyweight pattern is that common data is shared between objects. So yeah, accessor functions rather than copying values. I would only copy those values if I had a specific reason to do so.
Create-ivity - a game development blog Mouseover for more information.

This topic is closed to new replies.

Advertisement

Popular Topics

aigan
The promise of freedom in story games Game Design and Theory
robertrobert
Facebook Ads for sales on steam, does it work? Games Business and Law
MrK45
Inheriting from application registered class AngelCode
Advertisement

Recommended Tutorials

Myopic Rhino
SDL Collision Events Engines and Middleware
Myopic Rhino
Bigger Than Big: The Game Audio Explosion Music and Sound FX
AlexVu
Game Design: A Different Approach to Difficulty Game Design and Theory
GameDev.net
Transparency in D3D Immediate Mode Graphics and GPU Programming
Myopic Rhino
Spherical Scale Mapping Graphics and GPU Programming

Reticulating splines

About GameDev.net
Community Guidelines
Terms of Service
Privacy Policy
Contact Us
Copyright (c) 1999-2024 GameDev.net, LLC
Back to Top