Hey, gang. This is one of my more technical questions here. I'm still
working on getting the hang of the (for lack of a better phrase)
graphics engine, but it's coming along.
My mom was thrilled to find out I want to make Atari games. She
asked me when I was going to make "Columns" for the VCS--she says the
controllers on my Master System have too many buttons (yes, I know.
There's a reason I haven't shown her the controllers for my Jaguar
yet). As I mulled the possibility, it seems that I'm running into a
more extreme version of what I'm trying to figure out in making the
Solitaire game.
This is sort of a mental flowchart. I'll start with the most
immediate problem for the Solitaire game, and then explain how this
ties into a Columns translation. I need to know if this is feasible
and/or needlessly complicated. All this assumes I eventually get the
hang of drawing the graphics.
First, the control layout, so you can follow my logic. The
joystick moves the pointer between the spots for cards, empty or not.
Pressing the button creates action depending on what it is over. If
the pointer is over the draw pile, it takes the top card there and puts
it in the discard pile. If it is over the discard pile, it takes
whatever card is there and holds it (whether I'll do this by having the
card flash or have it graphically moved somewhere else on the screen
while the player makes up their mind what they are doing with it, I
don't know yet) in memory. If it is over one of the seven stacks, it
will pick up that card. If the button is pressed again, it will pick
up the card behind it that is face up, and so on. The pointer can then
be moved to whatever stack the person wants. By pressing the button
again, if it is carrying cards, it will set them down in the desired
spot if legal or put them back where they came from if not.
When the computer powers up, I put at memory location FFFC and
FFFD the memory address it is to start running from (since it's a 6502,
I put the last two bits of the location in the first register and the
first to bits in the second register, right?). At that location, I
tell the computer to set the flags and clear out some spaces in memory
to remember the cards. Since the person is likely waiting to play the
game, the computer takes these few start-up seconds to shuffle the deck
and prepare how they will be laid out.
I then start the VSYNC command stuff. Since the computer will
come back here once it is done drawing the screen, this is where to put
the bulk of the commands. First, I check for controller input,
controlling the pointer (in the interest of not driving myself insane,
the pointer will shift card positions, not moving over the screen
independently. It seems to me this will make it easier to keep track
of what it's pointing at). If there is a controller input, the
computer takes appropriate action (if the button is pressed, is it
holding cards?, if it is, can the cards be placed on that stack? Is
there a stack to begin with? If direction involved, where is it moving
to?). If there is none, the computer waits patiently until it gets to
the actual television screen and draws out the images.
(Deep breath.) This is where I hit the wall. The computer needs
to keep track of, among other things, what all the cards are in the
deck of cards, the discard deck, the four stacks you start with the
aces, and the seven stacks you start the game with. Take the last
stack, the one with seven cards, one up, six down at the start. I'm
thinking I'll need a pair of memory cells for each card, one to tell
the denomination, the other to tell what suit it is. That's twelve for
the face down cards so far. I would also need at least another
twenty-four for the face up cards, assuming there is a King on top and
the person keeps building off of it until he hits a two--an Ace would
have to be moved up to the top, it can't be placed on the stack.
That's 210 memory locations so far, since you can never tell which
stack will be empty so a King can be placed there. I suppose the
stacks at the top would be a little easier to manage. I image one
memory cell to denote the suit, and then another thirteen cells for
each stack. Since the cards in the discard deck never change order, I
would probably set up forty-eight memory cells for twenty-four cards
and their suits.
So, assuming some controller action is taken, the computer checks
to see the situation, starting with the action button. If there is
nothing where the pointer is when the button is pushed, it makes an
annoyed tone. If there is a card face down, it turns the card over.
If there is a face up card, the computer checks the Move stack. If
something is there, the computer compares the highest card on the Move
stack with the lowest card where the pointer is. If the number at the
pointer is one higher and the opposite color of the highest card on the
Move stack, it puts whatever is on the Move stack on the pile the
pointer is pointing at. If there is nothing in the Move stack when the
button is pushed, it moves the face-up card to the Move stack. If
there is already something in the Move stack, the computer checks if
the card is one number higher and the opposite suit of the highest on
the Move stack. If it is, it moves what's at the pointer to the Move
stack. If not, it makes an annoyed tone and whatever is in the Move
stack is put back where it came from (the memory registers where the
cards came from won't be cleared until after a legal move is made, so
the computer can tell where to return the cards to). If the pointer is
over where the Aces go, it checks to see if there is one card in the
Move stack--if not, illegal move. If something is in the Move stack,
it check to see if that Ace stack it is pointing to has been started
yet. If it has, it compares the card on the Move stack with the suit
and number of the Ace pile being pointed to and moves the values
around.
I'm wondering if this is too much to put in that space of time
between when the computer starts the VBLANK and it hits the imagery
seen on TV.
That's the problem for Solitaire, and it gets more complicated
with a game like Columns. To make a long idea short, I am envisioning
a series of 208 registers, two spots for each square in the 8 by 13
well. One of the pair would tell if there is a jewel there, the other
will denote it's color. Since the idea is to match the colors in three
in a row or more, all I can imagine is the computer comparing each
individual square in each of four directions by it (Starting with the
left jewel on the row, it would move right, comparing the jewel on the
immediate right, right-down, down, and down-left.) If it registers a
match, it will check the next one in that line to see if there are
three of more in a row.
This has me concerned that it will slow the computer down as it
checks all the jewels. I'm also wondering how I would get the computer
to keep it's directions straight ("No, no! Go to the next in line,
don't change direction!") and how it would tell what spots had matching
jewels that need to be removed. I can't just blank those memory
locations, because the scoring is different if six jewels are removed
(two sets of three) or six jewels are removed (six of the same color).
Of course, once those are removed, it checks for matches once the
jewels fall to fill in the holes.
I'm having trouble seeing how to make this work for the Atari
without slowing it down, screwing up the count, whatever. Is this the
best, most efficient way to do it? If not, what is? And if this is
the best way, am I executing so many instructions that the computer
can't run the program properly and keep count and the whole thing is
doomed?
Thank you for letting me run on so long. I know return you to
your regularly scheduled e-mail.
Sincerely,
Pete Holland Jr.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
