Bear Arms (7800) Brainstorming

[Jess Ragan]

So! I was dinking around with the recently released 7800 BASIC compiler, and with a lot of help from its creator RevEng, created a rudimentary game engine. You can download it from the link below if you'd like to give it a spin. It's an omni-directional shooter, with the character in the center of the screen running with the left joystick and aiming a gun with the right. There's not much to do at the moment- the character's gun doesn't fire and running outside the boundaries of the screen will likely have screwy results- but you should be able to get a general idea of what I'd like to do with it. (If it goes that far. We'll see!)

 

However, if you'll permit me, I'd like to go into specifics. The game I'm planning is tentatively titled Bear Arms, and it's a fixed screen shoot 'em up that borrows from a variety of other games. The core gameplay is similar to Robotron: 2084, but the finished game will take the timer and bonus prizes from Zoo Keeper, and the varied enemy patterns of Megamania. The object is not to clear the screen of enemies (they respawn) but rather just to survive. Fruits appear on the edges of the playfield at fixed intervals... grabbing one awards you points and doubles the value of the next fruit. However, this also triggers a "bear trap," an additional hazard that temporarily makes life more difficult for the player. It could be steel teeth embedded in the floor, or a pair of arrows that sail across the screen, or walls that block your shots... I haven't decided yet, but you get you the picture.

 

NOT collecting fruit has its own hazards. The multiplier drops back to one, and if you miss two fruits in a row, you'll spark the wrath of the invincible "Indestructicon." This threat can't be destroyed (duh) and continues to chase the player until they grab a fruit or get chopped into bear-bits by the Indestructicon's bladed ring. This character is the rough equivalent of Evil Otto from Berzerk, but takes just as much inspiration from Sinistar and those annoying Phantos from Super Mario Bros. 2.

 

Each stage has its own cannon fodder enemy, which can be destroyed with a bullet but respawn elsewhere in the playfield. The first stage has "Plimptonites," stray chunks of the dead political commentator and second-string game console advocate, which mindlessly wander around the screen in the hopes of boring the player to death. Other stages will have enemies that chase the player, move back and forth like Space Invaders, or bounce around the screen like Solar Plexus's artificial sun. They're worth a small amount of points, but the later, more difficult enemies have a higher bounty than the earlier ones.

 

I should probably mention the lead character. That's Byron J. Lennox, a bear cub I've been drawing for twenty years now. He's sort of a Bart Simpson/Baby Herman type, precocious and obnoxious in equal measure. (Yes, that's a diaper. Don't ask.) He was inspired in large part by several cartoon characters, but Bentley Bear from Crystal Castles also factors into his design. I haven't yet decided WHY he's in this predicament, but this is an old-school arcade game! Who needs an explanation?

 

One last thing: I'm worried that the game will reach beyond the scope of 7800 BASIC and my own coding abilities. I considered adding bosses, but I don't think I'll be able to cram them into 48K of space. Likewise, the border around the screen in the mock up will take up too much character data (forty characters by my estimation) and will likely have to be replaced with something more humble. I liked the thought of walls that tower over the playfield, but they not only take up too much space on the cartridge, they swallow up too much onscreen real estate. I'm also going to have to find out how many sprites I can realistically have onscreen while keeping the game running at a brisk clip. Byron, three shots, and six enemies brings the total up to ten, which is half of what 7800 BASIC can handle... but when you add in AI and game logic, it's probably not realistic to expect to have all twenty sprites active at once. I guess the only way I'll know for sure is when the game gets to that point.

omnid.zip

[RevEng]

Fun concept! I'm taking the same approach with Salvo - make the game similar to a classic, and then try to distinguish it from the original.

 

There are 2 sprite limits in 7800basic; there's a per-zone limit of 20, and an overall limit of about 24 due to the amount of available off-screen time, which is when the screen needs to be updated.

 

If you take measures to avoid sprites bunching up, which is probably a good idea anyway from a game-play perspective, the first limit isn't an issue. You can get close to that second 24 sprite limit if you separate your AI and other game logic from the sprite display routines, and keep the sprite display routines as simple as possible. That way the game logic runs during the visible screen, and doesn't take away time from the sprite display routine.

 

Even if you don't take measures to avoid the sprites bunching up, 20 sprites isn't difficult to achieve with separated game logic and sprite display logic. Salvo has about 18 simultaneous sprites right now, and more planned.

 

Keep on running with this excellent concept, man!

Edited April 26, 2014 by RevEng

[Jess Ragan]

Progress on the game is at a glacial pace but I did manage to put together a font; something that's got character but should be easily readable. Any thoughts?

 

Also (and this is probably a better question for the 7800 BASIC forum; I'll probably ask there as well if it's not answered here), is it possible to use different colors for the same character set? You know, if I wanted to use white text at the top of the screen and red text at the bottom, and a purple border in the center, would that be doable?

[Jess Ragan]

Er, here's the font. Doy!

[RevEng]

[...] is it possible to use different colors for the same character set? You know, if I wanted to use white text at the top of the screen and red text at the bottom, and a purple border in the center, would that be doable?

Yup, it's possible. You'd need to plot the text in 3 different palettes to achieve that.

[Jess Ragan]

Sorry it's been a while. I've been hugely undisciplined about developing this game; that's in contrast to Gorf which took two months to finish, and Solar Plexus which took closer to two weeks. I really need to push myself harder, because as it is crap's just not getting done.

 

Maybe a plan of attack is in order. Let's go with this:

 

* DIM all necessary variables into more descriptive names, for clarity's sake

* Create a preliminary character set and add a border to the playfield

* Set internal boundaries so Byron can't move past them

* Create sprites, AI, variables, et al for four bullets and allow Byron to fire

* Get five enemies onscreen and make them move around

* Introduce rudimentary collision detection and routines to delay the appearance of recently destroyed enemies

* Introduce rudimentary scoring system

 

After that, I can tackle some of the meat of the game, like fruit prizes, the timer at the top of the screen, new AI routines for enemies, etc. After I get all THAT squared away, it'll be closer to a game than a simple tech demo, and I can advance to the window dressing (titles, introductory text, worrying like hell I'll run out of memory, etc.).

