Zach

Clever. The end of Splatform does indeed lead naturally into Crash N Dive.

As much as I appreciate Bob's efforts into making a 1K menu, I think Swoops! is good in its present form. I'm fine with reading a manual on the side.

Thanks Thomas! I'm having fun with it right now.

Thanks for the comments, everyone. Here is the source code, but I still have dibs on using the kernel for Ataxx or Reversi. If you're wondering how it works, I've posted an explanation for a similar 8 marble wide kernel in my blog. See comments #2 and #4. http://www.atariage.com/forums/index.php?a...owentry&eid=414 I've figured out how to store 8 puzzles using 33 bytes instead of the current 56. For optimization, I think it will be safe to forgo setting the stack at the beginning, since I'm not using JSR nor BRK. Does that sound right to everyone? marble_solitaire_source.zip

Hi Bob, I finally got around to trying M4. Nice job. I like all the ideas for variations too. The more, the better, in my opinion. BTW, you are going to allow the reset switch to work in the middle of a game, right?

Marble Solitaire is a classic puzzle game played on a board with 33 squares. In the UK, it is simply known as Solitaire. It also goes by the name Peg Solitaire. The object of this game is to clear the board with the last piece in the center as shown below. Marbles move by capturing horizontally or vertically, but not diagonally. A capture is similar to checkers, where a marble jumps over another piece. To play, position the cursor on top of the piece you want to move. To jump, hold down the button and push the joystick in the desired direction. You can also reset the board to start over and select one of 8 puzzles. Puzzles 1 and 2 are fairly easy. The rest take some effort. So far, I have solved 1,2,3,4,6, and 7. My girlfriend has solved 3 of the puzzles, but to her credit, she hasn’t spent nearly as much time as I have. I’ve only begun to optimize, so I may be able to add more features in time for the competition. http://en.wikipedia.org/wiki/Peg_solitaire marble_solitaire_aug23.zip

Those who will be attending the vgXpo in Dallas will get a chance to sample Four-Play at the AtariAge booth. I just submitted an updated demo with the following changes: Each player now uses their own joystick. Game ends automatically with four in a row in any direction. Scanline count stabilized at 262 lines. The more I think about the A.I. the more I think I'd be better off doing a one-player puzzle game for the 1K competition. In fact, I've already got a good demo working, and I'll post it once everyone gets back from CGE and vgXpo. I will bring Four-Play and my 1K puzzle game to the Classic Game Expo in California this weekend. Anyone with a 2600 set up is welcome to take a look. On a side note: Saw a live performance by Carrot Top at the California State Fair tonight.

Thanks. The path information is hard-coded. Any kind of cool maze searching algorithms would be difficult for the Atari to do in real time.

Not all 1K games have been submitted to the contest yet.

For those of you who are new to the forums, Tank AI is my one player version of Combat. I started it two years ago as a class project and had made a playable version. It was good enough that Digital Eclipse gave it the honor of including it in the Atari Anthology. Unfortunately the computer was not very competitive against a human being, and I was short on ideas for making it smarter. In January this year, I had rashly pronounced the project over. Since then things have improved. A breakthrough came when I realized that the code that directs the tank could be applied to guided missiles as well. I've put together a demo that shows how deadly guided shots can be. I have ruled out using complex mazes like my old demo, and have decided to use the three original playfields. Thanks to Rob Mitchell for not letting me give up. I gradually work on Tank AI from time to time, even though I prefer to focus on a non-infringing homebrew that can be put on cartridge. My priorities could change if I can work out a deal with Atari Inc. to include it on a future project. (Flashback 3?) Tank_AI_demo_12Aug05.zip

OK, after a while I figured out how to win at level 3. To make smarter AI, I'll have to learn how to do Alpha-Beta pruning. Then you might be able to play at levels 4 and 5. (Actually you can play above level 3 now, but it takes a long time for the computer to move.)

Cool. I got 624 points after a few minutes of play. For a while I wondered if the fish actually grew, but saw that it did after 200 pts. Are you planning to enter the 1K and 4K contests?

