Ok, how about Killer Bees for the 2600/7800?

[courtesi]

One of my favorite games from the Magnavox Odyssey 2 camp is Killer Bees. What I was thinking was kind of a weird hybrid port to the 2600/7800.

 

If you play the game on an 2600 you will get the original version of Killer Bees. If you play it on the 7800 you will get the Odyssey 3/Videopac 7400 version with the enhanced background graphics that came with it. I know the units don't have a speech synthesizer - but it's not like that enhanced the original game anyway.

 

A good idea? or no?

 

PS: As a bonus - Atari users will be able to use a trackball with the game. There was a trackball for the Odyssey but only as a prototype. Those who have tried the game with the trackball say it's well suited for it.

Edited August 5, 2005 by courtesi

[Cybergoth]

Hi there!

 

A good idea?  or no?

 

I think a very good Killer Bees conversion could be done with a good sprite multiplexing engine.

 

Greetings,

Manuel

[supercat]

One of my favorite games from the Magnavox Odyssey 2 camp is Killer Bees.  What I was thinking was kind of a weird hybrid port to the 2600/7800.

 

I love the game, but I really don't know how one could effectively manage the animation of the beebots and the swarms, except perhaps by using a high-resolution flickerscreen on either the SuperCharger or a RAM+ cart. If one used shape rather than color to distinguish the red and blue beebots, a venetian-blind flickerscreen could probably be used for the beebots and enemy swarms. The player's swarm could be highlighted visually with the Ball if the proper transparency tricks were employed. This would not work out well visually when the player's swarm is overlapped by an enemy swarm, but that would probably be a comparatively small problem.

 

[Note: the screen would be drawn in SCORE mode, with a reflected playfield, and with COLUP1=COLUP2=black, COLUPF=white, and COLUBK=alternating enemy and beebot colors. The screen would be drawn Stella-Sketch/Suicide-Mission style, but with both missiles set to 8 pixels wide and alternating positions with the players. All graphics would be drawn 'inverted' [an 'on' pixel=black, and 'off' pixel=color]. The Ball would be 8 pixels wide and would highlight the player's swarm.

 

Probably a tough game to pull off, but if the Hires Helper features on my RAM cart work as I hope they will, it might not be too bad.

Edited August 5, 2005 by supercat

[courtesi]

*sigh*

 

Clearly I've been giving the 2600 way too much credit.

 

Ok, scratch the 2600 port - how about a 7800 version?

[supercat]

Clearly I've been giving the 2600 way too much credit.

 

Ok, scratch the 2600 port - how about a 7800 version?

905388[/snapback]

 

The 2600 might be able to do a decent job if it had expanded memory. The 7800 could almost certainly do a good job without too much trouble.

[Cybergoth]

Hi there!

 

supercat, sorry, I don't get you. Here's a screenshot of Killer Bees:

 

 

As far as I can see, that's all just a bunch of 8x8 sprites. Again, a good sprite multiplexer is all it takes. To animate the bee swarms, just have them read from RAM, that's only 8 byte for each. This can be converted 1:1 in a regular 4K cartridge. It even has a reflected playflied for easy repositiongs.

 

Greetings,

Manuel

[Thomas Jentzsch]

Looks very doable to me too.

[supercat]

Again, a good sprite multiplexer is all it takes.

 

The problem is that it's quite common to have more than four objects in a horizontal line (the limit for 30Hz flicker). If some of the objects are tombstones, the flicker could persist until the end of the level. Maybe it wouldn't be too bad, but I'd tend to be leery of a game mechanic with that many freely-movable objects. It's been awhile since I played the game, but I think the later levels had eight or twelve beebots--rather crowded for a 2600 screen.

[+kisrael]

The screenshot looks interesting, could someone summarize the gameplay?

[Cybergoth]

Hi there!

 

The problem is that it's quite common to have more than four objects in a horizontal line (the limit for 30Hz flicker).

 

Hm... how did the Odyssey do more than 4 sprites in a row? Flicker as well?

 

Here's an old demonstation of my Star Fire engine (which has been improved since then): Star Fire Engine

(Use the fire button to move the objects)

 

Note that this is using both sprites for one object. For a game like Killer Bees with it's small solo sprites, the flicker would be _much_ less. I'd think it could handle the required 12 sprites easily.

 

Greetings,

Manuel

[supercat]

Hm... how did the Odyssey do more than 4 sprites in a row? Flicker as well?

 

The Oddysey had four 8x8 sprites, twelve other 'single' objects, and four 'quad' objects. Other than the sprites, the objects' shapes had to be taken from a 512-byte ROM; each quad object would show four such shapes side-by-side. The Oddysey has no restrictions on object placement (other than requiring the four parts of a quad-object to be adjacent); one could show all 32 objects on the same scan line without flicker if one were so inclined (they'd overlap, of course).

 

