Jump to content
IGNORED

Jumper - Final Version Complete


Atarius Maximus

Recommended Posts

I have another update for today. No changes to the title song, but I added 'dynamic' playfields to Levels 2,4,6,8 & 10. Warning: some platforms may change during play. :evil: Kind of adds a new twist to those levels. It's a pretty cool addition, but now I'm down to 3 bytes free out of 8k.

 

There were also a few more bugfixes in this version, and I tweaked some things on a few other levels.

 

Steve

I'd go 16k if necessary.

 

The game's looking good, but I think it's a little too easy. The bullets aren't particularly threatening and this is the only way to die. In Jumpman, the bullets move slow like this normally, but "shoot" by speeding toward the player if his X or Y coordinate matches (or is close). Also, I'd make it lethal to fall further than a certain height.

 

EDIT: just noticed a bug - if you press the button in a fall, you can jump in mid-air.

Edited by batari
Link to comment
Share on other sites

I have another update for today. No changes to the title song, but I added 'dynamic' playfields to Levels 2,4,6,8 & 10. Warning: some platforms may change during play. :evil: Kind of adds a new twist to those levels. It's a pretty cool addition, but now I'm down to 3 bytes free out of 8k.

 

There were also a few more bugfixes in this version, and I tweaked some things on a few other levels.

 

Steve

I'd go 16k if necessary.

 

The game's looking good, but I think it's a little too easy. The bullets aren't particularly threatening and this is the only way to die. In Jumpman, the bullets move slow like this normally, but "shoot" by speeding toward the player if his X or Y coordinate matches (or is close). Also, I'd make it lethal to fall further than a certain height.

 

EDIT: just noticed a bug - if you press the button in a fall, you can jump in mid-air.

 

Thanks for the suggestions. I agree it's a little bit easy, I was already thinking about some of those things you mentioned as possibilities - but I had wasted all my space on cramming 12 levels into the game. :) Can you give me a suggestion on how to fix the problem that mojofltr mentioned? I'm having a hard time figuring out a way to make the player jump only when the button is pressed and released, and not continuosly jump when it's held down. I'm probably missing something obvious.

 

Can i just put a 'set romsize 16k' at the beginning of the code? if it's that simple, then I'll definitely go up to 16k to add more features.

 

I'll take a look at that bug you mentioned.

 

Thanks!

 

Steve

Link to comment
Share on other sites

One way would be to use a variable as a flag, so that its set to on when the player jumps and dosnt go off again until the player has collided with the playfield. ex:

 

loop

player0y=y

If joy0fire && jump=0 then jump=5

if jump=5 then goto jumproutine

goto loop

 

jumproutine

jumpy = jumpy + 1

if jumpy < 11 then y = y - 1

if jumpy > 10 then y = y + 1

if jumpy > 5 && collision(player0, playfield) then jumpy=0 : jump=0

goto loop

 

 

EDIT:

also, to limit how often they can jump, you can use the variable as a counter:

 

If joy0fire && jump < 5 then jump = jump + 1

 

This will keep the sprite from zipping up and down like a musquito :P

Edited by MausBoy
Link to comment
Share on other sites

One way would be to use a variable as a flag, so that its set to on when the player jumps and dosnt go off again until the player has collided with the playfield. ex:

 

loop

player0y=y

If joy0fire && jump=0 then jump=5

if jump=5 then goto jumproutine

goto loop

 

jumproutine

jumpy = jumpy + 1

if jumpy < 11 then y = y - 1

if jumpy > 10 then y = y + 1

if jumpy > 5 && collision(player0, playfield) then jumpy=0 : jump=0

goto loop

 

 

EDIT:

also, to limit how often they can jump, you can use the variable as a counter:

 

If joy0fire && jump < 5 then jump = jump + 1

 

This will keep the sprite from zipping up and down like a musquito :P

 

