Jump to content
IGNORED

Jumper - Final Version Complete


Atarius Maximus

Recommended Posts

I put this together today just to see if I could make a demo that even remotely looks like Jumpman from the C64, one of my all-time favorite games. This isn't a playable game at all, but it looks pretty cool. I'm going to continue to work on this and see if I can make an actual game out of it. ;)

 

Edited 14 years later on 6/14/2020 to include the last version I made in the first post.  Thanks to ZeroPage Homebrew for playing the game on your show, and thanks to everyone who tried it out.  No plans to update this after all these years!

 

Steve

post-2143-1144700829_thumb.jpg

jumpmandemo.bin

JumpmanDemo.txt

Jumper99rc1.txt jumper99rc1.bin

Edited by Atarius Maximus
Updating first post with last binary
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Whoa! That's pretty smooth. I didn't know there was a working build of bB that used the multi-sprite kernel. :thumbsup:

 

Thanks. :)

 

I'm using build 99b. It works, but I'm running into a few problems. Collision Detection doesn't seem to work properly with player sprites 2 through 5 (the code causes compilation errors), and I can't change the background color, it's stuck on grey. I'm excited about the possibilities with this kernel, though, it was fun putting this together today.

 

Steve

Edited by Atarius Maximus
Link to comment
Share on other sites

Whoa! That's pretty smooth. I didn't know there was a working build of bB that used the multi-sprite kernel. :thumbsup:

It's been functional for about 4 months now, though the integration into bB is still quite messy, and I haven't done anything with it for a little while after getting stuck on the intelligent flicker :( . The overall support for the kernel is still very preliminary as you can see, and this is the first time I've seen it used... That's good, now bug reports will start to come in.

 

I'm using build 99b. It works, but I'm running into a few problems. Collision Detection doesn't seem to work properly with player sprites 2 through 5 (the code causes compilation errors), and I can't change the background color, it's stuck on grey. I'm excited about the possibilities with this kernel, though, it was fun putting this together today.

 

Steve

Yeah, the collision thing an undocumented "feature" since all sprites are copies of player 1 (or is it player 0?) so the collision detection for player 1 means that you've hit one of the ladders, and you need to figure out yourself which one by your y-position.

 

This may change if I can find enough cycles in the kernel, but I wouldn't count on it. I will fix the background color thing though.

Link to comment
Share on other sites

It's still not playable, but I made a few changes. I fixed the background color problem my manually editing the asm file, and the player can now move back and forth and up and down the ladders on the bottom two platforms, but it's still buggy. I've got a long way to go before this is a playable game. ;)

jumpdemo2.bin

post-2143-1144863747_thumb.jpg

JumpDemo2.asm.zip

Link to comment
Share on other sites

  • 2 weeks later...

A few more things are working now;

 

Gravity - you'll fall when you walk or jump off the edge of a platform.

Ladders - You can go up and down all of them, and should be forced to get off on a platform, not midway up the ladder.

Jumping - Jumping is working pretty well -- you have to push left or right and the fire button. All the platforms are reachable via jumping.

 

It's still not a playable game, but it's a much more interesting demo now. :)

 

Steve

jmandemo2.bin

jman4.txt

post-2143-1145566734_thumb.jpg

Link to comment
Share on other sites

That looks great! Right now you can get stuck in the ceiling, and the game crashes if you try to go down one of the bottom ladders. Collision detection between sprites and the background seems to be a big hurdle with bB games, maybe this one will give us a clue when it's finished.

Link to comment
Share on other sites

I've finally got this demo turned into a playable game. I wasn't able to make the gameplay much like the original jumpman, but it's still kind of fun. I'm not sure what I'm going to name it yet, but I suppose I'll have to change it from "Jumpman".

 

Changes:

1. There is a moving "death missile" on the screen that will kill you if it hits you, this is similar to how the original jumpman behaved. After being hit by the missile 3 times, the game ends, and you have to hit reset to start over.

2. There is a single treasure at the top of the screen, the goal of the game is to get to the top and collect the treasure before you're shot by the missile. Once you've touched it, your player will hold it above his head and float back down to the bottom of the screen. The treasure will then be reset to the next of four locations at the top of the screen. After you've collected the treasure 4 times, the missile speed will increase, increasing the difficulty of the game.

3. You won't crash the game by going too far down on the bottom ladder, and you won't get stuck in the ceiling.

4. Death sequence added - when you're hit by a missile, you will fall to the bottom of the screen with a "splat" sprite.

 

