Jump to content
  • entries
    945
  • comments
    4,956
  • views
    1,220,835

A big, flickery mess?


Nathan Strum

6,203 views

So... back to one of the things on my "To-do" list - namely, "Stupid Game Ideas". (Pretend that was said in a loud, booming voice with lots of echo.)

 

...ideas... ...ideas... ...ideas...

 

These are the games I would make for the Atari 2600, if I had any clue about programming.

 

And trust me... I don't. I've read through a bunch of the 2600 "how-to" stuff, and even though I kind-of get some of the limitations of the 2600, and have a vague sense of what the hardware is doing, I have no knowledge of actual programming whatsoever.

 

Even batari Basic can't help me, since, of course, that requires knowledge of BASIC. I haven't had a class in BASIC since 1979 or '80, and then I just used it to make pictures and simple animation, rather than actual "programs". Funny how some things never change.

 

So, I have all of these pent-up ideas for 2600 games, and I figured I'd post them here, rather than cluttering up the homebrew forum with them.

 

Not that I'm saying people do that, mind you. :roll:

 

Anyway, the first game I was thinking of posting about was an original* idea I came up with 25 years ago. But I think I'll warm up on an arcade port, first.

 

*Original meaning completely derivative of other games, but with minor gameplay additions and changes.

 

So here then, are rough mockups for... Bosconian!

 

First, the arcade screenshots:

arc_bosco_1.gifarc_bosco_2.gif

 

Then the 2600 mockups:

26_bosco_1.gif26_bosco_2.gif

I wanted to keep the "space-turd" look of the original asteroids. ;)

 

The space stations would almost certainly need to be made out of the playfield, but that brings up a question... can you actually scroll the playfield in 8 directions? Yikes.

 

Another big problem with Bosconian is not only do you have to scroll the playfield around, but as you shoot pods off of the space stations (or completely blow it up), the playfield has to change in smaller chunks. Same thing (ideally) when the middle of the station opens to shoot a missile:

26_bosco_anim.gif

 

I did, however, come up with a possible solution for the radar screen. Now, usually in 2600 ports, they stick it at the bottom of the screen so it can be its own flicker-fest, separate from the game area. But I think you could actually lose the radar - mostly.

 

At the beginning of each wave, the layout of the stations could be shown on a separate screen, so you at least got an idea of which way to go. Then, on the main screen, there would be a flashing green indicator (playfield again?) along the border of the screen, that would lead you in the direction of the next nearest space station:

26_bosco_3.gif

 

Anytime there was a space station onscreen, the indicator would go away.

 

The full radar screen could also be brought up with either player 2's fire button, or a console switch. While not really necessary, it wouldn't be a bad idea.

 

Of course, this effectively loses the radar screen for tracking enemies, but it keeps the basic gameplay intact.

 

There are other problems, too.

 

Besides the whole scrolling playfield thing, is the fact that there tends to be a lot of enemies (and their shots) onscreen. Plus, the player's ship shoots both fore and aft at the same time (this is one of the things that makes Bosconian unique, so it would be a "must have").

 

And then, there's putting the score someplace. Minor detail. ;)

 

But just think how cool it would be to have the AtariVox shout, "Blast off!" at the beginning of the game. :D

 

Well, that's it for Bosconian (I didn't see much point in mocking up the title screen). So next time, maybe I'll post one of my original ideas.

 

And if I can get this posted in the next six minutes, I'll have made my "seven in a row", too. :)

28 Comments


Recommended Comments



Just realized something else... in order for the player to get the idea that space was "scrolling", there'd need to be something on screen the whole time, besides the player's ship. Even a couple of stars would do the trick.

Link to comment

Bosconian is one incredible well designed game. It's really a shame that it never got any real ports back in the day.

 

This is a really well-thought concept for a 2600 conversion. I always love to see the clever ideas "art"-people come up with to make it around the 2600 limitations. Like all the cool stuff retrofan was posting for a while.

 

Sometimes it really helps to have an artists vision of a 2600 version, as it may focus on totally different aspects than a programmers vision.

Link to comment

I seem to recall someone posting a mod for that online that allowed for eight-way movement.

 

Pretty stupid design on their part, though. Sounds like it would be completely unplayable. Bosconian just doesn't get the lovin' it deserves.

 

More thoughts on the 2600 mockup...

 

The green indicator radar-thing along the border could start small and grow larger (wider) as you approached a space station, so it would give you a sense of distance as well as direction.

 

In addition to a score (and number of player ships left) there should be an indicator showing how many space stations are left in the current level.