One of the things Killer Bees did which I've not seen any other game do (though I'm sure others did) is modify objects' shape/color registers mid-frame. A Beebot is part of an "8" on top of part of a "walking man"; a tombstone is part of an "A" on top of part of an "M". Makes for a much more interesting game.

 

I believe Killer Bees uses at least 12 if not all 16 of the non-quad objects in the central area of the playing field. Sixteen freely-movable objects is really pushing the limits of the 2600. Maybe it could be done somehow; I would tend to think excessive flicker would be unavoidable.

[+batari]

Hi there!

 

The problem is that it's quite common to have more than four objects in a horizontal line (the limit for 30Hz flicker).

 

Hm... how did the Odyssey do more than 4 sprites in a row? Flicker as well?

 

Here's an old demonstation of my Star Fire engine (which has been improved since then): Star Fire Engine

(Use the fire button to move the objects)

 

Note that this is using both sprites for one object. For a game like Killer Bees with it's small solo sprites, the flicker would be _much_ less. I'd think it could handle the required 12 sprites easily.

 

Greetings,

Manuel

905644[/snapback]

Is the source for this available?

 

If so, and with your permission, I'd like to integrate some of the code in this engine into a bB kernel (with two separate sprites instead of one 16-wide sprite) in the future... Not any time soon, but maybe in a couple of months. Perhaps then someone could take on Killer Bees with bB.

 

Thanks!

[Cybergoth]

Hi there!

 

If so, and with your permission, I'd like to integrate some of the code in this engine into a bB kernel (with two separate sprites instead of one 16-wide sprite) in the future... Not any time soon, but maybe in a couple of months.  Perhaps then someone could take on Killer Bees with bB.

 

Ok, I did some browsing in the [stella] archives and found a version of the engine (with source) is available that might be a good start:

 

http://www.biglist.com/lists/stella/archiv...4/msg00010.html

 

The binary there does 16 totally independent objects, by multiplexing 1 sprite. If you manage to tweak it to make some use of both sprites, it should extremely reduce flicker. Again, I think I improved the technique in details until the final Star Fire version, but this should be a good point to get a stripped to the basics version.

 

 

Greetings,

Manuel

[ZylonBane]

If I might suggest a possibly very ugly but relatively flicker-free alternative-- you could theoretically use playfield graphics to represent the Beebots. The animation would look really chunky at low speeds, but the faster-moving 'bots would look fine. If you'll take a moment to pop open the mockup I've attached.....

 

Okay, what we have here is a slightly shrunk version of the O2 play arena. At the top-right is a standard 6-digit score, moved up to not overlap the arena. The left and right 8 playfield pixels are mirror images, allowing the first bytes to be static in a mirrored asymmetrical playfield configuration (I think). The playfield itself is colored in stripes of blue, red, and white. Within the dynamic playfield area, the 'bots would move on a 12x8 grid. Tombstones would also be represented on this grid. The three enemy swarms and one player swarm would be the two players on a fixed 30-hz flicker (thus no midscreen positioning required). The zapper markers on the left and right could be the missiles, or a multiplexed ball.

 

You know what? Nevermind. This would be ugly as hell. It'd be easier to just program the Beebot AI to reverse direction if its new position would cause it to increase flicker beyond an acceptable threshold.

 

 

Incidentally, there's an interview with the author of Killer Bees here:

http://www.dieterkoenig.at/ccc/po/s_po_killerbeese.htm

Edited August 8, 2005 by ZylonBane

[supercat]

You know what? Nevermind. This would be ugly as hell. It'd be easier to just program the Beebot AI to reverse direction if its new position would cause it to increase flicker beyond an acceptable threshold.

 

Using PF graphics might be a reasonable approach, though I don't know how well a non-RAM-expanded 2600 would be able to handle it. If you limitted the beebots to moving on a coarse grid, it might work but that probably would be too ugly. If they were allowed to move on a grid that was twice as fine (i.e. one playfield pixel horizontally or eight scan lines vertically) it might not be too bad. Actually, if the beebots were three playfield pixels wide things might turn out looking somewhat reasonable. Not sure how everything could get managed by a kernel real-time without extra RAM, but extra RAM may be available in the near future.

[supercat]