Problems:

1. No Score! The score routine doesn't exist yet in the multisprite kernel. For now, you'll have to keep track of how many treasures you've collected, which is how I'd be scoring the game.

2. No Space! Only 84 bytes remain. I'm sure I could do some code cleanup, but right now I'm using almost the entire 4k of space with the game as it is now. I've got lots of ideas of additional things that could be added, but there isn't any more room.

3. I can't place the treasure on lower platforms, because of the flicker. When the ladders flicker, collision detection fails.

4. No Animations on the human player sprite: I really wanted to do this, but there's not enough space.

 

Other than the problems listed above, the game seems to work pretty well! :D

 

Steve

jumpman.bin

jumpman.txt

Edited by Atarius Maximus
Link to comment
Share on other sites

This looks great, and the collision detection is perfect. I think you should try messing with the way you increase the missile speed, it goes from slow to bullet speed in one round. Also, you should turn off collision detection during the fall back down, right now a missile can kill you while you are falling with the treasure.

I'm jealous of what you are doing with the msk, right now I can't even get a hello world to compile with it.

Link to comment
Share on other sites

This looks great, and the collision detection is perfect. I think you should try messing with the way you increase the missile speed, it goes from slow to bullet speed in one round.

I agree, I would like to do that, but it requires using 4.4 or 8.8 variables. I haven't been able to get that to work. batari assisted with that issue, in that he pointed out that using those variables causes label mismatch errors during compilation - but it should still be a usable binary. I've been unable to generate a usable binary using those variables to this point.

 

Also, you should turn off collision detection during the fall back down, right now a missile can kill you while you are falling with the treasure.
That should be easy to fix, I'll include it in the next revision. My next task is to see how I can compress the code a little bit. Anybody have any suggestions? ;)

 

I'm jealous of what you are doing with the msk, right now I can't even get a hello world to compile with it.

I've posted my most up to date code if you'd like to take a look, I've wasted many hours on this now... :)

 

Thanks also to Gateway and djmips for the compliments! :cool:

 

Steve

Link to comment
Share on other sites

This is pretty cool!

 

As noted, more missile speeds would be nice; I'll also agitate for a more realistic jumping motion.

 

I agree, it definitely needs variable missile speeds. Without the use of fractional variables, it can only go fast or slow, there's no in-between. Changing the jumping motion would probably also require fractional variables. Once I figure out how to get it to compile correctly with the MSK, I'll try to make those changes, providing I can free up enough space for it.

 

I just got my Cuttle Cart 2 in the mail today (Thanks Chad! :) ), I can't wait to try this out on real hardware!

 

Steve

Link to comment
Share on other sites

I agree, I would like to do that, but it requires using 4.4 or 8.8 variables. I haven't been able to get that to work. batari assisted with that issue, in that he pointed out that using those variables causes label mismatch errors during compilation - but it should still be a usable binary. I've been unable to generate a usable binary using those variables to this point.

 

You could try using a variable speed throttle, something like this:

 

speed = speed + 1

if speed = 5 && level = 5 then missile1x = missile1x + 1 : speed = 0

if speed = 6 && level = 4 then missile1x = missile1x + 1 : speed = 0

if speed = 7 && level = 3 then missile1x = missile1x + 1 : speed = 0

 

etc. That way on each level speed has to be 1 less for the missile to move, making it faster.

Link to comment
Share on other sites

I agree, I would like to do that, but it requires using 4.4 or 8.8 variables. I haven't been able to get that to work. batari assisted with that issue, in that he pointed out that using those variables causes label mismatch errors during compilation - but it should still be a usable binary. I've been unable to generate a usable binary using those variables to this point.

 

You could try using a variable speed throttle, something like this:

 

speed = speed + 1

if speed = 5 && level = 5 then missile1x = missile1x + 1 : speed = 0

if speed = 6 && level = 4 then missile1x = missile1x + 1 : speed = 0

if speed = 7 && level = 3 then missile1x = missile1x + 1 : speed = 0

 

etc. That way on each level speed has to be 1 less for the missile to move, making it faster.

 

I'm not sure I see how that would be much different than what I'm doing now, unless I'm just not understanding your code sample. If I increase the X value by 1 per "game loop", it's the normal speed, if I increase it by 2, it's the super fast bullet speed. Incrementing the X value of the missile by any more than 2 per game loop makes the missile too fast.

 