[Jess Ragan]

Progress is being made on the game, albeit slowly. Now there are boundaries for Byron and some early coding has been done on the bullets. A single bullet appears on the screen, aimed in the same direction as Byron's gun. It doesn't move yet, but there are variables set for four bullets and I've written code for bullet behavior and placement... it's just been REMmed out for the moment. You can download the alpha below, should you be so inclined.

 

Anyway, if there's continued interest in the project, I'd like to talk about enemy patterns. As I've mentioned earlier, the game isn't about wiping out a screen full of enemies, but just trying to survive. For that reason I was thinking the enemies should act less like the ones in other omni-directional shooters (Robotron, Smash TV) and more like the ones in fixed screen shooters like Megamania and Astro Blaster, with set patterns that happen independently of player movement. Some stages will have chasers, but others will have enemies that bounce around the edges of the screen, move randomly, or dart about unpredictably. They're behaviors that will keep players sweating and distract them from the fruit prizes that appear on the screen edges. If you can think of enemies in past games that would work well in this context, let me know! It'll be really helpful for building the game.

 

Also, I don't know what I'm going to do about sound. I know precious little about sound engineering; when I made GORF the Game Boy Advance and its two digitized sound channels did most of the work for me. I would enter a command like playsound titlemusic.wav, and it would handle that independently, without any need for me to step in and program single notes. I doubt I'll have the same luxury here. Also, I do wonder if I should use POKEY or just stick with the standard (awful) 7800 sound processor. It would deliver the raw sound effects of a dual stick shooter well enough, but would be wholly inadequate for any music I may want to include. Any suggestions here would be greatly appreciated.

 

I'd like to discuss this stuff at length with anyone who's looking forward to the game. Okay, the next build should have moving bullets. Stay tuned!

bear_arms_alpha_5_23.a78

[+Random Terrain]

Also, I don't know what I'm going to do about sound. I know precious little about sound engineering; when I made GORF the Game Boy Advance and its two digitized sound channels did most of the work for me. I would enter a command like playsound titlemusic.wav, and it would handle that independently, without any need for me to step in and program single notes. I doubt I'll have the same luxury here. Also, I do wonder if I should use POKEY or just stick with the standard (awful) 7800 sound processor. It would deliver the raw sound effects of a dual stick shooter well enough, but would be wholly inadequate for any music I may want to include. Any suggestions here would be greatly appreciated.

 

The VbB Music and Sound Editor allows you to play with the sounds until you get something you're happy with. It lets you go beyond the 'canned' sound effects you've heard in a lot of games and 'weave' a sound effect that you've never exactly heard before in an Atari 2600/7800 game. You can also hunt down sounds with Tone Toy 2008 and shape/alter those sounds using the VbB Music and Sound Editor. (Tone Toy 2008 is called "Sound Generator" under the View menu in VbB.)

 

In case it might help, there are Sound Examples Without Data and Sound Examples Using Data on the bB page.

[+Random Terrain]

This Atari 2600 example program has around 19 sound effects that don't sound too bad:

 

atariage.com/forums/topic/211497-chipoff-breakout-style-example-program/