LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

How to make enemy projectiles?

Root / Programming Questions / [.]

AInvesionerCreated:
I am making a space shooting game and I have no idea how to make enemy projectiles. I want enemies to shoot either 6 lasers 60 degrees apart from each other, or to shoot 3 lasers at the ship, with the coordinates x, y In case it helps, the enemies have the coordinates EX[I], EY[I], and ED[I] checks whether the enemy is alive or not. definition # for enemy laser is 15 Laser sprite # is 63 definition # for player is 2 definition # for enemies is (I+3)

So it appears you know how to make enemies. Why not consider enemy projectiles to be another type of enemy? One that has less intelligence than the 'real' enemies, so it should be even easier to code. Does thinking about it this way help you get started?

You should scrap the idea of lasers because collition box cannot be rotated. An option is to use the graphic function instead of sprites. However, graphic function are slower than sprites.

I was more or less thinking: Laser Type 1 LX[I] = LX[I]+1 LY[I]= LY[I]+1 Laser Type 2 LX[I] = LX[I]+0 LY[I]= LY[I]+1 Laser Type 3 LX[I] = LX[I]+1 LY[I]= LY[I]+0 Laser Type 4 LX[I] = LX[I]-1 LY[I]= LY[I]-1 Laser Type 5 LX[I] = LX[I]+0 LY[I]= LY[I]-1 Laser Type 6 LX[I] = LX[I]-1 LY[I]= LY[I]+0

haven't tested this, but i'm confident that collision corrects for SPROT if you set it up properly having it not do so would be a terrible design decision

haven't tested this, but i'm confident that collision corrects for SPROT if you set it up properly having it not do so would be a terrible design decision
It doesn't. The terrible design decision has been made. http://smilebasic.com/en/reference/#sprite Scroll down to SPCOL, you'll see it's possible to have it adjust to scale, but not rotation.

haven't tested this, but i'm confident that collision corrects for SPROT if you set it up properly having it not do so would be a terrible design decision
It doesn't. The terrible design decision has been made. http://smilebasic.com/en/reference/#sprite Scroll down to SPCOL, you'll see it's possible to have it adjust to scale, but not rotation.
pray for an update EDIT : actually, have we tested that it really doesn't or are we just assuming?

I made a clone of undertale bullet hell on smilebasic and working on an space roguelike so I know this issue. I tried to make a clock where the hands would damage the player but the collition box doesn't rotate when I use sprot Keys: nkk3dxt3 Y328xp41

You should scrap the idea of lasers because collition box cannot be rotated. An option is to use the graphic function instead of sprites. However, graphic function are slower than sprites.
Well, since graphics don't give any collision benefits anyway, you might as well just use a sprite without using its built-in collision. If you ask me the best solution would be to make a collision box only at the tip of the lazer, as a square, that way the "tail" can't hit but a direct hit can, and the box would be small enough so it roughly matches the graphic at any orientation.

I'll post the key so you can try and see what's wrong. Also, the sprites will look weird because I don't know how to publish sprite sheets. Its getting approved now.

You will have to take out the load grp part to make it work, maybe.

@AInvesioner Our website supports bbcode, which means that [i] will translate into the "italic" style. If you'd like to post code with [i], you can wrap in [icode] like so: This is my code: A[i]=B[i]+1 To make it work, you type: [icode]This is my code: A[i]=B[i]+1[/icode]

Did anyone find out what to do?

Here's a good guide on the "algorithm" you would need to come up with: http://blog.wolfire.com/2009/07/linear-algebra-for-game-developers-part-1/ :)

Success!