Or, maybe I just need to look at your post again after my kids are in bed and I can hear myself think! Argh.

 

Steve

Edited by Atarius Maximus
Link to comment
Share on other sites

I agree, I would like to do that, but it requires using 4.4 or 8.8 variables. I haven't been able to get that to work. batari assisted with that issue, in that he pointed out that using those variables causes label mismatch errors during compilation - but it should still be a usable binary. I've been unable to generate a usable binary using those variables to this point.

 

You could try using a variable speed throttle, something like this:

 

speed = speed + 1

if speed = 5 && level = 5 then missile1x = missile1x + 1 : speed = 0

if speed = 6 && level = 4 then missile1x = missile1x + 1 : speed = 0

if speed = 7 && level = 3 then missile1x = missile1x + 1 : speed = 0

 

etc. That way on each level speed has to be 1 less for the missile to move, making it faster.

 

I'm not sure I see how that would be much different than what I'm doing now, unless I'm just not understanding your code sample. If I increase the X value by 1 per "game loop", it's the normal speed, if I increase it by 2, it's the super fast bullet speed. Incrementing the X value of the missile by any more than 2 per game loop makes the missile too fast.

 

My example dosn't make the missile move more or less pixels across the screen, just more or less often. It adds one to speed every "game loop", then checks to see if speed is now equal to the level variable, if so it moves the missile one pixel and resets speed to zero. If the level is 1 then the missile would only move once every 9 "game loop"s. On level 5, it moves once every 5.

Link to comment
Share on other sites

My example dosn't make the missile move more or less pixels across the screen, just more or less often. It adds one to speed every "game loop", then checks to see if speed is now equal to the level variable, if so it moves the missile one pixel and resets speed to zero. If the level is 1 then the missile would only move once every 9 "game loop"s. On level 5, it moves once every 5.

 

Ah, that makes sense. I'm going to work on the missile speeds today, I'll see what I can do.

 

Steve

Link to comment
Share on other sites

I consolidated a little bit of the code, and added a few more features to increase the difficulty of the game as it progresses. I'm now down to 84 bytes free, and I've done all the code cleanup that I know how to do. I'd have to start removing existing features to add new ones now. I might have enough space to add it a few audio routines to the game, and I should be able to squeeze in a score counter once the kernel supports it.

 

Here's what's new:

 

1. Missile speed now gradually increases with every treasure taken.

2. After 4 Treasures are collected, two Missiles appear (actually one of them is the ball), and one top ladder is removed.

3. After 8 Treasures are collected , another top ladder is removed.

4. After 12 Tresures are collected, a middle ladder is removed

5. The playfield was tweaked a little bit (platform & border changes). I can't decide what looks best for the borders on the top and bottom of the screen. If anyone has a suggestion to improve how that looks, I'm open to new ideas.

 

Issues:

 

1. The routine I'm using to gradually increase missile speed moves the missile/ball object more than one pixel at a time. When the speed gets going really fast, if you're standing in just the right spot, the missile will pass right over you and you won't die. The whole missile speed routine is going to have to be changed, I think.

2. I tried to make the fractional variables work, and I can't - the code just doesn't compile properly for me, I get a blank screen when I run the bin. I used a similar method to what MausBoy posted to get the variable speeds on the missiles working as they are now.

 

 

Hi

really nice.Great work.

greetings Gambler172 :)

 

Thanks!

jumpman4.bin

jumpman4.txt

Link to comment
Share on other sites

You could try using a variable speed throttle, something like this:

 

speed = speed + 1

if speed = 5 && level = 5 then missile1x = missile1x + 1 : speed = 0

if speed = 6 && level = 4 then missile1x = missile1x + 1 : speed = 0

if speed = 7 && level = 3 then missile1x = missile1x + 1 : speed = 0

 

An alternative approach would be to do something like:

speed=speed+levelspeeds(level)

if speed & 128 then missile1x=missile1x+1 : speed = speed & 127

 

Using this approach, a levelspeeds() value of 128 would move a pixel every frame; a value of 64 would move every other frame, etc. This approach will give you much finer control of speed than you get via most other methods.

Link to comment
Share on other sites

1. The routine I'm using to gradually increase missile speed moves the missile/ball object more than one pixel at a time. When the speed gets going really fast, if you're standing in just the right spot, the missile will pass right over you and you won't die. The whole missile speed routine is going to have to be changed, I think.

To get around this, you can make the missile/ball double/quad-width as they get faster.

Edited by vdub_bobby
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...