jrok

Saying E.T. didn't cause the video game crash is like saying smacking yourself in the head with a hammer doesn't cause cancer. Chances are it doesn't, but that doesn't mean it's good for your health. As for the Twinkie example, you can't return a disappointing Twinkie after use.

Really great work here! The scrolling is a brilliant trade-off. Can't wait to see more of this.

I think part of the trouble with E.T. as a game was that it was a little too ambitious for its own good. Players were almost given too much to do -- keeping track of invisible power zones, collecting candy, searching for phone parts, running from FBI guys -- and the heavy memorization factor involved probably felt more like work than play to people who played Atari for high scores and arcade thrills. Having to remember which screen exits would deposit you where, which pits contained which phone parts, where the invisible call and pickup spots were, the invisible spot you can call Elliot, the invisible spots where you could scare away your enemies, warp to different rooms, take a bubble bath, run for Congress, etc... this all seemed better suited for a graphic adventure style of game like the Sierra "Quest" series or Maniac Mansion, where you click for hotspots to interact with on various screens. Those sorts of games can be fun in their own right, but IMO the 2600's resources we're better suited for arcade action. In most computer graphic adventures, the hotspots are likewise invisible, but on systems with a more expansive graphics capabilities, you can give the player better visual clues on where to click. With E.T., the process was more minimal and abstract - rather than remembering that the spot to call Elliot was the pay phone booth next to the drug store, you instead had to remember that it was slightly to the left of the jagged pit that looked slightly different than all the other jagged pits in Elliots' quaint strip-mining town of Pittsville, U.S.A. And the few "action" elements that E.T. included felt forced and chore-like as well. Running from the FBI guy and the Scientist might have been a bit more fun if they couldn't magically float over those pits, or if you could use the fire button to float across them yourself instead of suicide-sprinting into them like an intergalactic lemming. The way things are, there is no game of cat-and-mouse: your enemies are just big, human-shaped heat-seeking missiles, and encounters with them mean you either find a roman numeral hot spot ("II"), you lose some time, or you get mugged and have to fall into more pits and grind for the stolen phone part again. And the way that the screens connect to each is so weird that it just looks and feels buggy. Maybe The best example of this is if, at the start of a new game, you move E.T. up one screen. Instead of wrapping and reappearing at the bottom of the next screen in a logical way, E.T. instead appears near the top of the next screen, just above a pit, and if you keep moving up you... reappear on the first screen, right back where you started, and again near the top of the screen. This is probably one of the all-time great WTF Atari moments. If it was an unsquashed bug that's bad enough, but given the odd way some of the other screens connect, it was possibly a whacked-out design decision. Either way, it's not explained in the manual, so it just feels confusing and broken. It's not the "worst game ever made" by a long shot, but it's still terrible. I think it was attempting to abstract a kind of gameplay (graphic adventure) that wasn't really suitable for abstraction, the screen-to-screen navigation was illogical and/or broken and the action-oriented concessions it made just weren't any fun.

I like the first set much better. In addition to the flexibility of a blank space, you could also use it to spell words like: EAT ASK ACT TURN TAKE REACT SNEAK SNARE TEAR SACK CASK CASE RUNE SANE / NUTS (good for Lovecraftian Cthlulu-type games ) NUKE CRANK TRACK STUNK SUNK ARCANE

New version is posted here and in the OP: http://www.atariage....o/#entry2647208 I re-wrote the instructions to reflect all changes and additions, but here's a rough overview of what's changed. - Revised Star Map controls. GAME RESET now toggles the Star Map before and after battles. - The Star Map is also automatically toggled off whenever a space battle begins. - Added random map layout at game start - Added command logic for player map navigation and warp drive use. - Added logic for multiple enemy unit placement and destruction. - Revised enemy ship battle movements. - Revised demo win conditions (Player must defeat all three enemy units to end the demo) Basically, the player can now cruise around the map screen and hunt down enemy armies. Wiping out all three armies ends the demo, which is more similar to what the victory conditions will be in the final game. Next step will be to write logic that allows the enemy armies to chart their own courses around the map, and to conquer any planets they come across. I'll also need to add a starbase and some repair/refuel functions to the planets, giving the player stuff to protect. Cheers, J STARCRUS_DEMO_12_10_12.bas.bin

