SpiceWare's Blog

IMHO, there should be more options than just "Catch: Yes" and "Catch: No". If the ball hits the front of the shield, a yes/no is probably sufficient, but there are four different reasonable things that can happen if the ball hits the back of the shield:

1. Bounce backward, regardless of "catch"
   
2. Bounce backward unless button is held down, in which case catch and release forward
   
3. Bounce backward unless button is held down; in which case catch but release backward [give player control over which part of his shield to hit]
   
4. Allow ball to pass through back of shield
   

Warlords does #1 with catch disabled, or #2 with catch enabled. I would tend to think doing #1 or #3 with catch enabled would be better.

Warlords does #1 with catch disabled, or #2 with catch enabled. I would tend to think doing #1 or #3 with catch enabled would be better.

Do you mean 2600 Warlords or the coin-op?

 

In any case, I'd go with the coin-op behavior.

That's a good point. I'd test it in MacMAME, but it has issues with Warlords that make it run extremely slow with sporadic speedups.

Is it a Mac-specific issue, or something that affects all MAME versions? Have you posted a bug report on the MacMAME Wiki?

In any case, I'd go with the coin-op behavior.

 

Who cares what the coin op does? Go with what's fun.

 

I don't particularly like the 2600 Warlords because catch mode makes it too easy for people to last forever (just hold the fire button down and you don't have to worry about trapping the ball behind the shield); no-catch mode alleviates that problem, but gives players far too little influence over the game.

 

So regardless of what the 2600 or arcade do, do something fun.

The catch mode wouldn't have that problem in multi-ball play though, unless three people decided to just hoard the balls and pick on the fourth guy. You could make it so only one or two balls could be caught simultaneously. And/or you could have a catch mode where if you're hanging onto one ball, the others pass right through your shield.

The catch mode wouldn't have that problem in multi-ball play though, unless three people decided to just hoard the balls and pick on the fourth guy.

 

The problem with catch mode (at least on the 2600) is that even if you don't use it to "aim" your attacks, it provides easy protection against getting a ball trapped behind your shield. What might be best would be to allow the "catch" mode to be set on a per-player basis as a form of handicapping. The weaker players could be permitted to do "backhanded" catches, middle-strength players would have the ball pass through from the back but not be able to catch it, and strong players would have the ball bounce off the back with no ability to catch it.

Is it a Mac-specific issue, or something that affects all MAME versions? Have you posted a bug report on the MacMAME Wiki?

 

I found that the game would run OK by holding down SHIFT. Weird. I don't know if it's MacMAME only. I just posted in the EBB forum MacMame forum to see if anybody else has seen the problem.

 

In any case, I'd go with the coin-op behavior.

 

Who cares what the coin op does? Go with what's fun.

 

I don't particularly like the 2600 Warlords because catch mode makes it too easy for people to last forever (just hold the fire button down and you don't have to worry about trapping the ball behind the shield); no-catch mode alleviates that problem, but gives players far too little influence over the game.

 

So regardless of what the 2600 or arcade do, do something fun.

 

The Arcade allows the "backhanded catch". However - and this is a biggy - for as long as you hold the fireball you lose chunks of your own castle's walls. I do plan to emulate that behavior, which I think would address your concern.

Yes, the players and the whole title screen look great. I am the expert on players, by the way.

 

The catch mode wouldn't have that problem in multi-ball play though, unless three people decided to just hoard the balls and pick on the fourth guy. You could make it so only one or two balls could be caught simultaneously. And/or you could have a catch mode where if you're hanging onto one ball, the others pass right through your shield.

 

The ideal solution is in the arcade version. You can hold a fireball but it will eat away at your castle walls if you for more than 5 seconds or so. I should check the time on Castle Crisis, since it is pretty much the arcade game.

 

I do like the idea of having a lot of variations though.

Yes, the players and the whole title screen look great.

Thanx! The way I'm flagging each shield as computer/human allows me to allow you select which corner you'll play (as a single player). I could actually do the same for 2 or 3 players, but that gets pretty messy. I'm pretty sure I can redirect Paddle 1 to the solo human player as well, main thing being processing time as I'll be updating 3 fireballs in the same section of code that Warlords updated 1. The flickering fireballs could get removed for the same reason.

I am the expert on players, by the way.

I figured you were, Big. I can call you Big, can't I?

I do like the idea of having a lot of variations though.

We'll see. I've not figured out a way to reliably tell if it's a "backhanded catch". Plus I'm down to 6 bytes of RAM and I've not added the shields, dragon or sound effects yet so some rethinking of routines is in order. The shields should be easy though as 3 bytes of each player's wall isn't used so I can use 2 of those for each player for their shield's sprite shape pointer.

Just thought of a potential issue - I was planning to turn the dead players black like in Warlords so their king's wouldn't show. However this would cause a fireball to become invisible on that third of the screen(in the middle third the fireball would pick up the dragon's color).

 

I currently have 2 castle kernels - one for top and one for bottom. I could I expand that to 8 by including kernel variations for both living, left dead, right dead and both dead conditions. I don't like this idea to much as it'll take a lot of ROM and could make debugging difficult.

 

Another option is to fast flicker the fireballs. If the player left/right from you is dead then the fireball will be visibile 2/3rds of the time. If 2 players left/right are dead then the fireball would be visibile 1/3 of the time on their third of the screen, but since it's not a direct threat to the remaining players it's probably acceptable.

 

Another thing I could do is make the dead player's color dark grey and stop drawing their shield... Combining this with the fast flicker might work OK.

Is it a Mac-specific issue, or something that affects all MAME versions? Have you posted a bug report on the MacMAME Wiki?

I figured out that it's related to my bluetooth keyboard. I turned it off and plugged in a USB keyboard and it worked just fine.

We'll see. I've not figured out a way to reliably tell if it's a "backhanded catch".

 

If you keep track of ball direction as an angle 0-31, with 0 being the positive y direction and 8 being the positive x direction, and if you have an angle for the paddle (0 facing outward in the positive y direction and 8 facing outward in the positive x direction), then the new angle can be computed as 16 minus the ball angle plus twice the shield angle.

 

To distinguish a backhanded catch from a proper one, add 8 to the old or new ball angle, subtract the shield angle, and mask the result with 31. If the result is exactly 0 or 16, the ball hit the edge of the paddle. If the result is 0 to 15, the result is a back hit. If 17 to 31, the result is a front hit.

 

BTW, suggested option: lock the position (but not angle) of the shield when the button is held down. This would allow players who could position themselves in front of an imcoming ball the ability to control where it would go after impact.

Thanx for the info.

 

Hmm - so instead of catching the ball then moving before release, you'd catch the ball then rotate before releasing?

Hmm - so instead of catching the ball then moving before release, you'd catch the ball then rotate before releasing?

 

If that option was enabled, probably. Though other arrangements might be reasonable as well. For example, hold button before catch=set angle; once ball is caught, lock angle but control position. Or alternatively have the "catch" last for a fixed amount of time during which the player may move the shield as desired; the button would control the locking of the shield position, rather than the release of the ball. Many possible ways to do things.

 

Another thing that might be interesting would be to allow each player a small amount of Odyssey-style "ENGLISH" (maybe a 45 degree range) between the time the ball his their shield and the time it hits something else.

I'm surprised that while loading the graphics addresses into RAM, you are not able to set up a subroutine. You have a separate routine written for SpeedGraphic, FireballGraphic, CatchGraphic, etc even though they are nearly identical other than the starting address. I'm about to do the same thing so I was curious if there was a way to call a subroutine.