Upon further consideration, I like the idea of making the beebots three PFpixels wide by three 'blocks' high, where each block is six or eight scan lines (drawn on a per-scan-line basis). If there were two swarms of enemy bees, they could be drawn using one player and one missile while they human-controlled swarm was drawn using the other player. Using the other missile for the other computer-controlled swarm might be possible, but it would share its color with the player.

 

Four enemy swarms could be handled using 30hz flicker on those swarms; the human player would not flicker, since flickering would make collision-detection difficult.

 

I don't see any way the game could work well without extra RAM, but with extra RAM I would think it quite feasible.

 

If anyone wants to do a mockup, I'd suggest making the playing area 32pfpixels wide by 120 or 160 scan lines tall (the former would leave more CPU time available for running the game).

Edited August 8, 2005 by supercat

[Feralstorm]

I don't see much reason why this game couldn't be done with players/missiles/ball as long as people could accept two things: flicker and some minor compromises in the gameplay behavior. (you know, like pretty much every Atari 2600 port ever made)

 

My problem is, having never played the Odyssey game, I don't know the details of the gameplay. A few odd thoughts for a 2600 version are:

 

bee swarms might be doable with ball/missiles, by using one 'bee' per scanline, then repositioning the ball/missile semi-randomly for the next 'bee'. Might be rough on CPU time with a bunch of other moving objects to keep track of though.

 

Bee-bots should look like the robots from Berzerk (with antennae )

 

Personally, I think a lot is possible given the majesty that is 2600 Dig Dug. That has a ton of player objects running around independently (at least 8 or more) which could all end up on the same scanline - and the flicker ain't too bad either.

 

(and assymetrical changeable playfield too)

[ZylonBane]

My problem is, having never played the Odyssey game, I don't know the details of the gameplay.

http://o2em.sourceforge.net/

[courtesi]

If anyone makes a quality homebrew of this title for cartridge format I will be the first in line to buy a copy

 

The thing is, you really have to see it in action. It is really smoooooooth.

[supercat]

Personally, I think a lot is possible given the majesty that is 2600 Dig Dug. That has a ton of player objects running around independently (at least 8 or more) which could all end up on the same scanline - and the flicker ain't too bad either.

 

Dig Dug uses an expanded-RAM cartridge to achieve its magic. I don't think a homebrewer would be able to do so well with Killer Bees until expanded RAM is available for them, too.

[retrocon]

Dig Dug uses an expanded-RAM cartridge to achieve its magic.  I don't think a homebrewer would be able to do so well with Killer Bees until expanded RAM is available for them, too.

 

Do the emulators such as Z26 support expanded-RAM? If so, then 80% of the market is covered right there. No reason not to build it knowing that expanded-ram carts will be available in a year or three.

[supercat]

Do the emulators such as Z26 support expanded-RAM? If so, then 80% of the market is covered right there. No reason not to build it knowing that expanded-ram carts will be available in a year or three.

907934[/snapback]

 

I think the until developers actually get their hands on real affordable RAM-plus cartridges, they'll be reluctant to design for them. I think with a RAM+ cart, though, Killer Bees could come out pretty well. The enemy swarms would flicker full-time at 30hz (unless you played on "easy" mode with two enemy swarms instead of four) but everything else would be flicker-free. The mockup below is 163 scan lines; it doesn't include score, but everything in the mockup should be doable on a RAM-expanded 2600 exactly as shown.

 

BTW, the dull red bars mark the location of the ROSHA zapper.

[ZylonBane]

As I suspected, three-playfield-pixel bots look absolutely horrible. A port of Killer Bees that looked like that would just give O2 owners something to feel smug about.

 

Using the playfield for the walls and headstones, players for the bots, and missiles for the swarms is probably the best-looking approach. It would have to be an insanely tight kernel to pull it all off though.

Edited August 10, 2005 by ZylonBane

[retrocon]

As I suspected, three-playfield-pixel bots look absolutely horrible. A port of Killer Bees that looked like that would just give O2 owners something to feel smug about.

908385[/snapback]

 

It seem like they are just too big compared to the size of the playfield. There would be no place for them to roam...

[doug0909]

Hey I was the first one to suggest a port of killer bees in my post about ports of a bunch of the great O2 games, including KC Munchkin and Pick Axe Pete...

 

But I think you are barking up the wrong tree with the 2600 and 7800. The 2600 will have difficulty with the flicker issue, and both systems use digital joysticks. The 2600 has a trackball, but it's digital.

 

Killer Bees would be the PERFECT game for a mouse or real trackball with it's open playfield. That's why I'm amazed noone's done a remake for the PC. As for Atari systems, the 5200, with the killer analog trackball, would be best....

Edited September 7, 2005 by doug0909