It looks like you might have a slight data visualization problem here. I could be wrong since I don't know what you think it should look like, but from the way you have your data table laid out, it seems like you have 64 bits per rows instead of 32 bits per row (you are only going to be accessing 32 bits per row, per screen). So, while you are expecting to see a bitmap of the first "half" of each row, what the program is actually printing is this: data map %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111 %10000000, %00000000, %00000000, %00000001, %10000000, %00000000, %00000000, %00000001 %10100000, %00000000, %00111111, %11111001, %10100000, %00000000, %00111111, %11111001 %10100000, %00100000, %00100000, %00110001, %10100000, %00100000, %00100000, %00110001 %10100000, %00100000, %00100000, %11000001, %10100000, %00100000, %00100000, %11000001 %10100000, %00101111, %11100011, %00000001, %10100000, %00100001, %11100011, %00000001 %10100000, %00111000, %00001100, %00000001, %10100000, %00000000, %00001100, %00000001 %10100000, %00000000, %00110000, %00000001, %10100000, %00000000, %00110000, %00000001 %10111111, %11111111, %11000000, %00000001, %10111111, %11000001, %11000000, %00000001 %10000000, %00000000, %00000000, %00000001, %10000000, %00000000, %00000000, %00000001 %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111 %10101010, %01010101, %01010101, %01010100, %01010101, %01010001, %01010101, %01010101 %10000000, %00000000, %00000000, %00000001, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000001, %10000001, %00100000, %00000000, %00111111, %11111001 %10000000, %00100000, %00000000, %00110001, %00100000, %00100000, %00100000, %00110001 %10000000, %00100000, %00000000, %11000001, %00100000, %00100000, %00100000, %11000001 %10000000, %00101111, %10000011, %00000001, %00100000, %00100111, %11100011, %00000001 %10000000, %00111000, %00000000, %00000001, %00100000, %00111000, %00001100, %00000001 %10000000, %00000000, %00000000, %00000001, %00100000, %00000000, %00110000, %00000001 %10000000, %11111111, %00000000, %00000001, %10000011, %10000011, %11000000, %00000001 %10000000, %00000000, %00000000, %00000001, %10000000, %00000000, %00000000, %00000001 %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111 end That's what you'll see if you insert a hard return at the midway point in each row of your table. You'll see that the output of your program matches exactly the first ten rows of the bitmap image you are feeding it, but maybe not the way you were expecting it. Look at my attached version (I re-mapped the table to read "JROK WAS HERE") and see if it makes sense to you. The way you laid out your table, it looks to me like you thought it was reading bytes 0-3, then bytes 8-11, then bytes 16-19, etc. You could still potentially lay it out your way, just add a table pointer that accounts for the 4-byte shift when it picks which row to print. I also saved you 34 bytes by wrapping your bitmapper into a single for-loop. Cheers, J bitplayfield4.bas.bin bitplayfield4.bas

Why not both? http://www.atariage.com/forums/topic/93867-using-the-score-for-a-game-title-or-inventory-strip/#entry1139891

Yeah, I agree that masking out zones might be the way to go. My example was just meant to be generally illustrative of the concept. For my project (32x20 grid), I'm thinking of employing a combination of an "E.T." array pointer with 4 bytes reserved to disable certain elements. That's why I think pinning down the grid size should be mission number one for RT, here. When you have a sense of the size of your search grid, the best options become clearer.

I'm not sure how they were implemented in E.T., but what you describe is essentially a grid of binary nodes - like a checkerboard with some squares turned "on" (treasure, trap or resource is there) and many more turned "off" (nothing of interest is there). I think the general way I'd approach it would be to start out by determining the grid size (how many possible map positions there are vertically and horizontally) and the number of possible outcomes whenever the player occupies a square on the grid. For the sake of argument, let's say that our grid is 8x8, and that there is only one possible outcomes when the player digs up the ground at his present square. With 8 bytes of RAM you could create a bitmap of your search grid: dim map_row1 = a dim map_row2 = b dim map_row3 = c dim map_row4 = d dim map_row5 = a dim map_row6 = b dim map_row7 = c dim map_row8 = d map_row1 = %00000000 map_row2 = %00000000 map_row3 = %00000000 map_row4 = %00000000 map_row5 = %00000000 map_row6 = %00000000 map_row7 = %00000000 map_row8 = %00000000 Then you can randomly turn on bits in each row at the beginning of play to determine whether a treasure is there or not. During gameplay, track the player's grid position. When a player is located in the same position as a "1" square and digs, give him the treasure (i.e. play a sound, show a picture, add points, etc) and then turn the bit off so that the next time he digs there, he'll get bupkis. If you wanted to further randomize the kind of prize he gets, just do a rand command during the digging routine, and display the appropriate result: dim dig_result = e constant treasure = 0 constant trap = 1 constant oil = 2 constant skeleton = 3 DiggingRoutine dig_result = rand & 3 if dig_result = treasure then goto FoundTreasure if dig_result = trap then goto TriggeredTrap if dig_result = oil then goto StruckOil if dig_result = skeleton then goto HolyCrapASkeleton Off the top of my head that's just one way to do it, and just the bare bones of it. The randomness in this example can be finessed and weighted in a number of ways (limit the number of bits flipped at the beginning of play, expand or reduce the odds of each dig result, etc). I'm going to do something similar to this with the navigation map in Star Crusade, but I'm thinking of using a large ROM bit array instead of a RAM array, then randomizing a pointer in order to randomize the elements in the map.

