[RyanThunder]

Hey all! RyanThunder here.

Shooting in MegaZeux...we all know how it's done. Pin down the space bar and hit the direction you want it to go. Simple, right? Well, a bit too simple for my liking.

I was thinking about this the other day, and I was wondering if there was a way you could prevent this from happening. In fact, I was trying to think of a shooting system that would be similar to a Mega Man game.

With that said, here's how the Mega Man shooting system works:

-only 3-4 bullets on the screen at a time
-cannot pin down the shoot button to shoot multiple bullets
-in the later Mega Man games, if you do pin down the shoot button, you charge up for a bigger shot, and when you release it, the strength of your bigger shot is judged by how long you held the shoot button for.

I was contemplating on how one would get this to work in MegaZeux. I think it would be started by zapping and restoring "spacepressed" labels, but I'm not sure if a system like that would work in this case.

How would you guys go about doing a system like this?

[Dr Lancer-X]

All you'd have to do is replace the firing and projectile systems in Robotic, and use those instead. Easy to do, but maybe more work than you were thinking.

[RyanThunder]

Yea, I figured it would be kind of cumbersome. How would you go about changing those systems? In other words, what commands allow you to do that?

[Micah]

Here we go.

Lock the player's attack, so default bullets are like not used or anything. You might want to also turn off default messages.

lockplayer attack
set "bimesg" 0

Before I go any further, I want to explain how to place this robot on the board. Place the robot, a block on it's left side, then like 3 empty spaces, then a customblock or something. Like this (the # represents a space). You can add more spaces if you want more bullets on the board at one time. Say I want to be able to shoot 5 bullets. 5 Spaces. Simple stuff.

█☻###█

So then you want a main loop that detects whether the shoot key is being pressed. I prefer using something other than space to shoot, but I'll use space since you seem to want to use it. (Side note: Make sure you have some way of detecting which direction the player is facing, like a robot that detects arrow presses and sets variables accordingly.)

walk west
: "loop"
wait 1
if not spacepressed "loop"
if c?? customblock p?? EAST "loop"
duplicate self EAST
goto shoot&direction&

Now, making the bullets move. We'll say that the bullet is traveling east, and you happen to use 1 to say the bullet will go east. I like my bullets to move fast, so I'll have it move 2 spaces in one cycle, making sure I check both so I don't have bullets going through enemies or anything. Basically I tell the robot where the bullet starts, and move it while checking each space along the way for obstructions. If one is found, it goes to a "hit" label. It also makes sure it doesn't go outside the board limit. But instead of making sure by checking each cycle, we'll save some hassle by just limiting the bullet distance according to where it's shot from. You'll see what I mean.

: "shoot1"
set "local1" to "('playerx'+1)"
set "local2" to "playery"
set "local3" to "playerx"
loop start
write overlay c00 " " at "local1" "local2"
inc "local1" 1
if c?? customblock p?? at "local1" "local2" then "hit"
if c?? robot p?? at "local1" "local2" "hit"
inc "local1" 1
if c?? customblock p?? at "local1" "local2" then "hit"
if c?? robot p?? at "local1" "local2" "hit"
write overlay c0f "?" at "local1" "local2"
wait 1
loop for "('board_w'-'local3')"
die

Do that for all 4 directions, and of course you need a hit label.

: "hit"
send at "local1" "local2" "hit"
die

PM me or post here if you have any questions.

[T-Bone]

OR!

You could use sprites bullets and have them send a shot message each time it moves in its current direction.

[Elig]

Micah ftw. Micah totally owned this topic.

Edit; T-Bone, your new avatar is the best thing to ever happen on the internet.

This post has been edited by Elig: 05 September 2007 - 07:39 AM

[Micah]

Also, you said that you didn't want to be able to pin down the shoot button. If you want the player to have to release the shoot button before they can shoot again, just add a little piece of code that prevents the robot from going into the main loop unless space isn't pressed.

So, in this little snippet of code, we could add this.

walk west

: "releaseplz"
if spacepressed "releaseplz"

: "loop"
wait 1
if not spacepressed "loop"
if c?? customblock p?? EAST "loop"
duplicate self EAST
goto shoot&direction&

