Shoot and Jump

[jrok]

I recall we had some conversations before about using the fire button to shoot versus using it to jump. The problem is that some game designs call for a lot of shooting and jumping. I agree with the general consensus that using "fire button to shoot/ press the joystick up to jump" is just counter intuitive and feels unnatural, so I started working on a way to use the fire button for both actions.

 

In this little demo, the controls are as follows:

 

Jog: Joystick left or Joystick right

 

Sprint: Joystick up-left or Joystick up-right.

 

Duck: Joystick down, Joystick down-left or Joystick down-right.

 

Shoot: Fire button and...

• no Joystick
  
• Joystick down
  
• Joystick left
  
• Joystick right

Jump: Fire button and...

• Joystick up
  
• Joystick up-left
  
• Joystick up-right

Roll: Fire button and...

• Joystick down-left
  
• Joystick down-right

 

So basically the idea is that whenever the up-switch is detected on the joystick, you are in "jumping mode," and when it's not detected you are in "shooting mode." So, you can also shoot in mid-air as long as you aren't pressing one of the "up" directions (up, up-left or up-right).

 

I think that the demo I threw together could potentially be Pitfall-esque gameplay... except of course that you can blast stuff!

 

If any of you guys get a chance to play around with it, I'd like some feedback on how comfortable this control setup is. It would be especially great if someone with an Atari joystick (either USB or real hardware) can let me know if it feels natural.

 

Thanks,

J

 

 

Latest version:

Note: See latest post in this thread for list of changes.

shootandjump5.bas.bin

 

Older versions:

shootandjump4.bas.bin

shootandjump3.bas.bin

shootandjump2.bas.bin

shootandjump1.bas.bin

Edited December 30, 2010 by jrok

[Piggles]

I recall we had some conversations before about using the fire button to shoot versus using it to jump. The problem is that some game designs call for a lot of shooting and jumping. I agree with the general consensus that using "fire button to shoot/ press the joystick up to jump" is just counter intuitive and feels unnatural, so I started working on a way to use the fire button for both actions.

 

In this little demo, the controls are as follows:

 

Run: Joystick left, Joystick right, Joystick up-left or Joystick up-right.

Duck: Joystick down.

Shoot: Fire + no Joystick, Joystick down, Joystick left or Joystick right

Jump: Fire + Joystick up, up-left or up-right

 

So basically the idea is that whenever the up-switch is detected on the joystick, you are in "jumping mode," and when it's not detected you are in "shooting mode." So, you can also shoot in mid-air as long as you aren't pressing one of the "up" directions (up, up-left or up-right).

 

I think that the demo I threw together could potentially be Pitfall-esque gameplay... except of course that you can blast stuff!

 

If any of you guys get a chance to play around with it, I'd like some feedback on how comfortable this control setup is. It would be especially great if someone with an Atari joystick (either USB or real hardware) can let me know if it feels natural.

 

Thanks,

J

 

I find it to be comfortable. But take that with a grain of salt, as I don't mind pressing up to jump so long as it doesn't screw up my access to ladders or doors that require me to press Up. I used the keyboard. The physics of jumping and coming down are of professional quality as well.

[+Random Terrain]

Since it seems you have to stand still to fire, how about this:

 

Jump: Fire + Joystick up, up-left, up-right, left, or right

 

 

That would be more intuitive to me.

[jrok]

Since it seems you have to stand still to fire, how about this:

 

Jump: Fire + Joystick up, up-left, up-right, left, or right

 

 

That would be more intuitive to me.

 

Hmm, maybe. Or maybe it would be better to just let the player shoot while running. The only problem I see with fire + left/right to jump is that in the middle of a fight, you might jump when meaning to shoot. I'd prefer not to die from lack of shooting back.

Edited December 26, 2010 by jrok

[+Philsan]

Very nice demo game!

 

I am sorry but for me "fire button to shoot/ press the joystick up to jump is just counter intuitive and feels unnatural".

Perhaps I have to get used to your new control system...

[+Random Terrain]

I'd prefer not to die from lack of shooting back.

If enough people are using USB controllers with joypad, keyboard arrow keys, or Sega Genesis controllers more often than joysticks, they'll be dying from lack of jumping (if you are going to have enemies or object for them to jump over). It's really hard for me to jump using my USB controller, except for jumping straight up. You could try adding left/right as a test and see how you like it.