Thanks for the suggestion, MausBoy. I tried to implement something similar, but the jump code I'm using just isn't much like your example, and I couldn't make it work. I came up with an alternative, but it causes other problems. The the player is now forced to press and release the button to jump, which fixes the 'mosquito' problem. I also made a few color changes (the darker colored levels made it very hard to see the ball), and level 11 was changed.

 

The new jump code causes two other known issues. If you fall, you can press and hold the fire button and hang in midair. The problem is how to apply gravity - I need to keep track of whether or not the player is in the middle of a jump. If so, I don't want gravity to pull him down. I haven't found a good way to do that yet.

 

Also, If you hold down the fire button and run to the edge of a platform, you won't fall -- you'll hang on the edge and jump when you release the button. It's the same problem with when exactly to apply gravity. So...fix a few bugs, create a few more. :(

 

I've spent hours and hours trying to perfect the jumping, and I'm having a hard time with it. I think need to take a break from this for a day or two. Attached is the latest revision.

 

Steve

jumper8k_6.txt

jumper8k_6.bin

Link to comment
Share on other sites

Hmm, maybe I should shut up, but the version before was much more playable - mosquito or not.

 

I've spent hours and hours trying to perfect the jumping, and I'm having a hard time with it. I think need to take a break from this for a day or two. Attached is the latest revision.

 

Have a good break. I appreciate how much work goes into building a game. Your game shows a LOT of promise. :)

Edited by mojofltr
Link to comment
Share on other sites

Hmm, maybe I should shut up, but the version before was much more playable - mosquito or not.

Yeah, you're right. I just wanted to show my progress on the jump code. Attached is another version with all the changes to date, minus the change that affects jumping. As long as you don't hold the fire button down, the jumping is exactly how I want it. ;)

 

Have a good break. I appreciate how much work goes into building a game. Your game shows a LOT of promise. :)

Thanks! I'm glad you think it looks promising....and it is a LOT of work! :)

 

Steve

jumper8k_7.txt

jumper8k_7.bin

Link to comment
Share on other sites

Besides saying your game shows promise, I should have said that it is already a lot of fun to play - even with the glitches. :)

 

I always get more excited in the latter stages of a game's development when a game author is polishing up the little bits.

 

Congratulations! There are a ton of us who would love to be able to say we programmed a FUN Atari game.

Edited by mojofltr
Link to comment
Share on other sites

Besides saying your game shows promise, I should have said that it is already a lot of fun to play - even with the glitches. :)

 

I always get more excited in the latter stages of a game's development when a game author is polishing up the little bits.

 

Congratulations! There are a ton of us who would love to be able to say we programmed a FUN Atari game.

 

Thanks for the compliments. I've been wanting to program a fun atari game since 1978! :)

 

Here's the latest revision. The missiles will now speed up when you're on the approximate same Y position. They don't turn around, though, if they're past you they'll still speed up, but away from you. I've had a little trouble making them turn around, it's going to take alot of trial and error testing. Also, you'll now lose a life if you fall more than about two levels down.

 

So, the main three things left to fix on this game are the "holding down the button" jump problem, making the missiles change direction, and changing the title music. I could also add a 'cheat' mode, with unlimited lives by toggling color/bw, maybe I'll do that on the next version, it would help in playtesting.

 

@batari: Could you post some instructions on how to set up bankswitching properly when using 16k? It doesn't matter how I specify the specific banks with the "bank x" command, it always says there's no space in bank 0 by a large margin. I'd like to expand this to 16k, I'm out of space to do anything else...I'd have to remove a level or two, or maybe the win screen to free up enough space to make the changes I mentioned above.

 

Steve

jumper8k_8.bin

jumper8k_8.txt

Link to comment
Share on other sites

One way would be to use a variable as a flag, so that its set to on when the player jumps and dosnt go off again until the player has collided with the playfield. ex:

 

loop

player0y=y

If joy0fire && jump=0 then jump=5

if jump=5 then goto jumproutine

