S.K.O.B: Some kind of Bombjack (early WIP)

[Steril707]

After seeing Retrofans Mock up Pics of an old favourite game of mine in this thread: http://www.atariage.com/forums/index.php?s...ic=57802&hl

i started coding up my own little version of Bombjack for the 2600.

 

I don't know how true i will stay to the original game, so at the moment the working title is "S.K.O.B.:Some Kind of Bombjack" (in case you wondered about the thread title )

 

You can already jump around and collect bombs, but no enemies and a couple of other glitches. I am currently working on the platform part of the game, so you cannot jump from a platform, nor do they hinder you. The walls dont work as well yet. Should be done around the next days though.

 

When i am done with the platform code, i would like to do a little level design contest around here on Atariage...

 

greets,

Michael

 

 

(check out the lastest .bin file at the bottom of this post.)

 

 

 

 

 

Bombjack_v0_1.bin

Bombjack_v0_11.bin

Edited September 11, 2007 by Steril707

[Atariboy2600]

Wow finaly Bomb Jack on the 2600!

[Retrofan]

very good, more ...

[BSA Starfire]

Brilliant i always loved this game. Good luck

[gambler172]

Hi Michael

Looks good so far.I hope we will see more soon(and not a cancelled project)

Bomb Jack was one of my favourite games on the Atari ST.

Would be nice to see some enemies in the next posted bin.

greetings Walter

[Atariboy2600]

Just in case you get the game up and runing heres some old Label art I did some time ago on Bomb Jack^_^

 

[Steril707]

Thanks for the support to everybody here... I hope i can learn enough about the 2600 to finish this project.

I guess the biggest wall i will hit soon is multiplexing sprites in a clever way...

[Thomas Jentzsch]

Thanks for the support to everybody here... I hope i can learn enough about the 2600 to finish this project.

I guess the biggest wall i will hit soon is multiplexing sprites in a clever way...

First make sure that you design your kernel so that you can reposition sprites every few rows. This should make things much easier.

[Steril707]

Just in case you get the game up and runing heres some old Label art I did some time ago on Bomb Jack^_^

 

 

[Kurt_Woloch]

First make sure that you design your kernel so that you can reposition sprites every few rows. This should make things much easier.

 

I thought about this one a little more... basically, to my knowledge, you can't reposition a sprite on the same scanline as you display an asymmetric playfield because of time constraints. That's why games like Dig Dug and Super Cobra always have "holes" in their playfields to make room for lines where they can do this.

At first glance your playfield looks all asymmetric, with the walls and platforms as well as the bombs. But then I looked at the arcade original. And looking at that, it doesn't seem to be undoable to me anymore, because there are not so many vertical walls in one scanline that this would be a problem.

I've examined all the screens the arcade original has, and there are only 16 distinct platform layouts. Out of them, 6 are asymmetric, and 10 are totally symmetric. 8 of the 16 layouts have vertical walls (the other ones don't), and out of those 8, only 2 have assymetric vertical walls. Out of those 2, one screen only has one wall at most per line which is displaced from the center. I thought this could be handled by using the ball for the vertical line, at least in the places where you can't draw an asymmetric playfield directly because you reposition sprites. The other one has sort of a "spiral", but there would still be scanlines in that screen where only one wall is shown, and those are not too far apart, so on those there still would be room for repositioning sprites.

Other than that, in the arcade version, the bombs are laid out on a 9 x 9 grid, though the total number of bombs in each screen is 24. The maximum number of enemies to appear on screen is 9, in addition there are two bonus items and your player sprite, so 11 sprites in total.

As far as I can see, you have laid out the bombs in a 4 x 9 or 4 x 10 grid, so there is only half the number of rows.

Could you try to bring that closer to the mockup screen? As far as I can see, on the mockup screen by Retrofan, the bombs are 8 scanlines high, and the platforms are 8 scanlines high too. But that's a bit out of proportion, in my opinion, since on the arcade version, you have bombs that are 16 scanlines high and platforms with 8. I think if the bombs are 8 scanlines high on the VCS, it would be OK to show platforms that are 4 scanlines high, so that the 2 scanlines between the platforms and the bombs on each side could be used for sprite repositioning and playfield setup. How many scanlines do you need to set up the display of a row of bombs or a row of platforms?

[Steril707]

Well, basically you are right, but i think you are forgetting that i am displaying bombs by playfield gfx as well, so you would have to take them into account to. So we have Walls and Bombs in the "Bombkernal" part. I have also two "Spacekernals" for each row (above bomb and below bomb), but your approach would be to customize every level for this thing, and i am really looking for something i can use generally in all situations/levels.

 