Thanks Manuel. I've got a good AI algorithm working in C and it's just a matter of porting it to assembly. A DOS implementation of my AI can be downloaded from a previous blog entry. I have never won on level 3.

Excellent job, cd-w! It's a very clever use of missiles to draw the bells. I can't help wonder though if it's not possible to place Hunchy in front of the ladders. Even though you are using the left border to cover extraneous missiles, could you make changes to CTRLPF on the fly? If you can hit cycle 28, the change will be exactly where you need it. Of course it would take a bare minimum of six cycles and more realistically ten per scanline.

Lots of good suggestions here. I'll just add Space Treat. BTW, I think in Pac-Man you just eat the sheets the ghosts are wearing.

Let's see. Travel 100 miles to attend a classic video game convention and a chance to escape the Sacramento Valley heat? OK, I'm in. I'll probably bring a Krokodile cart with my latest projects in case anybody with a 2600 handy wants to see.

Progress report on Four-Play The kernel displays a full 7x7 board, and you can select a column with your joystick and drop your piece in. Currently I am working on game logic, specifically how to recognize a winning string of four pieces. Once that is done, a two player version will not be far away. The code as is easily fits into 1K, but it doesn't have game logic or AI yet. I give myself a 50/50 chance that I will be able to fit it all into 1K in time for the 2005 minigame contest.

Thanks Lee. I'll see you there.

Aaron, if you're still interested in A*, here's an idea for a better heuristic. If a ring is not in the same row or column as Non-Infringing-Yellow-Pie-Shaped-Man, he will need at least two moves to get to it. So all you do is take the number of those rings, double, and add the number of any rings that are in the same row/column*. That gives you a safe lower bound for the number of remaining moves. If you want to get more sophisticated, if a ring is in the same row/column as the player but an obstacle is in between, it will take at least 3 moves to catch it. *If two or more rings are in the same row/column and in the same direction, they should only count as one.

At least the ROMs have been dumped for some of these games. They will be public domain someday...

I believe so. In the case of Aaron's puzzle, Dijkstra's algorithm is also equivalent to a regular brute force search, since each move costs the same amount (1 step).

By the way, counting the rings remaining will be an effective heuristic, as long as you don't have a scenario where you can pick up two rings with a single move. To assume it will always take 1 or more moves to get each ring is a good underestimate. The set-up work involved in getting the rings will be sorted out by the search. If you grab a ring early on and screw yourself up, the search will eventually reach a point where g grows too high, and the search will switch to another path.

Hey Aaron, I solved a similar 8 puzzle using A* as a homework assignment once. You are correct about needing an "idea of closeness", but this needs some more explanation. An A* search consists of calculating two values; I'll call them g and h, where g is the cost incurred so far, and h is an estimate of the remaining cost to get to the goal. In the example of a maze, the cost refers to the distance traveled, and in your application the cost would be the number of moves. The heuristic, h, has a specific requirement: it must never overestimate the remaining cost - this is needed to guarantee the optimal solution. In finding a path through a maze, h is usually the linear distance between the current point the the goal. Obviously this is an underestimate because the distance traveled between two points can not be less than the linear distance. The safest heuristic is to let h=0, which is what I believe Thomas suggested. Clearly it will always underestimate how many step are left, but usually it will be far from the true amount. The trick to speeding up your A* is to find a "smarter" h. So to sum up, we should try to think of a way to estimate how many moves are left at each point, without going over. If there are no better ideas, we can always use h=0.

Don't know how to build a remote control reset button, but I've solved the problem by keeping the Atari in a wheeled box. Just roll it next to the couch when playing and roll it back under the TV when done. The IKEA journalist series works well.

I just realized, because the movable objects advance until they bump a obstacle, there will always be less than 4 moves per object.* So really you are dealing will 6^n branches. Furthermore, objects will only have 2 moves most of the time. The brute-force search is looking better. * Yes, there is a possible exception for the first move.