goto loop

 

jumproutine

jumpy = jumpy + 1

if jumpy < 11 then y = y - 1

if jumpy > 10 then y = y + 1

if jumpy > 5 && collision(player0, playfield) then jumpy=0 : jump=0

goto loop

 

 

EDIT:

also, to limit how often they can jump, you can use the variable as a counter:

 

If joy0fire && jump < 5 then jump = jump + 1

 

This will keep the sprite from zipping up and down like a musquito :P

 

Thanks for the suggestion, MausBoy. I tried to implement something similar, but the jump code I'm using just isn't much like your example, and I couldn't make it work. I came up with an alternative, but it causes other problems. The the player is now forced to press and release the button to jump, which fixes the 'mosquito' problem. I also made a few color changes (the darker colored levels made it very hard to see the ball), and level 11 was changed.

 

The new jump code causes two other known issues. If you fall, you can press and hold the fire button and hang in midair. The problem is how to apply gravity - I need to keep track of whether or not the player is in the middle of a jump. If so, I don't want gravity to pull him down. I haven't found a good way to do that yet.

 

Also, If you hold down the fire button and run to the edge of a platform, you won't fall -- you'll hang on the edge and jump when you release the button. It's the same problem with when exactly to apply gravity. So...fix a few bugs, create a few more. :(

 

I've spent hours and hours trying to perfect the jumping, and I'm having a hard time with it. I think need to take a break from this for a day or two. Attached is the latest revision.

 

Steve

 

My code takes care of when to implement gravity, and the flags aren't reset until the player lands on solid ground. Why exactly isn't it working for you? Is it because of how you detect the ladders? You should be able to use the same ideas to fix your code, just turn on a flag when the player jumps that isn't turned off until they collide with the playfield.

Link to comment
Share on other sites

Here's the latest revision. The missiles will now speed up when you're on the approximate same Y position. They don't turn around, though, if they're past you they'll still speed up, but away from you. I've had a little trouble making them turn around, it's going to take alot of trial and error testing. Also, you'll now lose a life if you fall more than about two levels down.

 

So, the main three things left to fix on this game are the "holding down the button" jump problem, making the missiles change direction, and changing the title music. I could also add a 'cheat' mode, with unlimited lives by toggling color/bw, maybe I'll do that on the next version, it would help in playtesting.

 

@batari: Could you post some instructions on how to set up bankswitching properly when using 16k? It doesn't matter how I specify the specific banks with the "bank x" command, it always says there's no space in bank 0 by a large margin. I'd like to expand this to 16k, I'm out of space to do anything else...I'd have to remove a level or two, or maybe the win screen to free up enough space to make the changes I mentioned above.

 

Steve

 

Missiles changing direction would be something like this:

 

dir(1) = 0 : x = 1

 

gameloop

missile0x = x

if dir(1) = 0 then x = x + 1

if x = 160 then dir(1) = 1

if dir(1) = 1 then x = x - 1

if x = 0 then dir(1) = 0

(other stuff)

goto gameloop

 

 

Since you use more than one "missile" and the flags are only on or off, the best idea would be to use bits of dir, so it'd be like dir(1)=0/1 for missile one, dir(2)=0/1 for missile two, dir(3)=0/1 for the ball. About bankswitched games not compiling, I had that problem until Batari told me to switch every PFCLEAR to PFCLEAR 0. That worked, so if you are using that command try that.

 

ps - if you want to add some challenge to harder levels try something like this:

player0x = a : player0y = b : missile0x = x : missile0y = y

if b = y && a > x then dir(1) = 0 : x = x + 1

if b = y && a < x then dir(1) = 1 : x = x - 1

 

This goes with the first example, and makes it so that if you cross paths with a missile, it switches directions and comes at you if it wasn't already, and hauls ass until you get out of its path.

Edited by MausBoy
Link to comment
Share on other sites

