Converting button input signals into shots on screen

[BER]

Let's suppose you control a character that shoots stuff. I am curious about how a programmer determines whether the character shoots a projectile based upon the button signals that the player sends. The following message made me curious about this:

http://click-stick.com/bbs/viewtopic.php?p=3085#3085

Let's denote 1 as the C button being on for one frame and 0 as off. For Mushihime, the guest poster "ram" claims the following:

• From the C button, two on frames, not necessarily consecutive, trigger a shot from the character Reko.
• The following button input sequence makes Reko fire one shot: 100100...
• The following sequence makes Reko fire three shots: 111000111000...

It's too cumbersome for me to propose an algorithm for this firing behavior. So for each sequence, I'll simply place a caret below the frame in which I think the game triggers a shot. For the first sequence, we have

Code: Select all

100100100100100100...
   ^     ^     ^

In other words, the interval between shots is five frames. And for the second, we have

Code: Select all

111000111000111000111000111000111000...
 ^    ^ ^    ^    ^ ^    ^    ^ ^

In other words, the interval between shots cycles in this order: four frames (the minimum to make the Reko-counter turn red), four frames, and one frame (which keeps the Reko-counter white).

First, is this one possible way to convert button signals into shots on screen? If not, why do you think Mushihime exhibits the firing behavior as listed above?

[raiden]

I´ve thought about this before when I read your thread in the hardware section. It´s a strange phenomenon, and I´m not sure whether I really understood the way this works in Mushihime, but it could have been designed as a method against abusing autofire originally. The algorithm seems to "collect" button signals and only starts a shot for every 2 signals accumulated, but limited to a maximum frequency/minimum time interval between shots. The idea behind this, I assume, is to reward tapping the button in a certain rhythmical way, which is already present in some form in Dodonpachi, where you need to do just that to keep the chain alive at some points.
On the other hand, it could be intentional in a way of "encoding" more than 3 kinds of weapon usage within the 3 buttons of Jamma standard. Just like earlier Cave games did with button A as a double function button for those cabs with only 2 buttons. This implies they were aware of sophisticated autofire circuits installed in several cabs and just "hid" the feature for players to find out by experimenting with autofire.
Regarding your circuit-building project, if it is with the PS2 version in mind, I´d maybe wait until it gets released, to find out if those functions are already selectable.
Now, is this even the direction your question was intended, or did I totally miss the point?

[BER]

raiden, I think you've answered the question, but I still feel unsatisfied. Now I'm left wondering whether the two examples I gave are indeed correct for Mushihime.

Ultimately, I wanted to be sure about why the ideal signal sequence for the C button in Mushihime is this if we're firing at point-blank range:

Code: Select all

110001100011000...
 ^    ^    ^ 

If we input this signal and the game indeed makes Reko fire at the frames indicated by the carets, then this would allow us to "bank" about twelve times a second. In the examples given in this thread's first post, we could only bank about ten times a second. But I couldn't accept assuming that Reko fires exactly as indicated above. So I was really wondering how Cave implemented Reko's logic for firing bullets based on the player's button inputs.

Maybe I'm just scatterbrained. :)

[raiden]

ok, I´ll try another perspective: the game logic is capable of creating player shots as independent objects that behave in a certain way (generally, move up until hitting enemies or leaving the screen) no matter what the player does after firing them. As shots shouldn´t move much faster than about 20 pixels upward per frame (because they´d be too fast to see them properly, and also they would be horizontally tied too tightly to the ship), a game engine that wants detailed shots bigger than 20 pixels in vertical direction will not create new shots every frame.

One simple way to go about it is like this: each frame, the engine decreases a variable by 1 and checks whether it´s below 0. If yes, it fires a shot and resets the value to 3, for example. That way, the player can fire 15 shots per second. Now, you can combine this procedure with a check whether the player has let go of the shot button since the last shot was fired, and in that way you will require the player to tap the button instead of just holding it down. An additional effect will be that the player will usually not achieve 15 shots per second, except when he uses an autofire circuit cutting off the signal every 2nd, 3rd or 4th frame.

What Cave did in Mushihime is obviously more complicated, and I don´t think I can write it down in a similar way until I played the game to see how it works in detail. I´ve read the descriptions on click-stick.com, and I´ve seen the videos, but I can still hardly imagine the way it works precisely.