[jrok]

Here is a version with the same controls, but that allows the player to shoot while running.

 

shootandjump2.bas.bin

Edited December 26, 2010 by jrok

[jrok]

Very nice demo game!

 

I am sorry but for me "fire button to shoot/ press the joystick up to jump is just counter intuitive and feels unnatural".

Perhaps I have to get used to your new control system...

 

That's the point of the demo, though. Pressing up doesn't jump unless you also press the fire button.

Edited December 26, 2010 by jrok

[jrok]

Here is a version with the following changes:

 

1) Shoot while Running: Fire + Joystick left or Joystick right.

2) Hi-Speed Sprint: Joystick up-left or Joystick up-right

 

So the idea here is that the up diagonals give you a boost of speed while you're running towards your jump-goal. The thing I like about it is that it marks an obvious on-screen change between shooting and jumping modes, and that this change actually helps achieve the players goal (jumping over an enemy or across a gap) by giving his jump more horizontal momentum.

 

shootandjump3.bas.bin

Edited December 27, 2010 by jrok

[Piggles]

Here is a version with the following changes:

 

1) Shoot while Running: Fire + Joystick left or Joystick right.

2) Hi-Speed Sprint: Joystick up-left or Joystick up-righ.t

 

So the idea here is that the up diagonals give you a boost of speed while your running towards your jump-goal. The thing I like about it is that it marks an obvious on-screen change between shooting and jumping modes, and that this change actually helps achieve the players goal (jumping over an enemy or across a gap) by giving his jump more horizontal momentum.

 

shootandjump3.bas.bin

 

That's my favorite. I can kick some alien butt with those controls.

[jrok]

Okay here is a updated version of the demo. I revised the controls as follows:

 

Jog: Joystick left or Joystick right

 

Sprint: Joystick up-left or Joystick up-right.

 

Duck: Joystick down, Joystick down-left or Joystick down-right.

 

Shoot: Fire button and...

• no Joystick
  
• Joystick down
  
• Joystick left
  
• Joystick right

Jump: Fire button and...

• Joystick up
  
• Joystick up-left
  
• Joystick up-right

Roll: Fire button and...

• Joystick down-left
  
• Joystick down-right

 

New demo screen: I did away with the 2-color "big sprite" and am using a single P1 to draw the player graphics now. I also revised the screen layout to fit in three platforms instead of two, and created a series of jumps of various difficulty (the top platform containing the most difficult jump; it is possible to make it, but you have to jump at the last possible second).

 

shootandjump4.bas.bin

Edited December 27, 2010 by jrok

[KevinMos3]

These are all nice. I've never been one who minded pressing up to jump, but these are a nice alternative.

 

The problem I had with the first demo was the inability to shoot while running.

 

I think the 2nd demo is my favorite.

 

While I like the idea of being able to sprint while running, it seems that when I go to jump a hole when running at normal pace, I may mess up because of the sprint which I'm forced to do. Precise jumping is difficult because of this. I do like the added ability to roll.

[jrok]

These are all nice. I've never been one who minded pressing up to jump, but these are a nice alternative.

 

The problem I had with the first demo was the inability to shoot while running.

 

I think the 2nd demo is my favorite.

 

While I like the idea of being able to sprint while running, it seems that when I go to jump a hole when running at normal pace, I may mess up because of the sprint which I'm forced to do. Precise jumping is difficult because of this. I do like the added ability to roll.

 

Thanks, Kevin!

 

The idea in the latest version is that you can't leap forward while running at a normal pace (although, you can jump straight up by just pressing up and pressing the fire button). The closest I can think of to these controls is Out of This World/ Another World.

[Piggles]

These are all nice. I've never been one who minded pressing up to jump, but these are a nice alternative.

 

The problem I had with the first demo was the inability to shoot while running.

 

I think the 2nd demo is my favorite.

 

While I like the idea of being able to sprint while running, it seems that when I go to jump a hole when running at normal pace, I may mess up because of the sprint which I'm forced to do. Precise jumping is difficult because of this. I do like the added ability to roll.

 

I like the engine very much. With careful level design, I think the timing of jumps won't be so frustrating. And I like how you fit 3 floors. You can put a lot of gameplay into 3 floors per screen.

