Fort Apocalypse

Game story: While swimming the loch, Nesi, daughter of Nessie, finds out that humans have started a war. Nesi must eat leafy greens off the lake floor and come up for air while avoiding submarines, nuclear blasts, and a warship dropping depth charges. How to play: Left joystick controls Nesi, who can eat greens off the lake floor for points, come up for breath to restore life, and who must attempt to avoid danger. Nesi wants to get as many points as possible before losing all lives. Right joystick controls the ship that continuously drops depth charges/shoots and has light control over the up and down control of the submaries. The player controlling the right joystick wants to limit Nesi's points. If no second player is available the single player can play Nesi and avoid subs. nesi_0.2.bas.bin nesi_0.2.bas

Zip line sounds cool! Bring on Quickclaw, the cowardly mountain lion! Yeah, Harry'd have to be an Olympic broad jumper and high jumper to get that liana. Here's a pic of a bird in the Colecovision Pitfall (which I was unaware of until I just searched for Pitfall bird):

If the goal is 1:1 with original Pitfall liana (vine), it had a lot of different positions. The overall complexity of it may not be worth it. Instead, you could have a bird that flies back and forth over the lake and you have to jump up to catch the bird, then you could have a single sprite for the bird and Harry to get rid of flicker and the sprite would have it's own coordinates so you wouldn't need additional variables. If you want a vine that stretches the pond or pit though, you could either do a single sprite with NUSIZ to make it bigger, but that may be ugly (I tried it), or you can use multiple sprites and have a lot of flicker.

@rsiddall Here's a (DPC+ 32K) demo of a more Jungle King-ish vine with Superman and Lois (from idea here). Superman doesn't need the vine currently, as he can fly, but whatever. (Watch out for E.T. in that hole.) superman_jungle_dev.bas.bin superman_jungle_dev.bas

This may not look exactly like Pitfall, but you could have a single tall sprite whose x position moved back and forth under the canopy of the jungle trees. In a decompiled and commented version of Pitfall, the swinging liana is made of three parts. I don't know if that helps for bB, though. When working locally on Moonshoot, I got sprites of a certain length to not flicker visibly when there was vertical space between them, but I ended up going for longer overlapping sprites and living with the flicker for now. I might still change it further, idk.

This is so cool, I thought it'd be neat to have a thread to post all the song demos from the Atari Video Music (Model C240), with YT and other videos starting right when the song starts for your enjoyment. Here are some. WARNING: These contain flashing lights which may affect some viewers! Atari Video Music Demo on Wikipedia: https://upload.wikimedia.org/wikipedia/commons/f/f8/Atari_Video_Music.webm Original Atari Video Music set to start at the countryish acoustic song: This has a little speech over it and isn't a full song: This was posted at least once before recently, but the YT of Rees' clone set to start at the song:

Release 0.4: Improved readability of game over screen. moonshoot_0.4.bas.bin moonshoot_0.4.bas

Release 0.3: Additional improvements to rails. Changes in placement to avoid stuck situation and to make gameplay involve basic skill. Still needs some work, but action is closer to reality, even if rails are not close and ball not rolling backwards. Ball no longer gets stuck at bottom for a while. moonshoot_0.3.bas.bin moonshoot_0.3.bas

@glurk tried reaching out to anyone listed here? They may not be following the group closely but might have a few minutes to help, possibly. It also wouldn't hurt to tag the post with "disassembly", "disassemble", "wabbit", and/or whatever else might attract folks. Tags look annoying, but it seems like I've gotten more views on pages after adding them, as long as you add appropriate ones, and not too many.

