R. Jones

Hello Again, I like the music. I got bB and I've been playing around with it. I have a much better idea of what can be done with it now. So, now I have more detailed suggestions. I know there's only a little bit of RAM in bB, so included an estimate for the RAM cost of the suggestions. You can have several modes. They would be chosen with the select switch at the title screen. You could number them with the score sprites. 1. Easy Mode This would be timed. At the start of the maze, some sort of prize would pop out of the end point. The object would simply bounce around the maze. This should only take three bytes of RAM. Two for the x and y positions and use four bits for the four directions. If the prize hits a wall check to see which two bits are on. Then reverse one direction. If the prize is still hitting a wall. Reverse the other direction. (If you like this idea, but don't know what I mean, I could explain it better, or even make a demo program.) At the end of every maze, the current score (time left on the clock) could be added to a location in the RAM for the final score. Whenever the player collects a prize, it will add time to the clock rather than directly add points. This would give the player more incentive to go after them, than simply giving them points. Points would be taken away from the final score for dying, but you couldn't completely lose. The prizes can be colored and the finish point made out of the ball. To differentiate the ball from the maze, flicker it at 30 hz which shouldn't look very bad at all on a real television with how dark Gosub's background is. (To keep track of whether the ball is on or off, you could use another bit of that third prize RAM byte.) Check the RAM that holds your current level and have proggressively nicer prizes. For example: Total RAM cost: 4 bytes Rom Cost: at least one maze 2. Hard Mode In this mode the timer will progressively go up. And the time will be subtracted from some predetermined number, to get the player's final score. If a player dies too many times they'll lose in this mode. Have a solid color sub pop out of the maze's finish point. The sub can move in the four cardinal directions and shoot a harmless "sonar" ping. The ball would be his ping. This should make AI easier to program. The ping will shoot off of the sub in whatever direction he's traveling. Whenever it hits something it will reverse directions and return to the enemy sub. Set up a byte of RAM with a timer. If the ping take too long to come back the sub knows that way is open. If the ping comes back quick the sub knows there is a wall there. You can keep a byte of Ram with above, below, left, and right mapped to four bits for the enemy sub. You can also four more bytes of Ram open with the xpos and ypos the sub was at when the ping returned on each side. Put something in your kernel that says something along the lines of: If Currentypos - yposwhenleftwallwasdetected > 10 set Thereisawallontheleftbit back to false. That way if the sub detects a wall on the left. The goes up about fifty lines, he isn't still trying to go right. This would take up a lot of RAM, though. Total RAM cost: at least 9 bytes Alternating Players This is something I suggested before. On the title screen you could have 1-8 in one color for easy and then 1-8 in another color for hard (there's a byte of RAM) Each player would get a single go at each maze. When they die a different colored sub we appear at the starting point, and they'd passe the joystick. At the end of the game every player's score would be shown. This is something I suggested before. I don't think it would work though. You need an extra byte of RAM for the title screen. A byte for each player's score. A byte to keep track of whose turn it is. If you don't add anything but multiplayer with individual scores to the game, you're already adding 10 bytes. You'll need to write a routine for cycling through each player's score and displaying different colored subs (this would also probably take a byte of RAM, now that I think about it.) This would be really cool to have, but I'm not sure if there would be room for it. (Ramwise) Cost: at least 11 bytes of RAM Race Mode This might be a better solution for multiplayer. Have a time limit on the mazes. No enemies or anything. But if a player dies once they're gone. This would only take two bytes. One to keep track of whose turn it was, and one to keep track of who's alive.

Nice. It's already better than Ed****.