[jrok]

I like the engine very much. With careful level design, I think the timing of jumps won't be so frustrating. And I like how you fit 3 floors. You can put a lot of gameplay into 3 floors per screen.

 

Thanks, Piggles.

 

What would be really cool is if we could run multiple batari display kernels. With one kernel running the display for each third of the screen, each floor could contain two flicker-free sprites (or 4 30hz ones). I think a fairly cool action-adventure game could be accomplished in such a framework.

Edited December 28, 2010 by jrok

[Piggles]

I like the engine very much. With careful level design, I think the timing of jumps won't be so frustrating. And I like how you fit 3 floors. You can put a lot of gameplay into 3 floors per screen.

 

Thanks, Piggles.

 

What would be really cool is if we could run multiple batari display kernels. With one kernel running the display for each third of the screen, each floor could contain two flicker-free sprites (or 4 30hz ones). I think a fairly cool action-adventure game could be accomplished in such a framework.

 

What might fit with the limitations of the Bb engine is a game with hidden enemies. Your line of sight restricted to the floor of the building that you're on. Combined with a theme of stealth, perhaps the bland lack of graphical data on the other floors wouldn't be a problem. Your enemy and terrain data could be handled via software until it's time to fall through a hole or climb down a ladder to the next floor. Using "pfcolors background" perhaps you could just blackout the levels of the screen you're not currently on, bringing focus to the current floor with whatever colors are appropriate for the situation.

 

And all this is easy for me to say because it's not my project.

Edited December 29, 2010 by Piggles

[jrok]

I like the engine very much. With careful level design, I think the timing of jumps won't be so frustrating. And I like how you fit 3 floors. You can put a lot of gameplay into 3 floors per screen.

 

Thanks, Piggles.

 

What would be really cool is if we could run multiple batari display kernels. With one kernel running the display for each third of the screen, each floor could contain two flicker-free sprites (or 4 30hz ones). I think a fairly cool action-adventure game could be accomplished in such a framework.

 

What might fit with the limitations of the Bb engine is a game with hidden enemies. Your line of sight restricted to the floor of the building that you're on. Combined with a theme of stealth, perhaps the bland lack of graphical data on the other floors wouldn't be a problem. Your enemy and terrain data could be handled via software until it's time to fall through a hole or climb down a ladder to the next floor. Using "pfcolors background" perhaps you could just blackout the levels of the screen you're not currently on, bringing focus to the current floor with whatever colors are appropriate for the situation.

 

And all this is easy for me to say because it's not my project.

 

No, these are all good ideas. It's funny - I was actually thinking of something similar, including the "blackout" of non-visible levels, which would actually add an interesting "Wizard of Wor" wrinkle to gameplay that I haven't seen in games of this type (not saying those games don't exist, it's just that I haven't seen one.)

[jrok]

Latest Version:

 

• Added 7 horizontal rooms. Player enters next room at screen edges.
  
• Added a playfield enemy, "Field Mouse" that roves back and forth along the floor of each deck and emits a vertical laser field at timed intervals. Up to two per screen for now, but I will try to include as many as four
  
• Added a p0 enemy, "Robot," that appears on a random deck when the screen is drawn. By default it roves back and forth across the deck, but it moves in the direction of the player whenever they share the same deck.

 

This is basically still a sandbox without any death or danger, and I just scattered around the pits without much thought to design, but I'm starting to get interested in the possibilities here. I'm using CurtisP's background colors hack to achieve a multicolored static background behind multicolored playfield pixels, but now I'm wondering if I should try to store the background rows, playfield colors and heights in the superchip RAM.

 

Also, if I go with 30hz flicker on P0 and P1, I could potentially have quite a lot going on in each screen so I might try something like that for the next version.

 

shootandjump5.bas.bin

Edited December 30, 2010 by jrok

[Brian O]

This is great so far. I like your character animations.

 

Perhaps you can have multiple levels, each one like a multi-level obstacle course. Start on one end and try to get to the other. Once you reach the end, you progress to a harder level, and so on.

 

You might also add a timer that counts down or up, and gives you a bonus at the end based on how much time is left. If it counts down, it may add a certain level of tension as you play, forcing the user to choose speed over carefulness. You may also add powerups that you could pick up that add or take away time.

 

Just my two cents.

 

-B