Pages: 1
Hello, I am working on a shooter with RPG Maker 2003, and the ABS system I have currently is set up to where if the hero is lined up with the enemy and you fire, it takes damage. I am trying to get it to where a separate character set IE: bullet sprite to teleport to the hero's location when the shoot button is pressed. I have that part and it does what it's supposed to do, however, I can't figure out the coordinates so the bullet hurts the enemy. does this make sense?
I think I got it to work. I have it so if the bullet is equal to enemie's X and Y then it hurts it. Seems to work so far.
Some things to keep in mind:

For your bullet sprites, are you using below hero, same level as hero, or above hero? If you want to have low cover that you can shoot over, but enemies can't pass, you could use above or below for the bullets, and put the cover in with Same Level as Hero.

If enemies can fire projectiles back, will they be on the same layer (above, below, same) as the player bullets or a different one? Will the player be able to shoot enemy projectiles out of the air/will enemy and player projectiles stall if they run into each other?

How many duplicates will you have for the bullet event? In larger maps, the bullet may not have traveled its full distance before the player fires again. I usually end up with a total of eight possible player bullets at a given time, and cycle them as needed on creation. This comes in handy if you're going for weapons with a high rate of fire later.
RPG Maker 2k/2k3 for life, baby!!
In my shooter for rmk2003 the bullets are "below hero" and are placed in the corner of the map where the player can't see them. Then I have a "parallel process" that checks each enemy, hero and bullets "X coordinate" and "Y coordinate".

When the hero fires (I use the cancel key) the "parallel process" I made for it sets the bullet in the same coordinates the hero has and check which direction the hero is facing, and depending on the direction it uses "move event" with repeat pattern.

Then another "parallel process" checks if the coordinates of the bullet and the enemies are the same, if they are then damage is inflicted (use variables for enemy life).

But it seems you made it in another way, maybe you can use the part I said about the bullet facing the same direction of the hero.

Depending on the rate of fire you may have to make several bullets and alternate between them. In my game I only need 2.
From past experience with abs shooting projects, I came up with this solution:

I handle the input and any animation control for the main character in a common event. I also do the placement and activation of the bullets via a common event that turns on the switch for each individual bullet as called for.

This lets me use my shooting system on multiple maps. The only events I have to copy over are my player bullets.

In my experiments, as long as you have the bullets set to update their x and y in parallel as they move, you can handle your collision detection in a separate event. That way you have the entire system running with a total of two non-projectile parallel events, which you can separate with a 0.0 wait command.

In the past I used hit detectors in each bullet's parallel routine, but with a lot on screen, they tended to cause slowdown or bottle necking. With the single hit check event, you can still handle multiple targets. I can handle ten flawlessly. Fifteen and twenty are doable, but you will start to get some delay due to the computation.

I set up a test event that fired 1000 bullets at a series of targets and tested for hits. With fifteen targets active, accuracy fell from 100% to 97%. At twenty active targets, accuracy fell again to around 92/93%. I was down below 89% with twenty five targets, and the system seems to get downright glitchy with 30+.

Theoretically, you could duplicate the system and stagger it in multiple parallel events with 0.0 waits to handle as many possible targets as you want in groups of ten, but I'm not sure it is worth it to push it. Ten enemies within range at a time should be enough.

You could add in duplicate "dead body" versions for the enemies that get placed by an event every time an active enemy is "killed." That way you get the illusion of dropping the target and having a "new" enemy spawn. You can fade the old corpses out over time, reducing the total number of redundant dead body sprites you'll need.

Between player and enemy projectiles, as well as decals and dead body stand ins, you might end up with a good portion of your screen covered in events. I use an event at the start of the map to move all of these to 0,0 or some location the player can't see/step on, and I make sure to return any projectile that finishes its track to those coordinates to keep them from causing accidental hits when an enemy walks over the position the stopped at.
Pages: 1