I have some other approach in mind though, but that would mean that the middle walls would show a 1 scanline hole at the top of each row, but i haven't actually checked out yet.

I wanna get the platform collision code right first, and then i will start to handle multisprites, so i will give you an update on this sometime later.

 

 

You are right on the lack of platform rows. This is a little bit of a design issue for me, and i am not quite sure in which direction i am heading. Currently i am doing a 2 line kernal, which means i can only update the sprites every two rows. Retrofans' Mock-up is using a 1lk approach, which is not feasable with a symmetric playfield and two player graphics displayed, even with PF0 being left out (what i did). So, if i insert more platform rows, i would have to shrink the sprite size accordingly, which would lead to very unrecognizable Sprites. At the moment i think about inserting one more row of platforms, but thats it.

 

(small edit/addition to the above paragraph: i need around 12 more bytes of ram for each row of platform and bombs on my current design, so thats another barrier. I think having 4 instead of the former 3 platform levels will do fine though and is a good compromise)

 

 

This Bomb Jack won't be a near arcadeperfect translation like Ladybug, but maybe more kind of an interpretation, hence the "Some kind of Bombjack" in my thread (and game-)title. I am not even sure if i will use the original games platform layouts in any way, though i might be inspired by them. My game will surely feature Bombs to collect, some critters running (and probably flying) around who are chasing you, Platforms and Walls, and thats it. I will try to have this thing resembling Bomb Jack a lot, but i certainly won't promise to deliver something even 80 percent close to the arcade experience on my first 2600 project.

 

Sorry for ranting off a little bit, i just don't want anybody to be all to disappointed if this isn't growing into the Bombjack he or she is used to, which is kind of difficult anyway, regarding the many different versions me alone has played over the years which all felt quite different, but all of them good in their own way (even the tainted C64 one, which i probably played the most of all of them).

 

Anyway, i am open for any constructive criticism and advice, so keep 'em coming...

Edited September 6, 2007 by Steril707

[Atariboy2600]

Other then DK, MsPacman and Star Wars arcade Bomb Jack is one of my top fave on the list, I remeber in NYs Time Square arcade I took all my tokens on one arcade Bomb Jack for all two to three hours^_^<3

[Kurt_Woloch]

Well, basically you are right, but i think you are forgetting that i am displaying bombs by playfield gfx as well, so you would have to take them into account to. So we have Walls and Bombs in the "Bombkernal" part. I have also two "Spacekernals" for each row (above bomb and below bomb), but your approach would be to customize every level for this thing, and i am really looking for something i can use generally in all situations/levels.

 

Well... not really. I only wanted to see what the kernel has to be able to do. In principle, the kernal should repeat as many times as there are possible rows of bombs. Inside that loop, the lines for platforms and the lines for bombs would repeat as well. The levels could be designed to take this into account. The question is what you mean by "customizing" each level. Basically, each level does have different data, so there is already some difference between levels. What you probably mean is if inside the visible area, different branches would be taken depending on the level. If that's the question, then yes, I would suggest that... but only for a small piece of code which either branches to the repositioning code or continues to draw the screen, depending on what's feasible in the given row.

 

You are right on the lack of platform rows. This is a little bit of a design issue for me, and i am not quite sure in which direction i am heading. Currently i am doing a 2 line kernal, which means i can only update the sprites every two rows. Retrofans' Mock-up is using a 1lk approach, which is not feasable with a symmetric playfield and two player graphics displayed, even with PF0 being left out (what i did). So, if i insert more platform rows, i would have to shrink the sprite size accordingly, which would lead to very unrecognizable Sprites. At the moment i think about inserting one more row of platforms, but thats it.

 

Well, looking at Retrofans' mockup, the sprites seem to be 12 scanlines high. And if you think a one-line-kernal isn't feasible, maybe you should think again. I looked at the source code for Coleco's 2600 Donkey Kong (which you can find somewhere on the net), and Mr. Kitchen managed to display an asymmetric playfield (at least in the 1st screen) along with 2 players, one of which (Mario) is even color-striped. But he narrowed down the playfield to 24 of the 40 available columns so that he has only 4 playfield writes per scanline, in addition to the 3 writes for the players. By the way, he repositions the enemy sprite (Mario doesn't get repositioned) in the scanlines where next to nothing is being drawn (in the middle of the ladders). And his kernal differs considerably for the two screens. So, in total he does 7 writes per scanline, which is pretty good in my opinion (probably the maximum you can do). OK, so you are doing 5 PF writes, 2 player graphics writes and 2 color writes per line (FG/BG of the screen), which would be 9 writes, which probably isn't feasible for a 1-line kernel.

 

