12 replies to this topic

[Retro Archaeologist]

I was planning on making a kind of clone out of Night Stalker but an idea hit me, why do somthing that already exists ?.

So i have changed and decided to do somthing diffrent but familiar, i want to take Infiltrate game ideas and combine them with other elements from Airlock and earth world.

It would be setup like this:
you would start off in a fourway intersection, each of the four way would lead to another "room" as it were and in which you would avoid monsters in the maze or shoot them to get to the exit on the other side.
once there that would lead to another room setup like normal infiltrate game play but instead of getting the plans twice you get them once. you would repeat this proccess for the other three directions to get the other three pieces of the plans. you would be in an Escape area like airlock's first level. but once you reach the top your put in another level using Inflitrates game play again only this time you get the key at the bottom and work your way to the door at the top in order to Escape and win the game.

Now i know this sounds like it might be impossible to do but maybe if kept it down to just 2 Enemies per area like in the original game of infiltrte and night stocker then the rest should be easy since i would be the only thing moving on the screen unless i am in an area with enemies. and i looked at the infiltrate game and i think most of the game's playfiled is just Playfiled pixles (Elevators, floors and Documents) but i may be wrong.

I am starting work out on paper how this should go, I have been studieing the Stella programmers manual and i think if i stick to reasonable goals and limits of the hardware it should be possible. and do not have to worry about the score since the bBasic Kernel takes care of that for me.

now would it be better if the game ends, after you get all four parts of the plans and make it to the top or would it be better if the game looped and changed colors or indicated a level increase somehow and just got harder as was common with most 2600 games of the era?.

my only concern is i do not think i can cram it in to 4K, i know about bankswitching but i am not sure how it would work or how to do it i should say.
so please let me know what you think and feel free to be as harsh and realistic as possible about the idea Critisim of anykind is welcome.

thanks in advance to all those reply.

Edit here is a link to show what i have in mind Map layout it is rather large diagram which is why i did not post directly.

Edit #2: below is a basic story and control setup (controls may change)

Story for 2600 game idea: (no name for the game yet)

the year is 2204 AD and an Alien race known as the salicons have setup a hidden underground
base and are building a weapon capable of destroying your home world Aligon2.
time is running out for your world, the greatest scientific minds of Aligon2 have come
together and built a super spy a Sophistecated Android the most advanced of it's kind
known as CX2600. it's mission is to infiltrate the underground base and get the plans
for the Salicons weapon which are devided in to four sections of the underground complex
you must get all four parts of the plans and Escape via the Teleporter to the upper
level to a Waiting ship. fail to get the plans and Aligon2's fate is sealed.

Controls: Joystick 1

move the joystick forward to move up or jump. (jumping is only available in final area)

move the joystick Downward to move down or Duck. (Duck is only available in area(s) 3,6,9,12)
move the joystick left to move left
move the joystick right to move right
press the fire button on the joystick shoot. (fire is available in all areas except one and final)

Color - B/W switch -- no function
Game select Switch -- no function
Difficulty switches -- no funtion
Reset switch -- resets game.

More to be written later as the game is programmed

Edit #3: found a good way to do the final level layout based on Airlock only a lot diffrent to Escape and win you'll have to figure out the Combination to get to the
Elevator that leads to the surface from the underground complex. using Tia Paint 1.3 has made the job of level design a lot easier and quicker.
just 2 more level designs to go and i can begin intial pseudo coding of the kernel and variable assignments. then when the new release of bBatari Basic comes out i can begin programming the game and debugging hope to have a demo by March 1st at the latest, feburary 20th at the soonest.

Edit #4:learned some new stuff that might be helpful to me, i should be able to take tia paint 1.3's output and stick in some data statements and use that as a way to draw a more defined playfeild and hopefully get smaller PF pixels than what bBatari basic uses by defualt and hopfully if some of my other assumptions are correct i can get that seprate rooms done and learn a little more ASM as i go.
but either way i am having a lot of fun, just hope no one gets tired of all of my questions that are probably considered not that hard to understand. now if i could just set my mind in to visualizing how these things work i would be set.

RA

Edited by Retro Archaeologist, Thu Dec 15, 2005 11:16 PM.

[batari]

Retro Archaeologist, on Thu Dec 15, 2005 2:32 PM, said:

