[disc] 6 ways to kill an enemy or: how to code a bullet

hi folks,

for the game I'm currently working on, i needed some bullets to fly around
and do some damage.

but how to code a bullet?

easy, you might say, though it is easy, but is it the best way?

while thinking about it i came across some different methods to do the same thing: letting the bullet fly into a certain direction and either hit a sprite, a wall or just "fade away".

i'm quite used to software abstraction, so i tried to narrow down the behaviors of the different bullet-types to the basic needs in order to have only one class for all bullets. (player / enemy 1 / enemy 2 / ...)

method a)
- create an MC in the library, set the linkage AND an AS2 class.
- the class would be an extension of the MovieClip class, so i could override the onEnterFrame event and init the class with an object to set the start values (read about it on LiveDocs: http://livedocs.macromedia.com/flash...=00001336.html)

- pro:
-- very straight forward method
-- every needed method can be contained in the Bullet class
-- could overwrite onEnterFrame to make it move and a simple hittest to check for collisions
-- attach and go ...
-- no loops needed to move bullets

- contra:
-- do you really want to use one onEnterFrame for each bullet?
-- need to keep track of new bullets depth
-- need to keep track of bullets in game
-- each bullet must be aware of it's surroundings "game world"

method b)
- same as a, but using an ASBroadcaster instead of the oEFs
- create an "onMove" event in the bullet class that gets fired by the ASBroadcaster

- pro:
-- same as (a)
-- still straight forward
-- still no loops needed

- contra:
-- same as (a)
-- the need to remove unused bullets from the ASBroadcaster or keep track of "used" bullets to reuse them

method c)
- create a bullet manager class that handle ALL bullets in the game

- pro:
-- no need to worry about bullets in the game
-- the manager would keep track of depths /counts and so on
-- could use either a loop to move bullets or use the ASBroadcaster
-- all bullets would be simple objects with a reference to the MC and the needed values
-- since the bullets would be stored in an array they could be added and removed without problems
-- reusable for future project

- contra:
-- quite a lot more work to write the manager, since it needs to be more
flexible than a single bullet
-- is it needed?
-- extra parameters for different bullet types (or extra code)

method d)
- a mix of a/b and c

method f)
- keep track of the bullet inside the player/enemy object

- pro
-- very straight forward
-- easy to keep track of "bullets per object"
-- easy to combine the movement method with the object's "action" event

- contra
-- not very "clean" separation of the game's objects (player, enemies)
-- extra bullet handling code per object needed (eg. different enemies)

i came across some more, but i thought this might be enough for a serious discussion.

so what do you guys use/think?

nGFX

ps: i have already found my method of choice and i will tell you somewhere later in this thread (if it starts at all), because i don't want to "preselect" an idea for this discussion.

Well for my never-going-to-finish spaceshooter, I have one bullet class which contains all the methods, including removal, hitting the player(separate class for enemy bullets and player bullets).

I always have a game class which contains a function that loops through all of the bullets, all calls the command update(all enemy bullets are in one clip).

So there is only 1 mc, just pick the frame depending on the bullet. I have a sub-object in the game class which stores all of the information(each object has a pointer to its appropriate mc), though the subobject isn't a class, the game class controls it.

I find it quite easy to manage(and for mine the bullets have different moving patterns, so I just have a move function and point it to the appropriate move command required).

Didn't really pick a choice, just talked a bit. :p

Are you trying to steal my title as DISC king? ;)

(THIS SPOT SAVED FOR REPLY...)

ah thats a good question I would have to go with c.). I feel its always important to keep track of both the players and bullets in one spot and where the collision occurs. I always like to keep my games open for change. I think that method is also easier to deal with when making a Myltiplayer game. With 10+ users shooting bullets, it'll be easier to handle them all in a bullet manager class.

Ever thought about not having bullets :) i mean each time you fire off a bullet. Work out the path/direction of the bullet and instead of testing wether a bullet is hitting an enemy make it so the enemy checks wether it will move into the path of the bullet.

Quote:

---

Are you trying to steal my title as DISC king?

---

yes. HAHA!

Quote:

---

checks wether it will move into the path of the bullet.

---

though you stll have to keep track of the "sprite" that represents the bullet. and you will have to do these checks every now and then, too. (the enemy might just move into another direction or "teleport" away or may be dead already)

thinking about it, this opens another question:

test if the bullet hit the object

OR

test if the object is hit by the bullet?

both ways have their advantages. if the checks are on the bullet you'll have to loop over the objects, if the check is on the objects you'll have to loop over the bullets.

so method F might have less loops (cause you know how many enemies are out there and each enemy knows how many bullets he has fired)

Quote:

---

I find it quite easy to manage(and for mine the bullets have different moving patterns, so I just have a move function and point it to the appropriate move command required).

---

Quote:

---

is also easier to deal with when making a Myltiplayer game. With 10+ users shooting bullets, it'll be easier to handle them all in a bullet manager class.

---

yup. same way here.
i use a bullet manage class together with the ASBroadcaster, it has slightly bigger coding overhead than just looping over them, but i don't have to use loops and the broadcaster is quite fast (though, i haven't tested if it is faster)

Quote:

---

I find it quite easy to manage(and for mine the bullets have different moving patterns, so I just have a move function and point it to the appropriate move command required).

---