"[ . . . ] but most importantly, lets hear your direct comments if Atari were to release a non-Atari 2600 chip powered device onto the market vs a real Atari product based on the Flashback 2 chipset" FB2-Based device - If it has a way to add new games (not necessarily a cart slot) I'd buy it. - My uncle was a big 2600 DK fan, so I'd probably buy him one, and put a copy of Donkey Kong on it. If it's possible, I set it up with a hack that would record high scores, and set the highest score with his highest from back in the day. - If I finish any games, I'd test them on the new FB2 for compatability. If it wasn't too much work, I'd try to make my games compatable with it, so they could reach a wider audience. Non-Atari 2600 device - I wouldn't buy it. - I wouldn't play it if I knew people that had it. - If I got it as a gift, I'd keep it out of obligation, but I'd just stick in a box and forget about it. - I'd warn other people not to buy it, if I thought they were considering it. - I'd be hesitant to buy other atari branded products, knowing that they'd ship out low-quality stuff like this just to make a buck off unsuspecting consumers, when they have the FB2 and a large catalog of games at their disposal.

Zonie, I'm not sure if you're aware of this, but at least two of the buttons on a genesis controller can easily be read by the vcs. One is fire; another is the opposite of an Omega Race grip. A lot of your positives involved things that could be done with extra buttons. I think extra buttons are a positive; but if they're the main reason for building these joysticks, very few will get built, and very few games will support them. - Robert Jones

Something that I see people alluding to, but not coming out and saying specifically is: "A good game concept for the vcs is one that uses the TIA creatively." A game concept that doesn't take the TIA into account is like a basketball play that doesn't take defenders into account. There would be no need to run a set play if there were no defenders. Likewise if the VCS were cocaine we wouldn't need any planning. The effort required to understand the TIA is probably less than half an hour of reading. Learning how to program a full game takes far more time and effort. If asking someone to read for half an hour is asking too much, then asking someone to program a game for many, many hours is definately asking too much.

Nice. Very indeed. I've never seen that before. Could you explain more about it? Jealous, R. Jones

ZylonBane, is that a screenshot or a mockup attached to your post. If it's a screenshot; is it of a demo, a WIP, or a finished game?