I decided against putting a wait 1 in there because well... I don't know how long the player would have to hold space before it started affecting performance, if it did at all.

If you want me to explain how to charge shots, just post here or something.

This post has been edited by Micah: 05 September 2007 - 03:57 PM

[RyanThunder]

Yes, please do explain the charge shots. You are nailing this topic left and right!

[Micah]

Ok, we can handle this one of two ways, for different effects. We can either have 2 types of shots, charged and uncharged (in which case you'd need to make a charged shoot label for each direction), or you could have a shitload of different shots without a new shot label.

Either way, you'll need to increase the charge as space is pressed, then detect when space is released. Then, if the charge reaches a certain point (we're using 200 here), we cap it and send it to a new label to idle until space is released.

walk west

set "charge" 0

: "releaseplz"
if spacepressed "releaseplz"

: "loop"
wait 1
if not spacepressed "loop"

: "charge"
inc "charge" 1
if "charge" > 199 "charged"
if spacepressed "charge"

if c?? customblock p?? EAST "loop"

duplicate self EAST
goto shoot&direction&

When the "charge" counter reaches it's max amount (in this case 200), it will go to a "charged" label, which is still detecting spacepressed. When space is released, it goes to the special shot labels for charged shots.

: "charged"
if spacepressed "charged"
goto "chargeshot&direction&"

Or, you could do the same thing, but instead of making new shot labels, you have the "charged" label send the robot to the same old shot labels, but we edit the "hit" label.

: "hit"
set "damage" "charge"
send at "local1" "local2" "hit"
die