my only concern is i do not think i can cram it in to 4K, i know about bankswitching but i am not sure how it would work or how to do it i should say.

No need to worry about that in a few weeks - I've modified bB to create 8k, 16k, or even 32k binaries now. I think I've come up with a reasonable way to handle bankswitching, so most of it is transparent to the programmer. Still working on optimizations. But it will ne included in the next release regardless.

[Retro Archaeologist]

batari, on Thu Dec 15, 2005 4:21 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 2:32 PM, said:

my only concern is i do not think i can cram it in to 4K, i know about bankswitching but i am not sure how it would work or how to do it i should say.

No need to worry about that in a few weeks - I've modified bB to create 8k, 16k, or even 32k binaries now. I think I've come up with a reasonable way to handle bankswitching, so most of it is transparent to the programmer. Still working on optimizations. But it will ne included in the next release regardless.

Cool !, okay then i can wait a bit if it means it will be a little easier on me, thanks for the info and for Creating such a great tool.

oh before i forget to ask, will bBatari Basic have a Poke and Peek function ?, like poke 65497,0 kinda command or Equivilent ?.

RA

Edited by Retro Archaeologist, Thu Dec 15, 2005 4:37 PM.

[SeaGtGruff]

batari, on Thu Dec 15, 2005 5:21 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 2:32 PM, said:

my only concern is i do not think i can cram it in to 4K, i know about bankswitching but i am not sure how it would work or how to do it i should say.

No need to worry about that in a few weeks - I've modified bB to create 8k, 16k, or even 32k binaries now. I think I've come up with a reasonable way to handle bankswitching, so most of it is transparent to the programmer. Still working on optimizations. But it will ne included in the next release regardless.

Out of curiosity, will the games that *don't* use the 8K, 16K, or 32K bankswitching (which I assume will be with Atari's method) still compile with everything in one place, or will they be split up into two areas as you'd mentioned doing to get the Atari bankswitching to work?

Michael Rideout

[SeaGtGruff]

Retro Archaeologist, on Thu Dec 15, 2005 5:49 PM, said:

oh before i forget to ask, will bBatari Basic have a Poke and Peek function ?, like poke 65497,0 kinda command or Equivilent ?.

RA

bB already has this, at least sort of. LET (i.e., "=") is the equivalent of POKE, since it works with 1-byte variables, although the only thing you can "poke" into are the variables in RAM or the TIA registers (which don't keep their values). And IF or LET will sort of let you do a PEEK, in the sense that you can use IF to do something if a byte has a certain value, or you can LET a variable equal the value of any memory location. You can also use DIM to help you define the memory locations you're interested in.

So for example, suppose you want to do something like "POKE 198, 7"-- you just say "variable = 7," where "variable" is a RAM variable that resides at location 198. Or "POKE COLUBK, 68" would just be "COLUBK = 68," since COLUBK is the name of a TIA register. You can't "poke" anything into ROM locations, but you can "poke" into registers or into RAM, including any extra RAM that's added by a particular bankswitching scheme (a few of which do add extra RAM).

If you want to do something like "A = PEEK(65500)," you just start out saying something like "dim location=65500" near the beginning of your program (or it can actually go anywhere, even at the end), and then "a = location," which sets the variable a (or A, they are equivalent) to the value in address 65500.

So, there's really no need for PEEK and POKE, they are pretty much necessary only in a BASIC that doesn't have 1-byte variables, whereas bB uses 1-byte variables by default.

Michael Rideout

[batari]

SeaGtGruff, on Thu Dec 15, 2005 10:13 PM, said:

batari, on Thu Dec 15, 2005 5:21 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 2:32 PM, said:

my only concern is i do not think i can cram it in to 4K, i know about bankswitching but i am not sure how it would work or how to do it i should say.

No need to worry about that in a few weeks - I've modified bB to create 8k, 16k, or even 32k binaries now. I think I've come up with a reasonable way to handle bankswitching, so most of it is transparent to the programmer. Still working on optimizations. But it will ne included in the next release regardless.

Out of curiosity, will the games that *don't* use the 8K, 16K, or 32K bankswitching (which I assume will be with Atari's method) still compile with everything in one place, or will they be split up into two areas as you'd mentioned doing to get the Atari bankswitching to work?