I've posted a new version of this in the OP: http://www.atariage....o/#entry2647208 List of changes: Revised enemy flight movement. I think they use the scaling effect better now, flying more often in 'tween states instead of just very far away or extremely close . Revised player ship's color scheme, layout and controls. The biggest control change is that players now fire their lasers on button releases instead of button presses, to allow for Photon Bomb activation. When a player holds down the fire button for about a second, he will hear a little "charge-up" sound begin to play. When the sound effect reaches it's highest frequency, releasing the button will activate a smart bomb that instantly destroys any enemies visible on the forward viewscreen. Play begins with a maximum of 3 bombs, displayed by orange icons along the top of the dashboard, but will be able to be replenished by space stations and certain planets when I get those things implemented. Added Star Map. By toggling the BW switch, players can view a map of the quadrant that shows enemies, space stations and planets in nearby quadrants. At the moment, this doesn't do much else than pause the game, but eventually this will function a lot like the maps in similar space shooters, albeit with a few new twists. New title screen. It's not hi-res, but it conserves valuable space and still gets the job, I think.

Thanks! Nothing too magical going on here, though. The graphics are really thanks to batari's hard work on bb1.1. There's just so much that can be accomplished in the visuals department now with DPC+ support. Thanks! And yes, they are. Thanks for the report. Unfortunately I can't test this very much on real hardware, since my Atari is somewhat on the fritz. Cool! Battlesphere looks like a very fun game.

If you playtest a bit more, I think you'll find that the jitter happens whenever you press right on the joystick (whether there are enemies on screen or not). This is a known bug that I'm working on. The only unusual thing going on that I can think of is that a negative fixed point variable is used when the player moves to the right. Not sure why (or if) that should be troublesome, so I'll have to attempt some trial-and-error fixes this weekend.

Yeah, the laser display is made with playfield pixels (single-line resolution).

Thanks man.

As far as I can tell, there are no catastrophic bugs in 1.1d. I've tested several DPC+ projects on my hardware, and the sort of bugs I've found tend to be small issues, many of which I recall were reported on batari's original bb1.1 thread. Still, if you think it's worth it, I'll try to post what little I know sometime tonight or tomorrow.

Yes, this was made using the DPC+ kernel (bB 1.1d).

Thanks.

You can't refuel or repair in this demo. It's just a straightforward fight to the finish with 16 enemies.

Thanks!

Thanks, Kevin. I agree that it needs a switch for reversed control. It's just, I've been testing it on Stella a lot, and I find down-for-dive to be somehow a lot more intuitive on a keyboard.