Thanks for the tips, MausBoy, I appreciate the feedback. The pfclear statement doesn't exist in the multisprite kernel, but I'm sure there's some other trick or tip batari can provide to make 16k bankswitching work.

 

I did get the missile speed code working after many hours of trial and error. They will speed up when they come within a 6 pixel range (the height of your player sprite), and will reverse direction if they've passed you. Simply comparing the Y positions of the player and missile didn't work, as the Y position of the player isn't in the middle of his body. ;) It also took some time to figure out how to make them continue off the screen after they speed up, they were just reversing again when the Y postions were no longer close. The missiles now function very similarly to the real Jumpman.... Unfortunately, the tradeoff to free up the space was the removal of the intro song. I figure improved gameplay is more important than the song anyway, and it can be re-added whenever I figure out how to make 16k bankswitching work. The audio will also need to be tweaked for the missiles to make the firing sound when they speed up rather than when they enter the playfield.

 

I haven't attemped to tackle the jumping problem again. It's a little bit less of an issue with how the missiles now work...if you jump around like a mosquito now you're much more likely to meet an untimely end. :D

 

Steve

jumper8k_9.bin

jumper8k_9.txt

Edited by Atarius Maximus
Link to comment
Share on other sites

Unfortunately, the tradeoff to free up the space was the removal of the intro song. I figure improved gameplay is more important than the song anyway, and it can be re-added whenever I figure out how to make 16k bankswitching work.

In all bankswitching schemes, if you don't specify where new banks begin, the bB code is in the first bank, while the graphics, kernel and routines are in the last.

 

For 8k bankswtiching, you don't need to do anything special to use up all of the space if you have written enough code to fill the first, plus defined enough graphics to fill the last. But for 16k or 32k bankswitching, doing nothing special will result in everything filling the first and last bank and the remaining banks will be empty.

 

You can only put bB code in the remaining banks right now (no graphics). To do this, you need to specify where the next bank begins, using "bank x" where x is the next bank (1-4 for 16k, 1-8 for 32k.) Furthermore, for any gotos or gosubs that occur from one bank to another, you must specify where the target is, with "bankx" after the statement. For returns, you don't need to do anything special, but there are some options to make things a little more efficient.

Edited by batari
Link to comment
Share on other sites

Unfortunately, the tradeoff to free up the space was the removal of the intro song. I figure improved gameplay is more important than the song anyway, and it can be re-added whenever I figure out how to make 16k bankswitching work.

In all bankswitching schemes, if you don't specify where new banks begin, the bB code is in the first bank, while the graphics, kernel and routines are in the last.

 

For 8k bankswtiching, you don't need to do anything special to use up all of the space if you have written enough code to fill the first, plus defined enough graphics to fill the last. But for 16k or 32k bankswitching, doing nothing special will result in everything filling the first and last bank and the remaining banks will be empty.

 

You can only put bB code in the remaining banks right now (no graphics). To do this, you need to specify where the next bank begins, using "bank x" where x is the next bank (1-4 for 16k, 1-8 for 32k.) Furthermore, for any gotos or gosubs that occur from one bank to another, you must specify where the target is, with "bankx" after the statement. For returns, you don't need to do anything special, but there are some options to make things a little more efficient.

 

Thanks batari. I was able to get the 16k version working thanks to your explanation. Just moving a few subroutines to bank 2 freed up about 800 bytes of space in bank 1, I should have plenty of space for changes now. It's a little disappointing that you can't put graphics into the other banks -- I doubt I'll need another 8k just for code. Having too much space is a nice problem to have, though. :)

 

Steve

Link to comment
Share on other sites

Here's some pseudo-code for anti-mosquito jumping:

 

You need a byte (or a bit) of RAM. Call it ButtonFlag.

 

So...

   if !joy0fire then ButtonFlag = 0 : goto SkipButtonRoutine
  if ButtonFlag != 0 then goto SkipButtonRoutine
  rem button is pressed and we want to make the guy jump, so...
  rem ...ButtonRoutine goes here