I just got a chance to play this all the way through. Anyway here are my thoughts: - I liked the easter egg screen. - A lot of the mazes were really similar. Get crazy with it. Also, you might want to consider taking the best half of your mazes and having a contest similar to Comat Redux to get the other half. (I worded that really bad, but I think the message was conveyed.) Contest page. - I liked the actual engine of the game. I remember when you were working on "Ants" before, and people (inlcuding myself) were saying that they liked the premise and look, but the actual engine was too simple. I think you've gotten better at giving the player control of his character without just giving him control of his sprite (if that makes sense). - I like how the game begins each level from a paused state. I had to leave the game for a few minutes to heat up some spaghetti, and was able to come right back. - This is the kind of game where you could have a lot of people playing turn-based multiplayer. (This is kind of my solution to everything.) I think it would be worth cutting out music to include this. You could have it be up to eight players. You could have it be elimination based: start each player with a set number of lives. If they use all of them they're out. Last one left wins. Use the other sprite for lives. Or you could have it be score based. Each player could have up to three chances at a level. With more points for beating on an earlier try and more points for beating levels (Something like 10 points for beating a level+the number of the level+9-(number of tries*3) Use the other sprite for some bonus items. Or you could have some stuff set up to select from different options. - In the one player mode, you could have an enemy that spawns from your spawn point a few seconds after you leave and chases you. The fire button could be used to lay mines. - You asked about the speed. I'd prefer it faster. Maybe you cna use the difficulty switches to choose? And a few questions I had: - What are you planning on using the other sprite for? - Are you planning any Atarivox support for saving games? I think I remember you posted about losing a lot your code because of computer problems. I'm glad to see that didn't stop you from coding. I look forward to seeing what you do with this. Good luck, R. Jones

Here are a few links that should help: Andrew Davie's 2600 101 Tutorial This is a really good explanation of how the 2600 works and how to write games for it. It's kind of technical, so it might be more information than you need. http://www.atariage.com/forums/index.php?a...;showentry=1130 Here is a simpler explanation of how the 2600 works. It's more geared to the layman who for whatever reason just wants a better understanding of it. http://www.atariage.com/forums/index.php?a...ighlite=%2Bidea These are some of Adam Tierney's threads. His threads are usually brought up as an example of what a good 2600 game proposal thread should be like. batari Basic Depending on what you want to do, bB might be a viable option to create your own game. Take a look at mausboy's graphic demo for his WIP space shooter for anexample of what's possible (graphically) with it. Best of luck with whatever you do, - Robert

I attached a zip file showing the different parts of battlezone individually. A few thoughts about your mock-up: - The background (which is a solid color all the way across the screen) is used to create the bottom part of the mountains. This is why the tanks in the foreground can move over the mountains. Changing the mounains to be vector-hollow would probably require large changes to the game. - A large part of the tank [EDIT: tank that you drive] appears to have also been drawn with the background. It would be difficult to hollow out for the same reasons. - Changing the [EDIT: enemy tank] tank graphics would very easy. - Changing just the colors (sky:black, ground: black, mountains:green, tank: green) of the background would be pretty easy with a commented disassembly. battlezone.zip

Here is my attempt to draw a missile cat. The first is one line resolution. The second is two line resolution. When animated they would go frame 1,2,3,2,1,2,. . . The head should probably be a little behind the body in the first frame, even in the second, and in front in the third. They look nothing like cats, but I thought I'd share them anyway. And the two line (poorly and hastily) animated:

I just read through this for the first time. I really like your mario and notmegaman sprites. I have a feeling that bB isn't going to support this, but I had an idea on how you could you could add enemies into the game. You could use M-Network style missile stacks and the ball (if you make the playfield black). Use the ball for fireballs and coins, too. Have fireball and coins use a constant 30hz flicker, and dissapear completely if they are on the same scan line as each other or a ball being used for an enemy. It would work pretty well for some objects like mushrooms, turtles, and ice. Some things like the flying turtles and the crabs would be almost impossible to do like this, though. Another downside would be that you could never have more than one enemy on the same scan line. If you decide to use this idea, I'd gladly help with the enemies. Here's a mockup using a tiled background: Edit: Here's a illustration of how the mushroom and turtle are made. Green and Blue are missiles, teal is a pixel occupied by both missiles (I'm not sure how well that would actually work), and red is the ball:

Thanks. That worked. You know you can't just click on dasm.exe from windows and expect it to work, right? When you say it just flashes briefly and then exits, it looks very much like you're doing that. To run DASM as a DOS app (as opposed to calling it from within an IDE) you need to go to a DOS command window first. Start/RUN and type in 'cmd' if you're using XP/Windows. Then navigate to the directory where DASM is, and type in the appropriate command line. Cheers A I tried to open it like a normal windows application first. When It didn't come up, I assumed it would only run in DOS. I tried to compile the disassembly of Donkey Kong (from the MiniDig) to test it out, using the "dasm source.asm -f3 -game.bin" command line from Kirk Israel's 2600 101 guide. I got an error message. It might just be the disassembly, though. I succesfully compiled several demos and Adventure with DASM through Crimson Editor, but it won't compile Donkey Kong. (The bin it spits out is just a blank screen with a rapid clicking noise in the background.) I might try to compile several .asm files that worked through DOS later.

Whenever I try to run DASM this briefly flashes on the screen before the program exits: I've used the 2600IDE for bB to compile several things. Since batari basic uses DASM to assemble games (it does use DASM right?) I don't think there's anything wrong with my version of DASM. I'm using Windows XP. I downloaded the latest version of DASM, and extracted it into a DASM folder in C:\program files\DASM. I also tried extracting it into several other folders. None worked so far. I'm using the bin>DOS>dasm.exe. So I tried downloading a DOS emulator (DOSbox) and opening dasm through that. This message comes up "This program cannot be run in DOS mode." Anyone know what I'm doing wrong or a way to set up an IDE (preferably crimson editor since I already have and have used it) to use dasm?

$40 for a 7800 with two controllers, power supply, and nine games (ten if you count the second copy of Combat.)

[ . . . ] What about the dragon is that a sprite? I know if I change it over to dragonfire dragon it will be vertical not sideways because of the orignal how it was designed. Thanks Feralstorm for just saving me a lot of headachs wondering where on earth that block spirite is to change!!!!!!!! Wade If you're using Stella, you can turn on and off the different display elements of a game using Alt+one of the bottom row of letter keys.

Changes I'd make if I was making changes: 1. Add delicious food items on the right side of the screen. 2. Divide the game into waves. 2.b. Have a set number of roaches per wave. 2.c. Have each new wave contain more roaches. 3. Make the point of the game to kill all of the roaches before they eat your food.

Your new builds are looking alot more polished. I have four unrelated thoughts about this. 1. This is really good, for a 2k game, a bB game, or a new programmers game. 2. My biggest criticism would be that the difficulty doesn't ramp up. I realize that a large part of that, is the simplicity of the current game, but around ant 70, something should happen. 3. Like I said before, the basic idea is appealing. Play to its strengths. Instead of making the ants simply disappear and take a notch off your bar. Have them turn into annoying fire ants that follow you and take notches off your bar. Use the missile or ball, to add some scenery (rock, twigs) that also can be conviently used to smash ants. 4. Don't think about selling it while you're making it. Making the game is 1/3 of the fun. If you're gonna think about selling it anyway, I'd reccomend you play Solar Plexus. People were all about this game, saying it was the most proffessional bB game etc. Then, it got released on cart, and it hasn't done that well. When people are playing free ROMs, it's easy to say, "Whoah, this is really cool, considering . . .," but when they actually start talking about plunking down $20-30 on a real cart, people prioritize. So when trying to figure out if people will buy something, don't think, "Is this game good enough to spend money on?" Think, "Would I spend money on this that could have gone to Marble Craze, Thrust, or Dark Mage?"

This is the very first programming related thing I ever did for the 2600. It's a graphic hack of Donkey Kong. You play as a skeleton, whose skin has been stolen by a Malicious Taxidermist. I was going to replace the single color barrels with deer heads (because [1] a taxidermist would have easier access to deer heads, [2] they're covered in dangerous spikes, and [3] they're easier to throw) but I discovered that there was no color map for the single color objects. When I get a better undertanding of asm, I'll probably come back and finish this, or at least use the awesome skin on a clothes rack sprite in something. Reskenge.bin

I don't think I would buy the current game as is. If it was part of a multicart, Ants would increase the value for me, but there would still have to be something else pretty interesting on the cart. I'm not a very good programmer, so this might not be easy/possible. But if you represented the player as a ball/missle, you could make the game two player, which would alot more value to it. It would also give you an extra sprite to work with. I hope I don't sound too negative. It's an interesting idea, and the changes you've made so far, have helped a lot.

I like it. You might want to consider changing the facing left and right sprites for your ship, though. 0XXXXXX 0000000 XXXXXXX 0000000 0XXXXXX The tail is sort of disorienting. You could try just leaving the tail off, or leaving the middle bar out: X000000 0XXXXXX 0000000 0XXXXXX X000000 Edit: Oh yeah, I forgot. I'd give an 8 also. Aside from that one complaint, you accomplished what you set out to do, and it was a neat idea. I'm playing it right now. (Well not right now; it's paused, but you know.)

I played with mojofltr's bottle sprite to try and make it blackground friendly. The first three look like bottles of ink though. Here's an animated one. I like this one; it's clever.

I'm a teenager. I just got into Atari, because it's so bizarre. I've been playing a bunch of ROMs and going to look for an actual system at Flea Markets, Goodwill, Garage Sales, etc. this week. I really like how the limitations on the size of the game reality and the way it's displayed, put so much emphasis on how you interact with it. I've never played a game like Crazy Climber, Room of Doom, or Stampede before. I'm also trying to learn how to write games for it. Trying . . .

The Glass Bottle is 7x20 3 colors. The Can is 7x12 3 colors. The Burger King cup is awful. The bottle is 7X16 6 colors. Feel free to change anything.done.bmp coke.bmp coke2.bmp coke3.bmp coke4.bmp