@splendidnut I looked at the documentation and at the congo.c example and have some comments and a question: The asm defining functionality is nice! Love the C code that makes things look easy, like: if (canMove || (playerState == SPR_STATE_CLIMBING)) { if (joyInput & JOY_RIGHT) { newPlayerX++ explorer.state &= SPR_FACE_RIGHT } else if (joyInput & JOY_LEFT) { if (newPlayerX > 0) newPlayerX-- explorer.state |= SPR_FACE_LEFT } if (joyInput & JOY_UP) { if (newPlayerY > 0) newPlayerY-- explorer.state |= SPR_FACE_LEFT } else if (joyInput & JOY_DOWN) { newPlayerY++ explorer.state &= SPR_FACE_RIGHT } } One of the reasons I like bB is that the ratio of art (playfield and sprite definitions) to code can be so high with low overall complexity for a fun game. Looking at congo.c- maybe about 1/4-1/3 of the lines I see in my editor are for art; that's impressive! Is there a tool that could be used to help visualize and create the playfield and player sprites? (My eyes glaze over arrays of hex, and comments don't help unless I can edit them and re-run something to update the hex.) It would be helpful to have information on the basics of Neolithic specifically for 2600 game developers, like: defining colors, sprite definitions, collisions, etc., like a starting point for what could become similar to RT's batari Basic Commands? I'm grateful for the Neolithic Language Guide you wrote and it's a good primer for the language. But, I could use a tutorial to get started writing games. Thanks!

Thanks! That worked!

An inconsistency(?) in how bB handles partially defined conditionals: This actually executes and always hits the "else": if somenum< then COLUBK=$0E else pfclear 42 This produces the compilation error, "if-then too complex for logical OR": if othernum> then COLUBK=$44 else pfclear 255 bb_bug_20220725.bas.bin bb_bug_20220725.bas

Release 0.2: Better rails. Thanks to @KevKelley for testing and feedback! moonshoot_0.2.bas.bin moonshoot_0.2.bas

It's DPC+ with 8 virtual sprites, 4 to a side, moving fairly quickly, but the sprites are short. I'll try taller sprites to see if that helps.

Labels

0.1 Release: Gameplay, sounds, etc.! For now, there is little skill involved; you just use the joystick to open the rails and hope for the best! moonshoot_0.1.bas.bin moonshoot_0.1.bas In Stella 6.7 w/ luminescence at 30 pct.: (rails show when playing, not in screenshot) luminescence at 98 pct. (just for screenshot): (luminescence at 30 pct.)

Relive the mid-20th century race to the moon with Moonshoot for the Atari 2600! (DPC+ 32K) Moonshoot is an attempt to roughly simulate the original great wooden home carnival game called Shoot the Moon (*- see footnote.) The point system simulates the original: Earth: -250 First Stage: +250 Second Stage: +500 Third Stage: +1000 Fourth Stage: +2000 Moon: +5000 I've not seen the original's instructions, but I had to have some sort of game ending, so I made up my own getting 3 tries to keep it on the board. Controls: Joystick right: open rails more quickly Joystick left: close rails more quickly Joystick down: open rails very slightly Joystick up: close rails very slightly Use button to start another round or start a new game if game over Use reset switch to start another game *- there have been other versions of the physical game- some more recent. This attempts to emulate the original. You should try it out in physical form, either the older or newer version, if you can, because it's a great game, and it'll give more context to what's going on in the 2600 version. Can involve basic level of skill. Skill requirement could improve in future release. Thanks to @KevKelley, @Dave C, and @Karl G for their feedback as I was trying to develop the rail system. It may continue to evolve, but I think it's more rail-like than it was in early development. moonshoot_0.4.bas.bin moonshoot_0.4.bas

Emulator (Stella 6.7) Sounds good!

I love the new default playfield! It's good practice for one player, since it's difficult to play two players by myself, though I tried. The other two maps are good for two players. A few new things I noticed when playing, and since the release listed a few new glitches, maybe they are known. I could reproduce these, but not easily: When the ball hits the disappearing black bars sticking out from the wall from the lower left, it can go out and win. I had the ball go out to the right of the goal at low speed with the top green laser once also, and no black bars, so that may be a different bug, but it only happened once. When my laser is just right of center at the bottom and I'm shooting the red laser frequently, sometimes the ball and screen go fuzzy. (Also, the rate doesn't stay on 262 scanlines / 60 Hz for NTSC when the laser is on.)