SkipButtonRoutine

I think that should work. Sorry if I messed up some of the syntax; hopefully it is clear enough.

Edited by vdub_bobby
Link to comment
Share on other sites

It's a little disappointing that you can't put graphics into the other banks -- I doubt I'll need another 8k just for code. Having too much space is a nice problem to have, though. :)

Graphics must go in the same bank as the kernel. There's really no way around this restriction, except for making multiple copies of the kernel, but bB doesn't support this feature (and it will be a while before it does.)

Link to comment
Share on other sites

Here's the first 16k version of the game. I haven't had all that much time to work on it this week, but i did spend a little time on the jump code. Using suggestions from vdub_bobby and Mausboy, I did come up with a workable solution. I'm not sure if this should be called a bug or not - if you hold down the fire button and walk to the end of a platform, you won't fall off. When you release the button, You'll jump. I tried to change this behavior, but if I set it to make you fall in that situation, there's no easy way to distinguish between hanging at the end of a platform with the fire button held down, or jumping between platforms - both result in a "no collision with anything" state. If I make the player fall in that state, it messes up jumping - gravity will pull you down a few pixels before you jump up, making it harder to jump. I've tried all of the obvious fixes, trying to set a flag for when you jump, skipping gravity code when you jump, etc...but every change I make seems to cause a new and different problem. Bleh. I don't think it really takes away from the game how it is now... it does allow for more precise jumping if you choose to play the game that way. I'd appreciate some feedback on how everyone likes how jumping works in this version.

 

There's one known bug: If you hold the button down when you're falling, you won't die no matter how far you fall. Still working on that one. Also, since I've done alot of work on this in my free time at work with no audio, there may be audio glitches with the current changes.

 

Steve

jumper16k_1.bin

jumper16k_1.txt

Link to comment
Share on other sites

Here's the latest version I finished up this morning. It fixes a few more bugs, the title song was re-added, and the jump code was revised yet again. The only bugs I know of are related to holding the button down -- the jumping audio stays on, and you won't die if you fall while holding the button.

 

The biggest problem with this version is it won't work on real hardware, the screen rolls. It's using too many cycles, so I'm going to have to spend a considerable amount of time changing things around. As I'm anticipating a busy week, I probably won't have time to work on this any more this week, so I'll have to use the most recent 8k version as the demo for the Midwest Gaming Classic. The other file attached (Jumper8kDemo.bin) is the one that will be at the show. I briefly tested it on real hardware, and it seems to work fine.

 

Steve

Jumper16k_2.bin

Jumper16k_2.txt

jumper8kDemo.bin

Link to comment
Share on other sites

I don't like giving negative comments but I think that you've fallen into that classic trap where you've made the game more difficult by making it too hard to control and therefore less fun because it's frustrating. I think back a few versions, even though there were certain 'holes', the game held a certain charm and was quite approachable.

Link to comment
Share on other sites

I don't like giving negative comments but I think that you've fallen into that classic trap where you've made the game more difficult by making it too hard to control and therefore less fun because it's frustrating. I think back a few versions, even though there were certain 'holes', the game held a certain charm and was quite approachable.

 

I appreciate your comments, positive or negative. You're right, it is a little more difficult to control the player with the changes I've made, although I've gotten pretty used to it with how much I play it in my testing. I'll probably just change it back to how the control was a few versions back, with the 'hole' being the ability to hold the button down and jump all over the screen. I may have to anyway, as I need to simplify some instructions in the game to free up cpu cycles to make it work on real hardware.

 

Steve

Link to comment
Share on other sites

I don't like giving negative comments but I think that you've fallen into that classic trap where you've made the game more difficult by making it too hard to control and therefore less fun because it's frustrating. I think back a few versions, even though there were certain 'holes', the game held a certain charm and was quite approachable.

 

