Polarium

[+atari2600land]

Here's level 1 of a port of a DS game called Polarium. If you're not familiar with the game, it's a puzzle game where you try to clear blocks by turning the black ones into white and the white ones into black using one line. If by the time the line is completed, all the blocks in each row is one color, the screen is completed, and you move on to the next one. This game is just like this, but there is no line (for obvious reasons) and since there's no line, you can go back and forth. To start the line, press and hold fire. When your path is completed, let go of fire. If the level isn't completed, you start back at the beginning. This level 1, featuring a picture of the number 1, is beatable. Can you do it? And should I continue working on this?

polarium.bas

polarium.bin

[SeaGtGruff]

I've never played the original DS game, so it took me a minute to figure out what I was supposed to do, but I finally managed to clear the level. It's an interesting little puzzle game, so I say go for it! But I wonder if you could do something like cycle between three colors-- color A goes to color B, color B goes to color C, and color C goes back to color A? That would certainly make it more challenging! If the game board is an 8x8 grid, you could use the background, player0, and player1 for the three colors (with the two players set to quadruple-wide mode), use the playfield for the border around the game board, and use the ball for the cursor. Another idea might be to stay with a two-color board (in keeping with the name, "Polarium"), but have a counter that keeps track of how many times you move the cursor, so the player could see if a level can be cleared in fewer moves. That is, if you clear level 1 in 50 moves, then the next time you play you could see if you can clear level 1 in less than 50 moves.

 

Michael

 

 

 

[+atari2600land]

Some neat ideas! I've done some remodeling, and now the goal is to clear the stage in a set number of moves. The counter is the score and your goal is to have one move left and have it be a valid clearance. For example, can you beat this level in 47 moves? If you can in less than that, please tell me.

polarium.bas.bin

polarium.bas

[+Gemintronic]

Brain. Not. Working.. I'll try to read and understand the instructions later in the day. I press and hold fire and move around.. but.. nothing happens when I release the button. This is end-user-itis and not your coding.

 

Still, please forgive me for saying this: Keep you hobby projects to a minimum Your other cool games may get lost in time.

 

I think I was on to something with my last post in yer DK 3 topic. It was coordinate based instead of hardware collision.

[SeaGtGruff]

I managed to clear the first one with 10 left in the score!

 

Michael

 

 

 

Edited October 1, 2010 by SeaGtGruff

[SeaGtGruff]

I press and hold fire and move around.. but.. nothing happens when I release the button.

You have to keep the button held down until you clear the board. You can move the cursor around without pressing the button, to get it where you want to start from. Then press the button and keep it held down while you move around and try to clear all the squares. As soon as you let go of the button, it restarts the game if you haven't cleared everything yet.

 

Michael

[+atari2600land]

I managed to clear the first one with 10 left in the score!

 

Michael

 

Really? Do you remember how?

[SeaGtGruff]

I finally managed to clear the second one, with 8 moves left. I'm going to have to start taking screenshots.

 

Michael

 

 

 

[SeaGtGruff]

I managed to clear the first one with 10 left in the score!

 

Michael

 

Really? Do you remember how?

The first time I cleared it, I had 2 moves left, and I started in the upper right corner. So I kept trying to duplicate it, starting in the upper right corner, but kept going over. Then I finally did it with 10 moves left, but I don't remember exactly how. I might be able to record myself playing it and see if I can duplicate it again.

 

Michael

 

PS - I like this game, especially with the changes you made from the first version. It seems deceptively simple, yet is extremely challenging.

Edited October 1, 2010 by SeaGtGruff

[+Gemintronic]

Hey! Since yer not using player0 or player1 (I think) why not use them for the left and right lines on the side? You know: for less flicker and great justice. Oh, wait.. sorry. Just reading through the code again.

 

I thought you could go:

top line is a missle

bottom line is a missle

left line is a player

right line is a player

Edited October 1, 2010 by theloon

[SeaGtGruff]

I managed to clear the first one with 10 left in the score!

 

Michael

 

Really? Do you remember how?

Quandry: I managed to duplicate and memorize the moves, and took several screenshots to show the movements step by step. But should I post them here and spoil level 1 for everyone else, or just PM you? I'll send them to you in a PM for now, and you can decide if you want me to post them here.

 

Michael

[SeaGtGruff]

I've duplicated and memorized how to clear level 2 with 8 moves left, but I can't take screenshots right now because it takes a long time and it's late.

 

Michael

 

 

 

[+atari2600land]

Back to work. I need to figure out how to make it so you can't backtrack (go over the same space twice.) Anyone have any suggestions on how to do this?