Link to comment
I seem to recall someone posting a mod for that online that allowed for eight-way movement.

 

Pretty stupid design on their part, though. Sounds like it would be completely unplayable. Bosconian just doesn't get the lovin' it deserves.

 

More thoughts on the 2600 mockup...

 

The green indicator radar-thing along the border could start small and grow larger (wider) as you approached a space station, so it would give you a sense of distance as well as direction.

 

In addition to a score (and number of player ships left) there should be an indicator showing how many space stations are left in the current level.

 

Pretty interesting mock-ups. It is worth pointing out, however, that there's already a Bosconian game of sorts available for the 2600... Mission 3000 A.D. by Bit Corporation. Then again, that game wasn't all that great, and I have no doubt that it could be improved upon by a homebrew game developer.

 

JR

Link to comment

Yeah, I tried out Mission 3000 A.D., and thought it was pretty bad. On the other hand, it shows that the basic concept works on the 2600 (although I think Time Pilot handles that play mechanic much better).

Link to comment

Looking at this again, I think the engine I built for 2600 Metroid could be adapted for this pretty easily. It supports a scrolling (striped) PF, two particles, a single non-flickered 1-line resolution* sprite, and multiple intelli-flickered 1-line resolution** other sprites.

 

The main problem would be the maps - how big are they? Plus the fact that since the space stations can be blown up would require some trickiness. But those are just details. :ponder:

 

*Multiple-color

**Single-color

Link to comment

I don't know how big the maps are, but I could figure it out. There's a map with all of the stations in a straight line, and it would be easy enough to extrapolate from that.

 

They're all the same size, but not all of them need to be that large. Some have all of the stations bunched up in a pretty small area.

 

Also, since all of the sprites must rotate (except the Cosmo mines and Asteroids), there wouldn't be much point in using multi-colored sprites. Except maybe for space station explosions.

Link to comment
I don't know how big the maps are, but I could figure it out. There's a map with all of the stations in a straight line, and it would be easy enough to extrapolate from that.

 

They're all the same size, but not all of them need to be that large. Some have all of the stations bunched up in a pretty small area.

 

Also, since all of the sprites must rotate (except the Cosmo mines and Asteroids), there wouldn't be much point in using multi-colored sprites. Except maybe for space station explosions.

Making all sprites a single color would probably allow three particles on the screen at once. And by

"how big" I mean how many screen-widths/heights.

Link to comment
And by "how big" I mean how many screen-widths/heights.

Right, but I meant some of the levels could probably be trimmed down, because they don't really utilize the full width and height of the entire level. A lot of it is just empty space.

 

Anyway, I took a bunch of screenshots of a number of levels, did some calculating, and the levels are 8 screens high by 4.571428571429 wide. I know that's a weird number but it works no matter how I measured it.

 

On one level, there are 8 space stations, evenly spaced across the width of the level. From center to center, they're 128 pixels apart, so the level is 128 x 8 = 1024 across. The player's screen area (not including radar and score display) is 224 x 224. So 1024 ÷ 224 = 4.571428571429. Also, on the radar, I estimated an area of 14 x 14 representing the player's screen area, and the overall radar view of the level is 112 high x 64 wide. 112 ÷ 14 = 8 and 64 ÷ 14 = 4.571428571429.

 

bosco-map-size.gif

 

I'm sure there was probably an easier way to figure that out, but there you go. :ponder:

Link to comment

Now...how many levels are there?

 

My Metroid engine has an overall map of 32x32 screens and, though that could be expanded, it would be nice if all the levels could fit into that. Assume 8 tall by 4 wide, then you could fit 32 levels in.

 

Also, the Metroid engine doesn't use the entire 160-pixel width; it excludes PF0. So the screen is effectively 128 pixels wide, by...I think 180 lines tall. Could go to 192 lines tall to make it ~square, though that would be iffy with RAM and then there's little room for anything else on the screen.

 

Other issues: PF blocks are 12 scanlines tall. Kinda rough for drawing a space-station. But at 15 rows, that requires 60 bytes of RAM. Could probably go to 20 rows (in 180 scanlines), which would make the PF "rows" 9 scanlines tall. Hm. An alternative...hmm. If only one space station was allowed onscreen at a time, then probably would work to have much finer resolution of the space stations, using striped PF; in fact any resolution you wanted, just limited to <20 rows for the space station graphics. In fact, scrap the Metroid memory map, most of that in this application would be empty space anyway, instead have 3 subkernels: one above the space-station, one that draws the space station (this would be the Metroid kernel), and one below the space station. Then for each level just store the global coords of the space stations.