And the robots who are hit can act according to the "damage" value (say, if it's over 150 they explode into a zillion pieces).

The first way is a little more tedious to do, but it's easier to add visual effects to. The second way is more dynamic, but all the shots will look the same.

This post has been edited by Micah: 05 September 2007 - 08:31 PM

[apage43]

btw
"playerfacedir"
built in counter that tells which way the player's facing. Since you seem not to know about it.

[Micah]

I know about playerfacedir, but I prefer using my own counters so I can have a little more control over them.

[RyanThunder]

So the only way to do this is with custom blocks, and not actual bullets?

[Micah]

The bullets aren't customblocks, they are overlay.

[CJA]

apage43, on Sep 5 2007, 08:04 PM, said:

btw
"playerfacedir"
built in counter that tells which way the player's facing. Since you seem not to know about it.

this post was an absolute JOY to read

[Dr Lancer-X]

Quote

So the only way to do this is with custom blocks, and not actual bullets?

Where did you get that idea?
Don't use customblocks, use either sprite or overlay. I don't recommend using one sprite for every bullet (although in this case it probably wouldn't matter, but if you've got player bullets as well as enemy bullets it may be a problem), but instead, use a sprite on the vlayer as a bullet display.

This is my preferred method: I like to have a general bullet control robot that controls all bullets, player and enemy alike. You can see an active example of this in Termination. Basically, each bullet is given a unique ID (you don't have to reuse old bullet IDs, although that would help save memory if you have many bullets!), and per-bullet information is stored about them, in a format such as this (these are counters, and replace the # with &bulletid& or whatever the relevant counter to represent the bullet id is in this instance)

b#xpos
b#ypos
b#xvelocity
b#yvelocity
b#type (eg. 1 for player bullets, 2 for enemy bullets)
b#damage
(any other per-bullet information that it would be useful to store, like the graphic to draw, the animation frame, status about a bullet smoke trail, whatever)
... etc.

I also like to have xpos and ypos being a higher resolution than the board itself. For example, if your resolution is a scaled by a factor of 8 on each axis, or something, a bullet at 5, 5 on the board might have an xpos and ypos of 40, or 43, or even 47. A bullet of 43,43 or 44,44 would be close to the centre of 5,5.

xvelocity and yvelocity are just numbers that you use to increment xpos and ypos for the bullet every cycle. For example, if yvelocity is -10 and xvelocity is 0, the bullet will be travelling north at 10 values per cycle. With the scaling resolution of 8 discussed before, the bullet will be travelling at approximately 1.2 chars per cycle. (at speed 4, this is 25 chars per second)

Another method for representing movement other than xvelocity and yvelocity (and I can't remember if I used this in Termination or not) is to store 'direction' and 'speed' values, in which the bullet has a direction (this could be given in degrees, such as 0? for east, 90? for south (vertically flipped polar coordinates, as appropriate for mzx), 180? for west and 270? for north, or something similarly appropriate) and a speed. Thus, a bullet with a direction of 270 and a speed of 10 should move at the same speed and in the same direction as the bullet discussed before with yvelocity of -10 and xvelocity of 0.

Now, here comes the tricky part. I like to store my bullets in a linked list. Essentially, I have a counter like:

b#next

This counter contains the bullet id of the 'next' bullet to be processed. Logically, it should not matter that much in what order the bullets are processed, as long as they all are. I also have a counter called 'firstBullet' or something, which contains the bullet id of the first bullet to be processed, and 'totalBullets' so I know how many there are. The 'last' bullet generally has a 'next' value of -1--this indicates that it is the end of the list of bullets.

The bullet control robot essentially has four tasks:

• Drawing the bullets on the screen
  
• Moving the bullets, and checking for when they hit something
  
• Creating new bullets. You could also make the things that shoot bullets perform this step, but this would involve duplicating a bit of code and could be pretty ugly.
  
• Deleting old bullets when they die

Initially, there won't be any bullets at all, so you'd set totalBullets to 0 and firstBullet to -1 (this is also the number used in b#next to indicate that the bullet is the last one in the list; not a coincidence). Now, each cycle you can just check totalBullets. If it's still zero, just keep looping, because nothing needs to be done yet. When there are bullets, clearly you need to move them and draw them etc.

It is up to you whether to have one bullet processing loop for both drawing, moving and deleting bullets, or instead to divide the tasks up into two or three loops. Depends what you prefer.

Adding bullets is fairly easy (much easier than deleting them!). Basically, what I like to do is add new bullets to the start of the linked list, because with our system this requires the least processing. First you need to assign a new bulletID. What I like to do is keep a counter like "nextBulletID". This will be 0 at the start when there are no bullets (so the first bullet created will have a bulletID of 0), and, after creating each bullet I increment nextBulletID by 1, so that the next bullet created will have a bulletID of 1, then 2, then 3 and so on. Basically, decide what the bulletID of the new bullet is, then 'create' the bullet by setting the counters as required. For example. if the player is shooting a bullet to the east, you might like to do something like:

set "b&bulletid&xpos" "('playerx' * 8 + 12)"
set "b&bulletid&ypos" "('playery' * 8 + 4)"
set "b&bulletid&xvelocity" 16
set "b&bulletid&yvelocity" 0
set "b&bulletid&type" 1
set "b&bulletid&damage" random 20 30

This is straightforward. Then, to make the new bullet point the head of the list, first make the new bullet's 'next' bullet the current first bullet in the list.

set "b&bulletid&next" "firstBullet"

As I said before, if you make firstBullet -1 when there are no bullets, this will conveniently make the first bullet you create have a 'next' value of -1, which is logical because that bullet is also the last bullet in the list.
You also want to increment the number of total bullets

inc "totalBullets" 1

Finally, make the new bullet the new first bullet, so that it will be processed when the bullet list is traversed.

set "firstBullet" "bulletID"

To draw the bullets, you simply have to go through the list of bullets and paint each one to the screen. Here, you have to choose whether to use overlay, a sprite layer or something else. I won't discuss the specifics of that choice, because it's entirely dependent on you and your game.

Looping through the bullets is a matter of traversing the linked list. For this, you have a counter, which could be something like 'currentBullet'. Set currentBullet to firstBullet (because naturally we want to process the first bullet.. first). Now, currentBullet points to the bullet we are interested in processing, so you can use the coordinates and other per-bullet counters to draw it and such:

write overlay c0f "?" "('b&currentBullet&xpos' / 8)" "('b&currentBullet&ypos' / 8)"

or whatever.
After you have finished processing this bullet, set "currentBullet" to "b&currentBullet&next" to process the next bullet in the list, and repeat, until currentBullet = -1. This will indicate that the end of the list has been reached, and you can stop processing bullets for this cycle. Example:

set "currentBullet" "firstBullet"
: "DrawBulletsLoop"
write overlay c0f "?" "('b&currentBullet&xpos' / 8)" "('b&currentBullet&ypos' / 8)"
set "currentBullet" "b&currentBullet&next"
if "currentBullet" != -1 "DrawBulletsLoop"

The process of moving bullets is also pretty straightforward, but has a possibly unexpected 'gotcha' which we will discuss in a moment. Again, it's just a matter of doing a list traversal. Each time you process a bullet, instead of drawing it, you move it. For example:

inc "b&currentBullet&xpos" "b&currentBullet&xvelocity"
inc "b&currentBullet&ypos" "b&currentBullet&yvelocity"
if c?? robot p?? "('b&currentBullet&xpos'/8)" "('b&currentBullet&ypos'/8)" "Bullet_hit_robot"
if c?? customblock p?? "('b&currentBullet&xpos'/8)" "('b&currentBullet&ypos'/8)" "Bullet_hit_wall"
if c?? custombreak p?? "('b&currentBullet&xpos'/8)" "('b&currentBullet&ypos'/8)" "Bullet_hit_breakable_wall"
... etc ...

On reaching any of those Bullet_hit_* labels, you would then perform the appropriate functionality (Bullet_hit_robot might involve destroying the bullet and sending "playershot" or something to the robot that the bullet hit, bullet_hit_breakable_wall might involve destroying the bullet and removing the wall, etc.)
Now, there are two issues to worry about. First of all, if the bullet travels at more than 1 char per cycle, you need to make sure it can't fly through single-char walls or enemies. This can be done by copying the x velocity and y velocity values to temporary counters, and only applying one char's worth of movement before performing another check. There are also other ways of doing this--experiment and go with whatever you prefer.

The other gotcha is destroying the bullets. This was also one of the primary tasks I mentioned before, and it can be complicated. You need to cleanly remove the bullet from the list. In a linked list, this involves making the previous bullet connect to the next bullet:

Before: ([?] = bullet, [X] = bullet that is being destroyed)
[?]-->[?]-->[?]-->[X]-->[?]-->[?]...
During:
[?]-->[?]-->[?]--.[X] .->[?]-->[?]...
                   ----
After:
[?]-->[?]-->[?]-->[?]-->[?]...

This means you need to know two things: the bullet that comes after the bullet being deleted (That's easy, it's the b#next value for the bullet) and the bullet that comes BEFORE the bullet being deleted (harder!). To find the bullet that comes before, you could do something like:

• Store a counter such as 'previousBullet' when traversing through the list: each time you change currentBullet to a new bullet ID, set previousBullet to the old value of currentBullet
  
• Have each bullet store the value of the previous bullet (b#previous, or something), effectively making it a doubly-linked list. I do _not_ recommend this, as it requires you to keep track of more stuff, and that can lead to mistakes
  
• Instead of deleting the bullet immediately, do something such as set "b#deleted" 1 so that you know the bullet has been deleted, and have a dedicated bullet removal loop. In this bullet removal loop, you can simply check each time if the NEXT bullet is being deleted. This method is complex, confusing and can lead to mistakes, but if you're sure of what you're doing it's easier to keep this technique fairly 'solid' when adding more stuff than the first or second technique. Have fun with constructs such as "b('b('bulletID')next')next" when using this method.

Bullet removal is generally tricky, but you can get it right without too much trouble if you can keep a clear head while coding. I personally favour the third approach, but you might consider the first or second to be more appropriate for your needs.

If you want to reuse bullet IDs, to keep memory usage down (Termination can end up using thousands of kilobytes just to store dead bullets after long enough, so I should have considered this) you want to keep track of removed bullets. One possible idea is adding the bullet ID to an MZX string each time an old bullet is removed. If you want to have more than 256 bullets at a time, you will need to use more than one string character per bullet. 2 characters (which would make the limit 65536) should be more than enough. You can just append old bullet IDs onto a '$deletedBullets' string to allow this. eg.

set "$deletedBullets.&$deletedBullets.length&" "('bulletID'a0xFF)"
set "$deletedBullets.&$deletedBullets.length&" "('bulletID'>>8a0xFF)"

(note that MZX's 'a' operator is just a binary and, so "a 0xFF" is like "% 256". MZX's >> operator is a right bitshift, so ">> 8" is like "/ 256". I hope this makes sense).

Now, when you add a new bullet, instead of just going to the "nextBulletID" counter (you should still keep this counter, though, because you'll need it for creating bullet IDs when there are none to reuse), you can just do a quick length check of $deletedBullets to make sure that there are bullets you can reuse. For example:

if "$deletedBullets.length" > 0 "ReuseBullet"

If there are, you just need to grab the bullet ID of one of the available bullets to reuse. Remember that bullets IDs are represented with two string characters, so allow for this. In this case, I'll use the last bullet in the string (the last two characters):

set "bulletID" "('$deletedBullets.('$deletedBullets.length'-2)'+('$deletedBullets.('$deletedBullets.length'-1)'<<8))"

The bullet must now be removed from the list. This is easy.

dec "$deletedBullets" 2

This was the reason I used the last bullet on the string, instead of the first. To delete the first bullet, a string offset method would be required, and the string offset command will never remove the last character of the string.

That is basically everything needed to create a basic bullet engine. If you can think of anything else, or you have any problems with this, feel free to ask.

[asgromo]

Lancer-X is pretty good at this stuff.

[Micah]

Lancer-X, on Sep 6 2007, 08:22 PM, said:

BLAH BLAH BLAH

Way to go and make things complicated...

[Dr Lancer-X]

Micah, on Sep 7 2007, 04:32 PM, said:

Lancer-X, on Sep 6 2007, 08:22 PM, said:

BLAH BLAH BLAH

Way to go and make things complicated...

lol butthurt

[Micah]

Lancer-X, on Sep 7 2007, 01:22 AM, said:

Micah, on Sep 7 2007, 04:32 PM, said:

Lancer-X, on Sep 6 2007, 08:22 PM, said:

BLAH BLAH BLAH

Way to go and make things complicated...

lol butthurt

I'm more than willing to bet you confused the fuck out of RyanThunder.

[RyanThunder]

Yea, pretty much. I'm very unfamiliar with sprites.

[CJA]

so?

who wins here?

I think it's pretty obvious.

Lancer gb2C.

[Dr Lancer-X]

RyanThunder, on Sep 8 2007, 04:44 AM, said:

Yea, pretty much. I'm very unfamiliar with sprites.

then use overlay!

[RyanThunder]

Isn't there a command line that checks if there are any bullets on the board?

If there is, I've figured out a way to do this without sprites, overlay, or custom blocks.

This post has been edited by RyanThunder: 07 September 2007 - 10:38 PM

[Dr Lancer-X]

if c?? bullet p?? "label"

[RyanThunder]

Ok, so let's say you give the player 3 ammo.

Couldn't you use that command to trigger a loop that'll keep checking the board for bullets, and when they're gone, it executes a command that gives the player his 3 ammo back?

This post has been edited by RyanThunder: 08 September 2007 - 02:25 AM

[Dr Lancer-X]

er.. i don't see why not. why not try it out instead of asking if it would work?

[RyanThunder]

Tried it out, but it didn't work. I'm sure I'm missing something:

set "ammo" to 4

: "loop"
if c?? Bullet p?? at ANYDIR then "loop2"
wait for 1
goto "loop"
end

: "loop2"
if not c?? Bullet p?? at ANYDIR then "restore"
wait for 1
goto "loop2"
end

: "restore"
set "ammo" to 4
wait for 1
goto "loop"
end

EDIT: Yea, I know what it is. The robot is only checking for bullets N, S, E, and W of itself and not the entire board. How do I make it check the entire board?

This post has been edited by RyanThunder: 08 September 2007 - 03:10 AM

[Dr Lancer-X]

if any c?? bullet p?? "label"

[RyanThunder]

Eureka! It works perfectly! All you would have to do is silence the "out of ammo" sound and "set 'bimesg' to 0"

Now all I have to figure out is implementing a charge shot into this thing...