I appreciate your comments, positive or negative. You're right, it is a little more difficult to control the player with the changes I've made, although I've gotten pretty used to it with how much I play it in my testing. I'll probably just change it back to how the control was a few versions back, with the 'hole' being the ability to hold the button down and jump all over the screen. I may have to anyway, as I need to simplify some instructions in the game to free up cpu cycles to make it work on real hardware.

 

Steve

Bankswitching requires some overhead. I suggest reorganizing your code to minimize the number of gotos or gosubs that cross bank boundaries. I recommend at most maybe 3 per frame.

 

The "bullets" are more challenging now and the falling is good. Regarding jumping: This new scheme does need work. I'm starting to think that allowing unlimited jumping while the button is down is not a bad idea, but if you do this, I think your player should be slowed down to avoid the "mosquito effect" (maybe to movement every other frame.) I'm not sure if the jumping in mid-air bug was fixed or not. If not, do a collision check when an jump has ended and fall if there is no collision, and disallow further jumps during this time.

Link to comment
Share on other sites

Hi

i tried the 16k variants on the z26.They do not work very well :( .Jumping is very difficult.And the latest 8k variant is too difficult.Best variant for playing is the 8kversion 8. :)

greetings Gambler172

 

Just to compromise, I made a version of the 8k demo that allows you to change the missile behavior.

 

Left Difficulty: A - Double Speed Missiles, B - Normal Speed Missiles

Right Difficulty: A- Missles are double speed, but do not shoot at you or change direction, B - Slower Missiles that shoot and change direction.

 

The demo version attached below will be the final revision for the MGC Show. ;)

 

Bankswitching requires some overhead. I suggest reorganizing your code to minimize the number of gotos or gosubs that cross bank boundaries. I recommend at most maybe 3 per frame.

 

The "bullets" are more challenging now and the falling is good. Regarding jumping: This new scheme does need work. I'm starting to think that allowing unlimited jumping while the button is down is not a bad idea, but if you do this, I think your player should be slowed down to avoid the "mosquito effect" (maybe to movement every other frame.) I'm not sure if the jumping in mid-air bug was fixed or not. If not, do a collision check when an jump has ended and fall if there is no collision, and disallow further jumps during this time.

 

Thanks for the tip about bankswitching. I figured the screen rolling was probably due to calling subroutines in other banks too frequently. It's going to take a while to make a change, test it on the cuttle cart, try again...etc. I should be able to figure it out, though.

 

I have tried slowing the player down to every other frame, I just never relased a version like that. It does work fine, the player just jumps all over the screen much more slowly. ;) Yes, you can still jump in mid-air, but I think I have an idea on how to fix that. Thanks for the feedback!

 

Steve

jumper8kDemo.bin

Link to comment
Share on other sites

Here's my first hardware compatible version of the 16k build, tested on my cuttle cart. The biggest change is to the scoring, the level you were last on and the number of treasures you've collected now appears on the title screen after you lose your last life. Jumping was changed back to how it was originally (allowing you to jump quickly around the screen), however I slowed movement down to every other frame. It can be switched back and forth to full speed using the color/bw switch. The win screen was also changed to free up some space. In order to add all of the additional number sprites, the alternate playfield for level 10 was axed. The Left/Right difficulty switches function the same as in the 8k demo version a few posts back.

 

Here's the known issues with this version that I still need to work on:

 

1. it's still possible to jump in mid-air.

2. the new build caused some audio headaches for me, for now the "walking" sound has been removed. All other sound effects seem to be working fine.

3. the title song was added back in, but it still needs to be changed.

4. the "holding down the button" problem still exists when you jump - but it may just have to stay like it is. The only other issue I can see that it causes is it can screw up the fall counter, sometimes you'll die for no apparent reason if you hold down the button and move around the screen.

 

Enjoy!

 

Steve

Jumper16k_3.bin

Jumper16k_3.txt

Edited by Atarius Maximus
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...