Link to comment

I don't know how many levels there are, since I haven't been that good at Bosconian in awhile. :ponder:

 

But I seem to recall the layouts repeating after awhile. Also, different ROMs use different layouts, and in different orders, but there is some duplication across the ROMsets.

 

I doubt there are any more than 32 unique levels. Or more to the point, I doubt there would need to be.

 

I'll play around with drawing the stations at different PF resolutions, and see what they look like. One station per screen might be an acceptable compromise, provided enough other things (enemies) were going on at the same time. It would require spreading out some of the tighter levels, but those might be impossible to do on the 2600 anyway, with all of the missiles being fired. Two stations at a time would be better, though.

Link to comment
I don't know how many levels there are, since I haven't been that good at Bosconian in awhile. :ponder:

 

But I seem to recall the layouts repeating after awhile. Also, different ROMs use different layouts, and in different orders, but there is some duplication across the ROMsets.

 

I doubt there are any more than 32 unique levels. Or more to the point, I doubt there would need to be.

 

I'll play around with drawing the stations at different PF resolutions, and see what they look like. One station per screen might be an acceptable compromise, provided enough other things (enemies) were going on at the same time. It would require spreading out some of the tighter levels, but those might be impossible to do on the 2600 anyway, with all of the missiles being fired. Two stations at a time would be better, though.

With the scheme I've outlined, two stations in the same horizontal band could be accomodated simultaneously.

 

Also, as you do mockups at different resolutions, recall that they may have to be striped.

 

EDIT: Just replayed Bosconian in MAME to remind myself...the fact that the main ship is at a fixed position in the center of the screen helps a bunch also.

Link to comment

Striped as in every other scanline, or once every x scanlines?

 

I think I'm going to have to hook up my Stelladaptor for Bosconian. The keyboard just isn't cutting it in MacMAME.

Link to comment
Striped as in every other scanline, or once every x scanlines?

 

I think I'm going to have to hook up my Stelladaptor for Bosconian. The keyboard just isn't cutting it in MacMAME.

Well...striped every other scanline, probably. I'm doing it in Metroid and the kernel I'm thinking of wouldn't be much more complicated than that one, if at all.

Link to comment

Hi there!

 

So, I spent some quality time with this blog entry over the weekend and found me an internet cafe to type some lengthy reply. Please excuse all the typos I'll overlook - the keyboard here is in horrible condition... :D

 

The space stations would almost certainly need to be made out of the playfield, but that brings up a question... can you actually scroll the playfield in 8 directions? Yikes.

 

You can, but only very few games do. In fact, Thrust might actually be the only one.

 

Another big problem with Bosconian is not only do you have to scroll the playfield around, but as you shoot pods off of the space stations (or completely blow it up), the playfield has to change in smaller chunks. Same thing (ideally) when the middle of the station opens to shoot a missile:

26_bosco_anim.gif

 

Those stations being 11/12 PF pixels wide would always occupy 2/3 PF columns. At an estimated height of 20 lines, this would be 60 bytes in RAM - per station!

 

Anytime there was a space station onscreen, the indicator would go away.

 

This and all your other ideas regarding the "radar" problem are brilliant! :D

 

Of course, this effectively loses the radar screen for tracking enemies, but it keeps the basic gameplay intact.

 

The only enemies the radar screen seems to track are the "formation attacks", or? Talking of which, here the title of this entry, "A big, flickery mess" hits the nail on the head, absolutely :)

 

Besides the whole scrolling playfield thing, is the fact that there tends to be a lot of enemies (and their shots) onscreen. Plus, the player's ship shoots both fore and aft at the same time (this is one of the things that makes Bosconian unique, so it would be a "must have").

 

With "normal" flicker, there can be two player and two enemy shots on the screen, using a missile for each couple.

 

Just realized something else... in order for the player to get the idea that space was "scrolling", there'd need to be something on screen the whole time, besides the player's ship. Even a couple of stars would do the trick.

 

One could use the ball for some "Earth Dies Screaming" background. Major problem though: Either the starfield jitters synced with the stations, which'd increase the amount of jittery objects, or don't. But then it'd look weird as well, having the stars fine scroll and the stations "jump" after them every 4th pixel :)

 

Also, since all of the sprites must rotate (except the Cosmo mines and Asteroids), there wouldn't be much point in using multi-colored sprites. Except maybe for space station explosions.

 