Hey guys - Long time, no post. Thanks to Al and RevEng for nudging me out of my AA coma. I've been trying to climb back into the homebrew hobby a bit over the past few weeks, and in the process I dusted off a couple of old projects I'd been tinkering with last year. One of them was called "Star Crusade." I basically set out to do a space shooter in the Star Raiders/ Starmaster/ Phaser Patrol tradition, with all of that genre's familiar conventions plus a few new twists that would hopefully set it apart from the crowd. I'll be updating the below instructions regularly to reflect new features and changes in the project. Cheers, J ~*~*~*~*~*~*~*~*~*~*~ Starting the game: - Press fire at the title screen to begin a new game. Rules of play: This demo pits your space cruiser against three units of enemy fighters (30 ships total). After the game starts, press the Game Reset button to view your Star Map. Each new game will randomly position your ship, two enemy squadrons (6 ships each), one enemy flotilla (18 ships) and three planetary systems on the map. Using the Command Menu, navigate your ship towards one of the enemy units. When your ship moves within combat range, the Star Map will automatically switch back to the Battle Viewscreen. Use the radar in the center of your command console to track enemy positions and maneuver them into firing range. Enemy fighters are classed 1 - 3, with Class 3 being the fastest and most aggressive. They will attack you two at a time, zooming and weaving around your ship. Avoid their fire as best you can and blast them to pieces. Once the last ship in the unit is destroyed, you can press Game Reset to switch back to the Star Map and plot your next move. Clear the map of all enemies to win and end the demo. Battle Viewscreen controls: - Tap and release the fire button to fire your Laser Array (cost: 100 fuel per shot) - Hold the fire button to charge up your Photon Blast superweapon, then release to fire it (3 uses) - Push up/forward to climb - Pull down/backward to dive - Press left or right to steer sideways - Press the Game Reset switch to view the Star Map (the map will not appear if a space battle is in progress). Star Map controls: - Tap the joystick up, down, left and right to move the cursor around the screen. - Press the fire button to open your Command Menu, then tap left or right to select the desired command. - Press the fire button again to execute the selected command. Map Legend: - The player's current location - A inhabited solar system. - A squadron of 6 enemy fighters. - A flotilla of 18 enemy fighters. Commands: - Navigate to the selected area using standard thrusters. - Move instantly to the selected area using your warp drive (cost: 10,000 fuel per warp). - Scan selected area (not implemented yet) - Cancel / Close Command Menu. Heads-Up Display: At the bottom of your screen is a HUD dashboard that shows you important information about your ship. This HUD persists whether you are viewing the Star Map or the Battle Viewscreen. Photon Bombs - Remaining Photon Bombs, indicated by the orange icons at the top of the dashboard. Shields - Remaining power to your shields, indicated by the status bar next to the letter "S". Radar - A display in the center of your console that shows the location of nearby ships as light-blue blips. Ships in the gray outer rectangle are beyond your firing range, while those in the interior dark-blue rectangle are within range, and will appear in your forward viewscreen (Battle Viewscreen only). Command Menu - A menu that allows you to issue orders to your crew (Star Map only). Fuel - The number in the green box at the bottom of your display represents your remaining fuel/hull integrity. Once this drops to zero, you are dead. Taking Damage: When enemy fire hits your craft, you will receive damage to your shields. Once this bar has been fully depleted, enemy shots will damage your ship directly, causing catastrophic fuel losses and system failures. Eventually, the loss of systems will be modeled in a less linear way, but for now system failures occur in this order: 1st shot - Tactical display (targeting crosshairs disappear) 5th shot - Impulse engines (ship will now manuever at 1/2 speed) 6th shot - Radar (can no longer track enemies) (updated 11/10/13) ~*~*~*~*~*~*~*~*~*~*~ Latest version below: - Revised controls (GAME RESET now toggles the Star Map before and after battles) - Added random map layout logic and command logic for player map navigation and warp drive. - Added logic for multiple enemy unit placement and engagement. - Revised enemy ship battle movements. - Revised demo win conditions (player must defeat all three enemy units) Note: This build will probably still jitter a little on a Harmony cart. It's only really suitable for emulation playtesting, until I rework some code. I recommend using Stella's phosphor setting (ALT-P) to compensate for any flicker. STARCRUS_DEMO_12_23_12.bas.bin

Be sure to define the values of DF0FRACINC - DF6FRACINC for <i>every</i> drawscreen (Without seeing your code, I'm thinking that this is your problem; it seems to be a universal issue with the 1.1d build) Also, try inserting the following at the beginning of each bank designation (bank 1, bank 2, etc): temp1 = temp1

I was working under the assumption that he wanted to limit RAM usage, and have an effect that was simple to restart and stop after two iterations. My version uses 22 more bytes of ROM, but it only uses 1 byte of RAM and resets to defaults after two flashes. And - maybe I was wrong in assuming this - but I figured that the "flash" effect itself was something that would start when a certain condition was triggered, like a ship being smacked with a missile, and stop after a certain duration. In that spirit, I put together a little demo showing how 9 bits can be used to trigger a color & sound event. This could be optimized in a bunch of ways (including storing both the color and sound effect in a single data table), but I get the feeling that this is somewhat along the lines of what RT was looking for. Hit_Effect.bas Hit_Effect.bas.bin

Since the color array is static, how about just use a pointer and a data table. data colorflash $40,$42,$44,$46,$44,$42,$40,$42,$44,$46,$44,$42,$40 end Loop COLUBK = 0 if a < colorflash_length-1 then a = a + 1 : COLUBK = colorflash[a] if joy0fire then a = 0 drawscreen goto Loop

I'm not sure I know what you mean. What is the stair-stepping effect?