(small edit/addition to the above paragraph: i need around 12 more bytes of ram for each row of platform and bombs on my current design, so thats another barrier. I think having 4 instead of the former 3 platform levels will do fine though and is a good compromise)

 

I see... so you're probably already storing the PF patterns for the running line in zeropage RAM in order to be able to access them faster. This was actually what I was going to suggest, but the catch is that you have to setup those RAM locations somewhere.

 

This Bomb Jack won't be a near arcadeperfect translation like Ladybug, but maybe more kind of an interpretation, hence the "Some kind of Bombjack" in my thread (and game-)title. I am not even sure if i will use the original games platform layouts in any way, though i might be inspired by them. My game will surely feature Bombs to collect, some critters running (and probably flying) around who are chasing you, Platforms and Walls, and thats it. I will try to have this thing resembling Bomb Jack a lot, but i certainly won't promise to deliver something even 80 percent close to the arcade experience on my first 2600 project.

 

OK, I see... so the levels can be redesigned so they fit the programming that's possible on the 2600 better.

[Impaler_26]

Great! I'm looking forward to see more of this!

[Steril707]

Well... not really. I only wanted to see what the kernel has to be able to do. In principle, the kernal should repeat as many times as there are possible rows of bombs. Inside that loop, the lines for platforms and the lines for bombs would repeat as well.

----------

Thats whats happening in my code so far.

 

 

The levels could be designed to take this into account. The question is what you mean by "customizing" each level.

-------------

At the moment i am reading the levels out of a data table in rom, partly comverting stuff into some zero page ram locations (the bombs) and directly reading stuff out of romspace (the platforms and their collision data for instance).

Customizing would mean for me to write a different kernal for each level, and thats what your approach sounded to me like. I am sorry if i misread that.

 

 

 

Basically, each level does have different data, so there is already some difference between levels. What you probably mean is if inside the visible area, different branches would be taken depending on the level. If that's the question, then yes, I would suggest that... but only for a small piece of code which either branches to the repositioning code or continues to draw the screen, depending on what's feasible in the given row.

---------

Well, as i said, i hope i can do a reposition in my init sequence for each row, which would lead to a space in the middle wall rows (which i was able to avoid up to now). But that would be okay i guess. It keeps the code modular, and i dont need to have any branches.

 

 

 

 

Well, looking at Retrofans' mockup, the sprites seem to be 12 scanlines high. And if you think a one-line-kernal isn't feasible, maybe you should think again. I looked at the source code for Coleco's 2600 Donkey Kong (which you can find somewhere on the net), and Mr. Kitchen managed to display an asymmetric playfield (at least in the 1st screen) along with 2 players, one of which (Mario) is even color-striped.

-------------

I just downloaded the game, and i am surprised. This is the first time since 1983 that i see the VCS version of it, and i have to say i really don't understand what the fuss is about. The game looks nice, and plays extraordinary well. I dont understand why Donkey Kong himself looks the way he does (big meh), but other than that it's a quite spectacular game for the 2600 and the time.

 

 

 

But he narrowed down the playfield to 24 of the 40 available columns so that he has only 4 playfield writes per scanline,

-------------

so do i.

 

 