(sorry for quoting it again) :) so what do you think about OOP paterns, then?
i thought for a very tiny moment about the idea of using base-bullet class and inherit each bullet type from there. but then, when using a bullet manager, i used a simple object ( {x,y,dx,dy,mcTarget,...} ) to store the data needed (instead of "new BulletA()").

nGFX

I'd go for f) blue.

I know you're doing this AS2, so some of this may not be too relevant.

The player I never use a class for, can't see the point of creating a singleton for the sake of it. Good ol' fashioned functions do me fine there.

Baddies I use a superclass, with the child classes being the different baddie types. Also I create child classes of the bullet object within this superclass too.

Simple little loop on a enterFrame goes through all the baddies calling their current activeMethod() ( Which is just a function pointer, so one call always gets them doing what I want ).

Within the baddies mainloop I also call the bullet handling code ( Is he going to shoot ? Has he shot ? Move the bullet etc. ), again a function pointer.

If the baddie get's killed, I just run his dying frames and make sure the routine for that checks for the bullet too. That way a baddies bullets don't die with them ( So I flag up that the baddie is dead, wait for him to actually die fully, and then alter the activeMethod pointer to just handle the bullet ).

Bit of simplistic write up, but that's pretty much it.

Squize.

i knew you would.

mhm. i just looked at my code and i think i'll try to simplify it even more.

nGFX

For smaller game when i am lazy i use a holder clip attach all bullets into it and the holder clip has an onEnterFrame event to update all bullets. You have the advantage of testing all the bullets at once against an object before having to find out which one it was and they remove easily and not even much stuff is needed (but like mentioned only for small games).

Squize did you have a look at the tile engine yet? Is it so bad?

Quote:

---

Originally Posted by nGFX

(sorry for quoting it again) so what do you think about OOP paterns, then?
i thought for a very tiny moment about the idea of using base-bullet class and inherit each bullet type from there. but then, when using a bullet manager, i used a simple object ( {x,y,dx,dy,mcTarget,...} ) to store the data needed (instead of "new BulletA()").

---

Well, what I do is have a 'dynamic', which allows properties to be added at runtime, so I have 1 controlling bullet class which controls all of my bullets, and then depending on the movetype(which I talked about earlier), the proper variables are created and set with a corresponding setup command to the move command selected.

Then, I have bullettype classes, which enables not different types of movement(which is controlled by the above class, as I said) but different actions of that bullets. So the bullet type class could be say normal bullet, which would just on impact take away the damage variable. But I could also have say emp, which would remove shields of all objects in the area, but that is all controlled by the emp class which extends the bullet class, which extends the world class.

Hope that makes sense. It works for me.

Quote:

---

Originally Posted by UnknownGuy

Then, I have bullettype classes, which enables not different types of movement(which is controlled by the above class, as I said) but different actions of that bullets. So the bullet type class could be say normal bullet, which would just on impact take away the damage variable. But I could also have say emp, which would remove shields of all objects in the area, but that is all controlled by the emp class which extends the bullet class, which extends the world class.

---

though, it is basically creating (extended) childs from the base class, only at runtime.

what i asked myself: do i need a class for every bullet (or extend the base class) OR can it be handled by the bullet manager?

i always try to find a "best practise" method for games (mainly because i'm lazy as hell and try to reuse as much as possible).

btw. anyone else with a different method?

nGFX

Im hoping there will be some code posted at the end, I cant figure out how to make a loop that dosnt start at 0 but at the lowest depth of my MC's :(. This is bullet related by the way.

Quote:

---

Originally Posted by nGFX

what i asked myself: do i need a class for every bullet (or extend the base class) OR can it be handled by the bullet manager?

---

It just comes down what you need to do and what you are trying to produce.

Quote:

---

Originally Posted by UnknownGuy

It just comes down what you need to do and what you are trying to produce.

---

:) thoutgh, it was more a rhetorical question. this is a question i ask at the start of the development process. my way to simplify the code design, a way to narrow down 10 different methods into one method with 4 params.

this is why i started this thread in the first place. to see how other people find their "best" way of doing one thing. (not to mention that i think that that is one of the problems new game devs have when they start. (i think the way most tuts show it is the "easiest" but not the best and this "easiest" way is one of the problems they face when things become more complex))

nGFX

It is a balance between usability and how open-ended it is.

And just about storing bullets in an array, I find objects much easier to use, I just love for in loops.

??? you know that "for ... in" works with arrays as well ???
... or did you just left out the part of the sentence that is responsible for the "oh, now i get what you want"?

nGFX

Quote:

---

Originally Posted by nGFX

??? you know that "for ... in" works with arrays as well ???
... or did you just left out the part of the sentence that is responsible for the "oh, now i get what you want"?

nGFX

---

I was never sure if it worked with arrays, but still, I find it easier to manage objects.

I don't understand your second sentence...

actually an object is an array which uses names for indexing

... it is usually called dictionary ...

nGFX

Quote:

---

Originally Posted by nGFX

actually an object is an array which uses names for indexing

---

Yes, indeed it is, but I would rather create a property then to use array commands, simpler IMHO.

Edit: I also believe objects are faster, though that doesn't always matter.

just out of interest, whats method e?

i think it depends on how many parameters you will have (number on screen at the same time, variation in style, direction, speed, deadly etc.) If theres gonna be alot of parameters, i would go with c, else f

must have missed e somehow :)

nGFX