The missiles only go 4 ways I think.

Since there's three similar triangle shaped enemies, it'd be interesting, wether they can be rotated in ways that they still look ID'able.

 

If only one space station was allowed onscreen at a time, then probably would work to have much finer resolution of the space stations, using striped PF; in fact any resolution you wanted, just limited to

 

This is an excellent idea. Expanding a bit on this, you could then probably even have the stations in all their states created from ROM. If you cut them into three sections top/middle/bottom, then there ain't too many combinations of shapes, 2³ at max per stripe :)

 

EDIT: Just replayed Bosconian in MAME to remind myself...the fact that the main ship is at a fixed position in the center of the screen helps a bunch also.

 

While this helps the kernel, it seems a major KO criteria for this port: With a fixed ship, you can't use "delayed scrolling", i.e for every little move of your ship, you're jumping everything 4 pixels around, which is not really working for Bosconian :)

 

Personally, I think I won't try converting Bosconian myself. It seems it requires a lot of work already, just to get to a point where you can tell wether it'll work out or not.

Link to comment

Any problem with shrinking the space stations slightly, so as to be 32 'raw' pixels wide?

----------------
----------------
----##----##----
---####--####---
---####--####---
----##----##----
-##----##----##-
####--####--####
####--####--####
-##----##----##-
----##----##----
---####--####---
---####--####---
----##----##----
----------------
----------------

-------##-------
------####------
------####------
---##--##--##---
--####----####--
--####----####--
---##--##--##---
------####------
------####------
---##--##--##---
--####----####--
--####----####--
---##--##--##---
------####------
------####------
-------##-------

 

Use a 4x sprite, shifted left/right 2px on selected scan lines. Each character above is 2px and each row is 4 scan lines.

Link to comment

Hmm... that could work.

 

(Time passes)

 

Something like these:

 

spritestation_1.gif

 

spritestation_2.gif

 

Same, but with "shading":

 

spritestation_3.gif

 

spritestation_4.gif

 

This would make it easier (presumably) to shoot the spheres off the space stations, too. Maybe. But since you can shoot each one off individually... that's quite a few possible combinations per station. (Math and I never got along very well. :) )

 

But... I didn't think you could have multiple copies of a widened sprite... so you couldn't have more than one station on a horizontal row at a time (without flickering... and the game would already be flickering to beat the band anyway). But given that the stations are quite a bit smaller this way, that might not be such a big deal.

 

2600-bosco-2.gif

Link to comment
Same, but with "shading":

 

The shading looks very nice, though managing to get it done within kernel time constraints might be hard. Maybe not too bad, though, if you use a 2LK and "decide" upon both scan lines at the same time.

 

This would make it easier (presumably) to shoot the spheres off the space stations, too. Maybe. But since you can shoot each one off individually... that's quite a few possible combinations per station. (Math and I never got along very well. :) )

 

There would be 64 different ways to do each space station, but splitting each station into two or three pieces shouldn't be a problem. For one style of station there would be four tops, four middles, and four bottoms; for the other style there would be eight top halves and eight bottom halves.

 

But... I didn't think you could have multiple copies of a widened sprite... so you couldn't have more than one station on a horizontal row at a time (without flickering... and the game would already be flickering to beat the band anyway). But given that the stations are quite a bit smaller this way, that might not be such a big deal.

 

Vertical separation for the stations shouldn't be a problem I wouldn't think.

 

How many of what sorts of things does the game need on screen? I would think one could manage 30Hz flicker with one frame having stations, the player ship, and up to three shots; the other screen having two sets of enemies with different movement restrictions along with three shots.

Link to comment
So, I spent some quality time with this blog entry over the weekend and found me an internet cafe to type some lengthy reply. Please excuse all the typos I'll overlook - the keyboard here is in horrible condition... :D

It's all that spilled coffee.

 

This and all your other ideas regarding the "radar" problem are brilliant! :D

Thanks! It's always interesting to try and figure out ways around the 2600's limitations (although I'm not doing it from a programming standpoint - I tend to do it from a strictly visual approach).

 

The only enemies the radar screen seems to track are the "formation attacks", or?

That's correct - only the formation attacks are tracked. I suppose it might be possible to use the same radar idea for those, but use a red indicator instead. The trick then is, if the playfield is in use for the space station radar, what to use for the attack formation radar? Maybe just switch between the two, every half second or so (a blink, rather than a flicker).

 

Talking of which, here the title of this entry, "A big, flickery mess" hits the nail on the head, absolutely :)