in addition to the 3 writes for the players. By the way, he repositions the enemy sprite (Mario doesn't get repositioned) in the scanlines where next to nothing is being drawn (in the middle of the ladders).

 

 

And his kernal differs considerably for the two screens.

-----------

Thats what i meant with "customization". If i code, i head for one routine doing all the stuff if possible, not different ones.

I agree though, doing something like DK needs customized kernals. Those two screens play like different games, but Bombjacks stages don't.

 

So, in total he does 7 writes per scanline, which is pretty good in my opinion (probably the maximum you can do). OK, so you are doing 5 PF writes, 2 player graphics writes and 2 color writes per line (FG/BG of the screen), which would be 9 writes, which probably isn't feasible for a 1-line kernel.

-------------

Well, coding for the 2600 is entering a world of full of compromises. Like you noticed, having all that stuff in a 1lk, i would need to give up the colorfulness of the game, bombs would have the same color as the platforms and the background would be completely dull in one color, which would be a shame. I tried that out, and it looks boring, and i feel most people here, given the choice to decide for one version or the other would happily trade the more colourful but less platformy for the other , dull looking version, even if that means having a few platform levels less.

 

 

 

 

OK, I see... so the levels can be redesigned so they fit the programming that's possible on the 2600 better.

------------------

Let's see what happens. I think something fun for people who like Bombjack as much (and more) as i do is possible, even if it's not 100 %of the arcade experience.

 

 

Greets,

Mike

[+SpiceWare]

Nice

[supercat]

I'm not familiar with the original, so I have no idea how the enemies move. That would be a major factor in deciding how to do things.

 

Fetching and writing seven bytes of data per scan line is hardly magical. Toyshop Trouble does eight fetch/store operations within the conveyor-display loops, and does nine stores during a couple of the status-bar loops (though in those particular loops two stores wrote constants).

 

Donkey Kong actually gets up to nine stores per line in the vicinity of the hammer (COLUP0/GRP0/GRP1/PF1/PF2/PF2/PF1/ENAM1/ENABL) but uses a RAM buffer to assist with that. I believe Casino gets up to ten loads/stores per line; my Sudoku kernel does as well. My Arkanoid kernel (Supercharger only) can get up to 19 stores per line; I'm unaware of anything higher than that.

[Atariboy2600]

[quote name='supercat' date='Thu Sep 6, 2007 8:05 PM' post='1365591'

I'm not familiar with the original, so I have no idea how the enemies move. quote]

 

Step 1 - Download Bomb Jack arcade for MAME

Step 2 - Run Mame with Bomb Jack

Step 3 - Say goodby to your outside world one last time cuase this game will make you Hooked!

[Steril707]

I'm not familiar with the original, so I have no idea how the enemies move. That would be a major factor in deciding how to do things.

 

Hey Supercat,

the enemies are basically one bird flying around all over the screen and some spacemen walking around on the platforms. Later on the spacemen fall to the ground and transform into flying enemies as well. This is the difficult aspect of the whole affair, i think. You would have a couple of freely moving objects on the screen.

 

hmm...

[Kurt_Woloch]

I'm not familiar with the original, so I have no idea how the enemies move. That would be a major factor in deciding how to do things.

 

Hey Supercat,

the enemies are basically one bird flying around all over the screen and some spacemen walking around on the platforms. Later on the spacemen fall to the ground and transform into flying enemies as well. This is the difficult aspect of the whole affair, i think. You would have a couple of freely moving objects on the screen.

 

hmm...

 

Well, not necessarily... the logic of the enemies could be changed so they never are more than one in a scanline... similar to how Atari did it in Joust and Phoenix. The enemies spawn one after each other, with the bird usually being the first. There are usually two spawning positions per level, if you are on the left half of the screen, the enemies spawn on the right position, and if you are on the right half, they spawn on the left one. After spawning, they walk left and right on their platform for some time, then fall down to the next platform where the start walking again, unless they hit the ground, in which case they transform to flying enemies.

Now the screen is divided in "zones". One zone usually is one row of bombs and platforms, and the logic could be changed in a way that the walking men aren't allowed to fall down unless the zone below them has no enemy on it, and a new one is only allowed to spawn if it would be alone in the zone in which to spawn. Similarly, the heatseeking flying enemies as well as the bird would only be allowed to leave their zone if the target zone is free.

Now we could get a problem if the bird blocks a zone, and another enemy is in the zone above the bird. Therefore the logic could be changed so that two objects (the two players) are allowed in each zone, one of them being the player. Now, of course, you can't limit the player's movement, so if the player decides to enter a zone where there are already two enemies, those two begin to flicker at 30 Hz, but one of them would try to use the next opportunity to leave that zone. Does that sound feasible?

Another idea would be to limit the color changes in the background in order to reduce the number of writes and allow a one-line kernal. What if the foreground only changes between one shade of red (for the bombs) and one platform color (different per level), and background color changes would only occur once per "zone"?

Another idea would be to have "double enemies" in some places, that is, two enemies that are actually two copies of the same player, which spawn and fall together (the platform layout of that level would have to allow for that, however).

[Godzilla]

cant wait to see what this looks like... big bombjack fan... any screenshots so far?

[Steril707]

I'm not familiar with the original, so I have no idea how the enemies move. That would be a major factor in deciding how to do things.

 

Hey Supercat,

the enemies are basically one bird flying around all over the screen and some spacemen walking around on the platforms. Later on the spacemen fall to the ground and transform into flying enemies as well. This is the difficult aspect of the whole affair, i think. You would have a couple of freely moving objects on the screen.

 

hmm...

 

Well, not necessarily... the logic of the enemies could be changed so they never are more than one in a scanline... similar to how Atari did it in Joust and Phoenix. The enemies spawn one after each other, with the bird usually being the first. There are usually two spawning positions per level, if you are on the left half of the screen, the enemies spawn on the right position, and if you are on the right half, they spawn on the left one. After spawning, they walk left and right on their platform for some time, then fall down to the next platform where the start walking again, unless they hit the ground, in which case they transform to flying enemies.

Now the screen is divided in "zones". One zone usually is one row of bombs and platforms, and the logic could be changed in a way that the walking men aren't allowed to fall down unless the zone below them has no enemy on it, and a new one is only allowed to spawn if it would be alone in the zone in which to spawn. Similarly, the heatseeking flying enemies as well as the bird would only be allowed to leave their zone if the target zone is free.

Now we could get a problem if the bird blocks a zone, and another enemy is in the zone above the bird. Therefore the logic could be changed so that two objects (the two players) are allowed in each zone, one of them being the player. Now, of course, you can't limit the player's movement, so if the player decides to enter a zone where there are already two enemies, those two begin to flicker at 30 Hz, but one of them would try to use the next opportunity to leave that zone. Does that sound feasible?

Another idea would be to limit the color changes in the background in order to reduce the number of writes and allow a one-line kernal. What if the foreground only changes between one shade of red (for the bombs) and one platform color (different per level), and background color changes would only occur once per "zone"?

Another idea would be to have "double enemies" in some places, that is, two enemies that are actually two copies of the same player, which spawn and fall together (the platform layout of that level would have to allow for that, however).

 

There are some really good ideas in your post. I will surely use some of your suggestions...

Thanks a lot...

 

Mike

[supercat]

the enemies are basically one bird flying around all over the screen and some spacemen walking around on the platforms. Later on the spacemen fall to the ground and transform into flying enemies as well. This is the difficult aspect of the whole affair, i think. You would have a couple of freely moving objects on the screen.

 

I would suggest perhaps having two similar kernels, memory permitting, which are used on alternate frames; this would allow the use of flicker-blinds for the bombs and level. On half the frames, you show bombs and walls/floors in one color on the even scan lines, and walls only in the other color on the odd lines; on the other half of the frames, you switch even and odd scan lines.

 

I would suggest that in each 'zone' you recognize three sprites: the player, a non-vertically-mobile spaceman, and a vertically-mobile enemy which could be either a spaceman or a bird. The non-vertically mobile spaceman would be drawn on half the frames using M1 and on half the frames using M0, thus giving it a different color from the bird (vertically-mobile spacemen should have their color flickered likewise). See M-Network's football cartridge for a nice illustration of drawing men with missiles.

 

With that set of restrictions, a spaceman would only be able to fall down if the zone below was completely vacant and his own zone didn't have a bird in it; a bird could enter a zone if it was either totally empty, or was empty except for a non-falling spaceman.

 

Allowing the "missile" spacemen to move vertically might improve the gameplay further, but designing the kernel to allow for that might be more difficult. By no means impossible (in M-Network's football game, both missile-men are vertically mobile).

[Atariboy2600]

I know Im not a programer and thsi maybe a huge pipe-dream idea but if theres anyway to add a backdrop image for each levels like the arcade stages I use a real 2600 screenshot and made a mockup backdrop in three diffent way but again dont know if this will work:P Using the 640+400 size screenshot heres what it could be or not.^_^;

 

[Steril707]

I know Im not a programer and thsi maybe a huge pipe-dream idea but if theres anyway to add a backdrop image for each levels like the arcade stages I use a real 2600 screenshot and made a mockup backdrop in three diffent way but again dont know if this will work:P Using the 640+400 size screenshot heres what it could be or not.^_^;

 

 

Hey Atariboy,

of course it's sad to have a Bombjack without the backdrops, but as i see it there is simply no way to integrate them. I use the playfield graphics for displaying the platforms and bombs, so, no good way of having backdrops.

 

If the enemy sprites wouldn't move around as much as they do, i could think of using player graphics (=sprites) for the platforms but then the bombs would still ned to get displayed. Overall, its simply too much overhead.

 

A feasible approach, using my current "engine", would be to flicker playfield gfx, like ladybug does, so it would be possible to have the backdrops having a different color from the platforms and bombs. But given the size of the backdrops, i guess people wouldnt want to play the game for feeling nausea after around 10 seconds of doing so.

 

As for your Mockup-pics, they don't take the Ataris' restrictions into account. Your backdrops would be needed to built up with player graphics (having 160 pixel resolution per scanline), but usually you would built up something like that with playfield graphics, and then you only have 40 pixels horizontal resolution for one scanline. Check out Retrofans Mockup pics, i think he quite nails the 2600's restrictions with his Mockup stuff.

Edited September 8, 2007 by Steril707