Michael Rideout

The games using no bankswitching will compile almost exactly as they did before. The only difference is that the graphics data are placed immediately after the bB code instead of being mixed in. This had to be done anyway because the multisprite kernel needs graphics to be placed stategically, but it also made bankswitching much easier.

[SeaGtGruff]

batari, on Thu Dec 15, 2005 11:34 PM, said:

SeaGtGruff, on Thu Dec 15, 2005 10:13 PM, said:

Out of curiosity, will the games that *don't* use the 8K, 16K, or 32K bankswitching (which I assume will be with Atari's method) still compile with everything in one place, or will they be split up into two areas as you'd mentioned doing to get the Atari bankswitching to work?

Michael Rideout

The games using no bankswitching will compile almost exactly as they did before. The only difference is that the graphics data are placed immediately after the bB code instead of being mixed in. This had to be done anyway because the multisprite kernel needs graphics to be placed stategically, but it also made bankswitching much easier.

That sounds great! I was worried about how it might affect the customization I'd done for M-Network bankswitching, which I think works best if all of bB's code (included routines, as opposed to the programmer's code) can be compiled to occupy the fixed ROM area so it's available to all banks.

Michael Rideout

[Retro Archaeologist]

SeaGtGruff, on Thu Dec 15, 2005 10:31 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 5:49 PM, said:

oh before i forget to ask, will bBatari Basic have a Poke and Peek function ?, like poke 65497,0 kinda command or Equivilent ?.

RA

bB already has this, at least sort of. LET (i.e., "=") is the equivalent of POKE, since it works with 1-byte variables, although the only thing you can "poke" into are the variables in RAM or the TIA registers (which don't keep their values). And IF or LET will sort of let you do a PEEK, in the sense that you can use IF to do something if a byte has a certain value, or you can LET a variable equal the value of any memory location. You can also use DIM to help you define the memory locations you're interested in.

So for example, suppose you want to do something like "POKE 198, 7"-- you just say "variable = 7," where "variable" is a RAM variable that resides at location 198. Or "POKE COLUBK, 68" would just be "COLUBK = 68," since COLUBK is the name of a TIA register. You can't "poke" anything into ROM locations, but you can "poke" into registers or into RAM, including any extra RAM that's added by a particular bankswitching scheme (a few of which do add extra RAM).

If you want to do something like "A = PEEK(65500)," you just start out saying something like "dim location=65500" near the beginning of your program (or it can actually go anywhere, even at the end), and then "a = location," which sets the variable a (or A, they are equivalent) to the value in address 65500.

So, there's really no need for PEEK and POKE, they are pretty much necessary only in a BASIC that doesn't have 1-byte variables, whereas bB uses 1-byte variables by default.

Michael Rideout

Ahh, i see said the blind man , i keep thinking in terms of GW-Basic, this is taking longer to get used to than i thought.

Hey by the way do you know how many pixels tall a single scanline is ?, i have been looking all over this info and have not found it yet.

thanks for the Information on poke and peek equivilents.

RA

[supercat]

Retro Archaeologist, on Thu Dec 15, 2005 10:55 PM, said:

Hey by the way do you know how many pixels tall a single scanline is ?, i have been looking all over this info and have not found it yet.

Unless you use interlacing (very rare on the 2600), a scan line is the smallest unit of vertical resolution. Many Atari 2600 games draw the same thing on pairs of consecutive scan lines, though it's often possible to move things vertically in one-line increments.

[Retro Archaeologist]

supercat, on Thu Dec 15, 2005 11:26 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 10:55 PM, said:

Hey by the way do you know how many pixels tall a single scanline is ?, i have been looking all over this info and have not found it yet.

Unless you use interlacing (very rare on the 2600), a scan line is the smallest unit of vertical resolution. Many Atari 2600 games draw the same thing on pairs of consecutive scan lines, though it's often possible to move things vertically in one-line increments.

okay so like one PC style pixle tall than, i know the scanline is a group of pixels crammed together in a line from left to right, so i thought i might be 1 pixel tall from top to bottom. in any case thats answers that .

RA

[SeaGtGruff]

Retro Archaeologist, on Fri Dec 16, 2005 12:48 AM, said:

supercat, on Thu Dec 15, 2005 11:26 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 10:55 PM, said:

Hey by the way do you know how many pixels tall a single scanline is ?, i have been looking all over this info and have not found it yet.

Unless you use interlacing (very rare on the 2600), a scan line is the smallest unit of vertical resolution. Many Atari 2600 games draw the same thing on pairs of consecutive scan lines, though it's often possible to move things vertically in one-line increments.

okay so like one PC style pixle tall than, i know the scanline is a group of pixels crammed together in a line from left to right, so i thought i might be 1 pixel tall from top to bottom. in any case thats answers that .

RA

You asked the question backwards, it ought to be "A pixel is how many scan lines tall?" And the answer is that a pixel can be any number of scan lines tall, since the graphics features extend from the top of the screen to the bottom of the screen in the sense that once you set them on or off, they stay that way until you change them. So for example, if you set a particular playfield pixel on, it will create a line that extends from the top of the screen to the bottom of the screen, until you set that same playfield pixel off, hence you can make the playfield pixels be 1 scan line tall, or 2, or 3, or 4, etc., up to the height of the screen. At the same time, the player pixels can be left as is or changed, so they can also be any height. And the same holds true of the ball and the missiles. (I'm not referring to bB, which uses a canned kernel that updates the players every 2 scan lines, and updates the playfield every 16 scan lines-- with the exception of PF0 pixels, which stay on or off for the full height of the screen.)

Or, to put it in terms of the way you asked the question, a scan line can be 1 pixel tall, or 1/2 pixel tall, or 1/3 pixel tall, or 1/4 pixel tall, etc., if you see what I mean.

Michael Rideout

[Retro Archaeologist]

SeaGtGruff, on Fri Dec 16, 2005 12:25 AM, said:

Retro Archaeologist, on Fri Dec 16, 2005 12:48 AM, said:

supercat, on Thu Dec 15, 2005 11:26 PM, said:

Retro Archaeologist, on Thu Dec 15, 2005 10:55 PM, said:

Hey by the way do you know how many pixels tall a single scanline is ?, i have been looking all over this info and have not found it yet.

Unless you use interlacing (very rare on the 2600), a scan line is the smallest unit of vertical resolution. Many Atari 2600 games draw the same thing on pairs of consecutive scan lines, though it's often possible to move things vertically in one-line increments.

okay so like one PC style pixle tall than, i know the scanline is a group of pixels crammed together in a line from left to right, so i thought i might be 1 pixel tall from top to bottom. in any case thats answers that .

RA

You asked the question backwards, it ought to be "A pixel is how many scan lines tall?" And the answer is that a pixel can be any number of scan lines tall, since the graphics features extend from the top of the screen to the bottom of the screen in the sense that once you set them on or off, they stay that way until you change them. So for example, if you set a particular playfield pixel on, it will create a line that extends from the top of the screen to the bottom of the screen, until you set that same playfield pixel off, hence you can make the playfield pixels be 1 scan line tall, or 2, or 3, or 4, etc., up to the height of the screen. At the same time, the player pixels can be left as is or changed, so they can also be any height. And the same holds true of the ball and the missiles. (I'm not referring to bB, which uses a canned kernel that updates the players every 2 scan lines, and updates the playfield every 16 scan lines-- with the exception of PF0 pixels, which stay on or off for the full height of the screen.)

Or, to put it in terms of the way you asked the question, a scan line can be 1 pixel tall, or 1/2 pixel tall, or 1/3 pixel tall, or 1/4 pixel tall, etc., if you see what I mean.

Michael Rideout

Okay, let me see if i have this right:

1 scanline can be as tall as i want it to be ?, so if i have an image that is 8 pixels tall then the scaline will be 8 pixels tall because that is what TIA is drawing at that moment ?.

if i get it wrong, i do not mean to thinking in this way is very new to me.

RA

[Random Terrain]

batari, on Thu Dec 15, 2005 4:21 PM, said:

No need to worry about that in a few weeks - I've modified bB to create 8k, 16k, or even 32k binaries now.  I think I've come up with a reasonable way to handle bankswitching, so most of it is transparent to the programmer.  Still working on optimizations.  But it will ne included in the next release regardless.

That is cool. Since I'm not that great at crunching code, I pretty much ran out of space with that random 'maze' experiment I was working on, but now I'll be able to add more things to it.