@splendidnut This is awesome! I'm looking forward to getting this to work! I tested the Mac version in the distribution and ran into problems in the output running ./neolithic-mac congo (...Unable to process program due to error...), so would you like to start up another thread just for bugs, and I'll paste the output there, or should I just post it here since it's an alpha release?

That's what I thought you were talking about- using the third bit of NUSIZ for reflection also for player1-9 sprites. (So, on first frame: _NUSIZ1{3}=0 : NUSIZ1{3}=0 : NUSIZ2{3}=0 : NUSIZ3{3}=0 : NUSIZ4{3}=0 : NUSIZ5{3}=0 : NUSIZ6{3}=0 : NUSIZ7{3}=0 : NUSIZ8{3}=0 : NUSIZ9{3}=0 and on second frame: _NUSIZ1{3}=1 : NUSIZ1{3}=1 : NUSIZ2{3}=1 : NUSIZ3{3}=1 : NUSIZ4{3}=1 : NUSIZ5{3}=1 : NUSIZ6{3}=1 : NUSIZ7{3}=1 : NUSIZ8{3}=1 : NUSIZ9{3}=1). And the $01, $02, $04 widths of NUSIZ spaced copies might come in handy for stepped angle. In the actual wood and metal game, each rail has maybe 8.3-8.4 degrees of freedom to the opposite side from 90 degrees up. If you were to extend out the point of the virtual triangle from the fully extended rails past the hinges, it is a max of 17.6 (? questionable number, but within a degree or so) degree vertex of a virtual isoceles triangle, though the rails aren't pinned at the same point, so that's not as helpful. All that said, it's probably enough of a slant to need multiple sprites, I think, but I'm not sure how many yet. And there's the playfield idea, too.

Do whatever you think is best. I personally think it's challenging without the timed aspect, so maybe it could be a difficulty setting or at a later level. You could also have the walls/ceiling/floor close in over time, or the floor removed like in Joust; maybe the floor and top platform could alternate in disappearing and reappearing.

That's a good thought, and it would improve the amount I could draw on the page. It's a long line, though, so it would flicker some or a lot, but it might look more rail-like. Thanks!

@Karl G @Dave C Thanks! Just fyi, here's the really awful dev version of the Shoot the Moon game I'm working on, so you can maybe see why I was hoping to use missiles to get proper rails. I'll try to make playfield work, though. About it: The gameplay stinks atm, and getting the ball to work right was a whole PhD thesis for someone- I read and then ignored that since it was too intense, spent a few hours on it, ran into bB bugs with floating point that I know I probably hit like 14-15 years ago, and then started whacking it with a large stick for some hours to make the "beautiful and sensical code" it is currently. I could probably make something work with playfield and improve the resolution. Maybe I'll get the crappy version of the physics working also! ? Also, here's a photo from someone's listing on eBay of the old version I'm trying to emulate. There's a steel ball and you move the rods so the ball moves up and down, then you move the rods to drop it, on purpose or accidentally. shoot_the_moon_dev.bas.bin shoot_the_moon_dev.bas

I started working on a Shoot the Moon game where I needed lines for rails for the ball to roll on. For now I'm just moving the missiles each frame. Flicker isn't great since there are several or more frames with the missile moving at an angle and then repeating to try to simulate a slanted line. I thought about using playfield to do it, but it isn't a great option; the playfield rails would need to be over the playfield being used for the game board, so it'd either be invisible over the board, or more work would have to be done to change the color during scanlines, and I'm not sure how to do that. I could change playfield every other frame- one frame for the board and one for the rails, but that may be hard to look at and play with. To try to figure out how to use missiles to do lines, I looked at asm for Fishing Derby and Missile Command Arcade, but it's over my head exactly what's going on and especially how to pull that off in bB, with asm patches or a kernel hack. Has anyone gotten slanted lines made with missiles to work before in bB (or otherwise) and/or would it be possible to pull it off in bB without a lot of work? Thanks for your help!