Yep. It'd give Juno First a run for its money in the flicker department. :D

 

The missiles only go 4 ways I think.

Since there's three similar triangle shaped enemies, it'd be interesting, wether they can be rotated in ways that they still look ID'able.

The missiles go 8 ways, when in attack formation. When launched from the station, they go 4.

 

I don't think making the sprites look unique would be a problem. The fact they use different colors also helps.

 

One could use the ball for some "Earth Dies Screaming" background.

That looks pretty good. The stars and space stations would need to move at different speeds though, to get that parallax-effect.

 

Major problem though: Either the starfield jitters synced with the stations, which'd increase the amount of jittery objects, or don't. But then it'd look weird as well, having the stars fine scroll and the stations "jump" after them every 4th pixel :)
While this helps the kernel, it seems a major KO criteria for this port: With a fixed ship, you can't use "delayed scrolling", i.e for every little move of your ship, you're jumping everything 4 pixels around, which is not really working for Bosconian :)

Supercat's idea for using a big ol' sprite for the space stations would take care of these though, wouldn't it?

 

Personally, I think I won't try converting Bosconian myself. It seems it requires a lot of work already, just to get to a point where you can tell wether it'll work out or not.

Well... maybe someone will take it on, someday. If nothing else, it makes for an interesting discussion. :)

Link to comment
How many of what sorts of things does the game need on screen?

Lots.

 

There is your ship, up to three to five other ships at any given time (typically), mines and asteroids (anywhere from 0 to 10 or more - but they don't move), and the attack formations which have five ships in them, (but there can only be one of those at a time). Space Stations can be quite packed on screen, depending on the level. One ROMset has a level where you're entirely surrounded, where you see parts of at eight stations at once. Then, there are the enemy shots (bullets), although they only come from the space stations, and it looks like each station can only fire off four at once. (The plus side is, none of the enemy ships fire at you.) And finally, you have the large missiles which are launched out of the center of each space station.

 

This is the worst-case scenario for space stations:

bosc0002.gif

 

At least, I don't recall there being another level with them more tightly packed. Mostly though, you might see three on screen at once.

 

Obviously, there would need to be some scaling back. The attack formations would likely need to be pared down to three ships, instead of five. Space station layouts would have some limitations, the number of bullets fired at once scaled back, and so on.

 

I suppose the question is - could the game be made without stripping out so much that it becomes something else?

Link to comment

FYI Skeleton+ uses the ball at the edge of the screen as a skeleton direction finder.

 

I'd start with trying to get one space station, the player, one attack formation and some shots on the screen at once. Hmmm... Since the player is fixed in the center, maybe use the playfield for that sprite. Blocky as hell, but that would free up one player sprite.

 

In fact . . .

playfield - player ship & station direction indicator(s)

player 0 sprite - space station (4x wide)

player 1 sprite - attack formation (tripled, like Combat)

ball - space station shot

missiles - player shots (max 2?)

 

I don't think a background is really necessary as long as there isn't too much distance between the space stations.

Link to comment
Major problem though: Either the starfield jitters synced with the stations, which'd increase the amount of jittery objects, or don't. But then it'd look weird as well, having the stars fine scroll and the stations "jump" after them every 4th pixel :)
While this helps the kernel, it seems a major KO criteria for this port: With a fixed ship, you can't use "delayed scrolling", i.e for every little move of your ship, you're jumping everything 4 pixels around, which is not really working for Bosconian :)
Supercat's idea for using a big ol' sprite for the space stations would take care of these though, wouldn't it?

 

I admit that I dismissed that thought too early - I never considered that you could manage to make the stations still looking that good.

 

The negatives are that it adds to the flicker and that it kinda ruins the proportions: A station in the Arcade version occupies 50% of the screen horizontally, while with the sprite solution it comes down to 25%.

 

The positives are, that this IMO was indeed a way to go that make a playable(!) game and that it nullifies all the horrible Playfield overhead and also helps the RAM usage a lot.

 

Actually it's going Mission 3000 then though. Even its idea of turning the scenery 90° ain't all bad and it seems to work somehow. One could fix quite some things from Mission 3000, but the flicker it already has, gives a good idea of things to come :)

 

Maybe it'd even make sense to start with (code-)hacking Mission 3000. Fix the starfield for the start and try to add the 32 pixel stations.

Link to comment
Maybe it'd even make sense to start with (code-)hacking Mission 3000.

 

BTW: Mission 3000 seems to have only 6 levels ;)

Link to comment

Guest
Add a comment...

×   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...