First Demo

[Matthew]

I put this together last night. This is the first time I have programmed the 2600.

 

Controls: Press fire to shoot, press fire a second time while the missile is still inside the screen to call the missile back. This currently

only works after the missile has traveled 30 unit away. (might change this later)

 

It's very early days, just a fun project to learn the basics. I want to make the game play to be somewhat original.

default.bas.bin

[+Random Terrain]

Keep plucking that chicken.

[PAC-MAN-RED]

You've gotten the basics down pat I'd say. What's your next step?

 

Illya

Edited April 28, 2011 by PAC-MAN-RED

[Matthew]

What's your next step?

 

Just trying to figure out what's available and what the limitations are.

At the moment I have both players displayed, the two bullets and the ball. The playfield is also defined in static rom.

 

 

Is this generally all I have to work with.? Is it possible to duplicate some of these objects easily with Batari Basic (like player1)

 

Also,is it technically possible to store the entire playfield in RAM?. I'm thinking of making it into a destructible barrier.

If I can't store it in ram, I could make every combination possible in ROM and then just swap the playfields out. But this would use a lot of ROM.

default.bas.bin

[diogoandrei]

hey, nice start! It's really good to go slow but solid steps =)

[SeaGtGruff]

Also,is it technically possible to store the entire playfield in RAM?. I'm thinking of making it into a destructible barrier.

If I can't store it in ram, I could make every combination possible in ROM and then just swap the playfields out. But this would use a lot of ROM.

Even though you use the "playfield:" statement to define the playfield all at once, batari Basic actually does store it in RAM-- unless you're using the multisprite kernel, that is. Before batari (Fred) added the "playfield:" statement, we had to use the "pf draw" commands to draw the playfield with horizontal lines ("pfhline"), vertical lines ("pfvline"), or individual pixels ("pfpixel"). The "playfield:" command just gives you a much easier way to define the playfield's appearance all at once.

 

So, after you declare the playfield in the beginning of your program, you can use the "pfpixel" command to turn individual playfield pixels on or off. You can also use the "pfread" command to peek at a specific playfield location to see whether that pixel is currently turned on or off. Just don't stick your "playfield:" statement inside your loop, or it will keep restoring the playfield each time you loop back!

 

You can check Random Terrain's batari Basic web page if you need to see examples of how to use these commands.

 

Michael

[+grafixbmp]

I found a neat trick with the demo. Because of the animation of the white player graphic, when you move the graphic directly above the blue bar extending across the playfield and contact with it, then move side to side, the player consistently move slower than not contacting it. This is because for the frame that the extention of the ship is not visible allows it to move but when it is visible it counts as a collision and won't move. I think thats a cool bonus.

[Matthew]

"pfpixel" command to turn individual playfield pixels on or off. You can also use the "pfread" command to peek at a specific playfield location to see whether that pixel is currently turned on or off

 

That's great Michael, I will look into this. As the levels get harder, I would like there to be barriers that help the enemy ship. (Like a fortress).

 

I have a lot of ideas for the gameplay, like using the return command to shoot around barriers, destructible and in-destructible moving barriers, just to name a few.

 

I think I have everything I need to make a good game now

 

1)Dynamic playfield

2)Enemy ship, and a bullet to shoot

3)Ball (will make this into an enemy feature, maybe a laser cannon)

4)A player that shoots.

 

I'm thinking this game will be a Yar's revenge type of game....not a copy.

 

The thing that will make or break this game will be the enemy logic/AI.

 

 

I found a neat trick with the demo. Because of the animation of the white player graphic, when you move the graphic directly above the blue bar extending across the playfield and contact with it, then move side to side, the player consistently move slower than not contacting it. This is because for the frame that the extention of the ship is not visible allows it to move but when it is visible it counts as a collision and won't move. I think thats a cool bonus.

 

Yes, I also noticed this. I'm not sure if I will keep it this way, could frustrate some players.

[+Random Terrain]

The thing that will make or break this game will be the enemy logic/AI.

I wonder if any of these links would be helpful:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#links_enemy_ai

[Matthew]

I wonder if any of these links would be helpful:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#links_enemy_ai

 

Nice link, there are a lot of useful functions available. (Like a scoreboard)

 

And I was able to answer one of my questions.

 

Is this generally all I have to work with.? Is it possible to duplicate some of these objects easily with Batari Basic (like player1)

 

NUSIZ0, NUSIZ1

default.bas.bin

Edited April 29, 2011 by Matthew

[yuppicide]

Screen shot pleace.

[Matthew]

 

 

LMAO, just owned myself.

 

I reformatted all my code style, then I got a bunch of compiler errors. Then I started deleting parts of the code (looking for the error).

 

 

 

I should of read this first.

 

Indent!

 

All program statements, data, and sprite/playfield pixel data must be indented by at least one space. (Labels, line numbers, and end must not be indented.)

 

 

 

Feeling stupid .

Edited April 29, 2011 by Matthew

[yuppicide]

Lookin good so far!

[Matthew]

Did a complete re-write of the game engine, added some basic enemy movement and collision detection / animation.

 

I can now easily spawn an enemy...., once updated, i will be able to easily change its behavior.

New.bas.bin

Edited April 30, 2011 by Matthew

[Matthew]

Small update

ShotterTest.bin

[Brian O]

This is coming along nicely. I like the boomerang behavior of the bullets, too.

 

Keep it going.

 

-B