By the way, you can go out of the board, but what counts is in the gray box. Like in the original, the gray box doesn't matter, but it also needs to be limited to one move only per square. I fried my brain trying to think of a way to do this, but can't seem to find one. If you make all the lines in a row the same color, the playfield will go black (I did this on purpose, it won't be in the final game, though.)

polarium112910.bas

polarium112910.bin

[+atari2600land]

I still need help with the problem above, but in case you don't know what Polarium is, a hint is its working title: One-Line Puzzle. Download the binary and watch the title screen animation, and, if you want to help with my no-backtracking over a square you already went over problem, download the .bas file, too (please!)

polarium112910_4k.bas.bin

polarium112910_4k.bas

[SeaGtGruff]

I'm glad to see you're working on this again, because I thought it was pretty neat, and addictively challenging. I haven't tried your latest builds yet, and it's kind of late now, so I'll check them out tomorrow night.

 

Michael

 

 

 

[+atari2600land]

Since there have been an influx of new members here that know more than I, I'd thought they could help me with the problem of not being able to backtrack. I don't want the cursor to be on a square that has already been touched by the cursor when the player is flipping the pfpixels. Here is some annotated code, the newest one. I don't know why, but I'm posting the binary file too.

polarium1.bas

polarium1.bas.bin

[+Gemintronic]

I'm not sure I follow. You want to block the cursor from moving onto a space that it's already moved over?

[+atari2600land]

I'm not sure I follow. You want to block the cursor from moving onto a space that it's already moved over?

Yep, but only if the cursor is red.

[+Gemintronic]

As usual I don't have a useful answer for you. I think what you need is a collision map. In theory you could use a DATA statement like a binary array. Each bit represents a coordinate in your puzzle. Bogax did some work on what I'm talking about here:

http://www.atariage.com/forums/topic/200939-accessing-data-as-binary-array/

 

My trouble has always been adapting his work to arrays of different sizes. Meaning adjusting his code to work 16x16 or 8x7 or whatever.

[Cybearg]

Yep, but only if the cursor is red.

Does it need to be a specific space? Is there any visual cue to indicate to the player which of those it would be? Or is the player flipping between whether they can move over black or white? It seemed fully functional to me with the ability to move back and forth as-is. What does the flipping do? Could you post a sample video of the DS game or something demonstrating how it should look?

 

If you need to remember specifically which pfpixel was touched before without anything to work off of (such as the ability to check whether a pfpixel is active or not), the only way I can see doing it is by setting aside a series of bitmapped variables to represent the "okay" and "not-okay" movement states of the 4x8 playfield blocks. This would, of course, require 4 x 10 = 40 variables, which aren't normally available but may be doable with a superchip.

 

EDIT: No, silly me, you could just affect the direct variables that already represent the on/off states of the playfield, right? Well, that is, unless there needs to be no visual distinction as to whether or not you can move in a certain place, but this would be a simple way to affect the playfield.

[+Gemintronic]

If it was as simple as not going where his cursor had already "drawn" then he'd just check the playfield pixel for the drawn color and not allow movement in that direction.

 

I *think* he needs a collision map. Basically an array that represents the current screen as collision and non-collision areas. If the level has solid objects that never change then a DATA statement used as an array would do. If the level changes then he'd have to use variables.

 

Thing is, solid/empty is a boolean value. He could use each bit of an 8-bit variable as an element.

[+atari2600land]

Here's a video of the GBA version:

http://www.youtube.com/watch?v=xAGbSOPZzqs

[+Gemintronic]

Embedding disabled by request? That sucks.

 

Anyway, now it's clear to me.

 

Complicated method I dunno how to implement:

Create a binary array to represent used/unused areas of the playfield.

 

Cheat:

Use pfcolors and separate playfield rows to create a semi hidden copy of the playfield. Except the blocks represent areas already traversed. You can hide it by making the background color the same as the foreground for those rows. You could also use pfheights to make those rows only 1 pixel tall to further hide them.

[Cybearg]

Binary array won't work because the values have to change based on whether or not the player has been over them, methinks. I don't see how pfcolors will work like theloon suggests because you need the colors (black and white) to do the actual gameplay.

 

I think that the only way is using RAM SuperChip. It may be a bit complicated programming wise and may gobble up a lot of cycles, so there may be a better way of doing this, but I think that you need to, as I say above, set aside 40 varibles and bit operations to account for whether a pfpixel is 0 (not touched) or 1 (touched). If the player moved the red cursor to a pfpixel, it'd flip the bit to on and the player wouldn't be allowed to move a cursor onto a pfpixel location that had a bit that was flipped on. After the player was finished, they'd hit the trigger and every pfpixel that had a bit flipped to 1 would then reverse itself, either turning on if it was off or off if it was on. Does that make sense?

[GroovyBee]

Binary array won't work because the values have to change based on whether or not the player has been over them, methinks.

 

A binary array in RAM is ideal because you've either visited the square or you haven't which is 2 states.