2600 Game Standards from 1987

[2600 Game Standards from 1987]

Thought some of this was a kind of fun read (many may have already read, but this is the first I'd seen it):

 

http://www.atarimuseum.com/ahs_archives/ar...0_Standards.pdf

 

Found that on Curt's atarimuseum site here:

 

http://archives.atarimuseum.com/archives/archives.html

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

0.8. REAL INDY CARS! (Thanks to batari!) Much better driving dynamics.

 

ultindy500_0.8.bas.binultindy500_0.8.bas

 

[Schoolbus]

larger versions

[Schoolbus]

[Schoolbus]

I wrote this a few weeks ago and was going to spend more time on it before posting, but someone might find it fun.

 

The story is that you are a schoolbus driver and there is a storm that took a lot of powerlines down and you have to drive to school without running off the road or into downed powerlines.

 

It is basically currently just a side-scrolling driving game where you get more points by driving faster and longer. Have fun!

 

Plans were to have some kind of kids getting off/on the bus and maybe having to avoid other things besides downed power lines, but I'm not sure when I'll get to it.

 

 

schoolbus0.1.bas.binschoolbus0.1.bas

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

0.7 contains radical changes and is a major step backwards in smoothness and gameplay, but radically different for steering (and saved some space). Direction is tied 1:1 to paddle (so you have to rotate it all the way back around after turning right too far) - this is just temporary to make it easier to drive and figure out the x, y deltas. Changed the way I was doing deltas. Unfortunately, it is pretty jumpy.

 

ultindy500_0.7.bas.binultindy500_0.7.bas

 

One kind of neat trick I used (not sure yet whether it is a good trick or not) is that since I didn't need the persistance of player0x, player0y, player1x, player1y (since I was storing those in car0x, car0y, etc.) I could use them as temp variables. I don't know whether it is affecting collision detection, but that is not a concern for now (until I get driving dynamics figured out).

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

0.6 just had the small changes I mentioned previously (steering more accurate and is less sluggish).

 

ultindy500_0.6.bas.binultindy500_0.6.bas

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

Actually, I think I know what may be wrong with it if it is about car movement and not the actual direction of the car. (If it is about direction of the car though I think the previous fix is the first thing to do probably.)

 

Here is the part of the code that does 0-15 direction to x,y coordinate delta:

setdeltas
if tempvel >= 0 then temp100percentdelta = 0 : temp92percentdelta = 0 : temp71percentdelta = 0 : temp38percentdelta = 0
if tempvel > 1 then temp100percentdelta = 1 : temp92percentdelta = 1 : temp71percentdelta = 1 : temp38percentdelta = 1
if tempvel > 20 then temp100percentdelta = 2 : temp92percentdelta = 2 : temp71percentdelta = 1 : temp38percentdelta = 1
if tempvel > 40 then temp100percentdelta = 3 : temp92percentdelta = 3 : temp71percentdelta = 2 : temp38percentdelta = 1
rem if tempvel > 50 then temp100percentdelta = 5 : temp92percentdelta = 5 : temp71percentdelta = 4 : temp38percentdelta = 2
rem if tempvel > 60 then temp100percentdelta = 6 : temp92percentdelta = 6 : temp71percentdelta = 4 : temp38percentdelta = 2
return

changepos
if tempdir16max = 1 then tempy = tempy - temp100percentdelta
if tempdir16max = 2 then tempx = tempx + temp38percentdelta : tempy = tempy - temp92percentdelta
if tempdir16max = 3 then tempx = tempx + temp71percentdelta : tempy = tempy - temp71percentdelta
if tempdir16max = 4 then tempx = tempx + temp92percentdelta : tempy = tempy - temp38percentdelta
if tempdir16max = 5 then tempx = tempx + temp100percentdelta
if tempdir16max = 6 then tempx = tempx + temp92percentdelta : tempy = tempy + temp38percentdelta
if tempdir16max = 7 then tempx = tempx + temp71percentdelta : tempy = tempy + temp71percentdelta
if tempdir16max = 8 then tempx = tempx + temp38percentdelta : tempy = tempy + temp92percentdelta
if tempdir16max = 9 then tempy = tempy + temp100percentdelta
if tempdir16max = 10 then tempx = tempx - temp38percentdelta : tempy = tempy + temp92percentdelta
if tempdir16max = 11 then tempx = tempx - temp71percentdelta : tempy = tempy + temp71percentdelta
if tempdir16max = 12 then tempx = tempx - temp92percentdelta : tempy = tempy + temp38percentdelta
if tempdir16max = 13 then tempx = tempx - temp100percentdelta
if tempdir16max = 14 then tempx = tempx - temp92percentdelta : tempy = tempy - temp38percentdelta
if tempdir16max = 15 then tempx = tempx - temp71percentdelta : tempy = tempy - temp71percentdelta
if tempdir16max = 16 then tempx = tempx - temp38percentdelta : tempy = tempy - temp92percentdelta
return

 

If you look at that you can see that at slow speed, the x,y deltas are REALLY rough. That is the best I could come up with at the time, because I just didn't have enough variables (and/or space) available to have 2 byte floats. When you're only using 2 cars you can do stuff like store the first byte in the player x coord and only need one variable, but you can't do that with 4 cars without using multisprite kernel, but you can't use paddles with multisprite, so...

 

If I had more variables, the x,y coord changes would definitely be smoother. For now, you have to drive fast as heck to get more realistic movement.

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

but, you run into the problem of the paddle controllers having stops at each end...

 

Right.

 

But, there has to be a way where the two philosophies can be merged... the tight control and response of the original Indy 500 driving controllers, but with the realistic steering the paddle controllers can give you...

 

I don't know the best way to go about this.... but, I do know that the current steering algorithm needs an overhaul. I'll look at the code and see what I might be able to come up with...

 

That would be awesome. It is really hard getting the right feel for it without having actually paddles.

 

I think the problem may be this:

if paddle > 40 then tempdir255maxdelta = (paddle - 38) / 8 : gosub incrdir : return

if paddle < 36 then tempdir255maxdelta = (38 - paddle) / 8 : gosub decrdir

 

I was trying to have a way to keep it "steady" in the middle, but maybe I should make it like this (lowering from 8 to might it turn faster and changed the middle value to not have a "center" range:

 

if paddle > 38 then tempdir255maxdelta = (paddle - 38) / 6 : gosub incrdir : return

if paddle < 38 then tempdir255maxdelta = (38 - paddle) / 6 : gosub decrdir

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

I'm thinking once I'm done with the 4k game, it might also be cool to have a version that has a lot of tracks and better physics. Or maybe someone else could take that on if interested.

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

0.5 released

 

* Has lap count and working lap detection

* Has fuel gauges (lines to left and right of playfield). When fuel runs out, car is slower.

* Got rid of title sequence to save space

* Got rid of flag to use missile for fuel gauge

 

ultindy500_0.5.bas.binultindy500_0.5.bas

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

A bar might be a good way to show how much fuel you have left. When you run out of gas, is the game just over because the car stalls or you get sent back to the starting line with half a tank or a full tank? Since the seem early in the development, I guess you have the time figure out the gameplay.

 

Unfortunately, since there are four players, there is no way to show 4 bars without writing a minikernel (and I'm not quite up to that level yet ). I had originally thought that maybe you would still be able to move but just really, really slow at this point. That way, even though you will probably lose the game, at least you still have a chance and can play.

 

I almost have to code done for the fuel (to use car color) but am having to take chance using temp vars 2 and 3 and lose title sequence. Hopefully playfield collision detection won't screw up again.

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

0.4 released. Steering less sensitive (went from diving paddle difference from center by 5 to dividing by 8 for the 255-based direction delta- don't ask me what percentage difference that is- it is too late today for me to do math), accel/decel more sensitive (2x sensitivity). Changed code to not use temp1-3 (so had to use up 3 more regular vars). It now sets sound and checks for playfield collision 2x as quickly and maybe more accurately (I didn't test to see if it fixed the pf bug yet- let me know if it does).

 

Let me know what you think. You may have to turn up the default paddle delta in Stella to get it to turn quickly enough via keyboard.

 

ultindy500_0.4.bas.binultindy500_0.4.bas

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

I can't remember exactly where I found this, but I believe batari wrote it. I did a quick search on the forums and I couldn't find the original post. It's an indy 500 demo game that has the all the car physics for the car configured just like the original indy 500 game. It works really well - It might be a good example to look at if you want to tweak your game.

 

Great job by the way! Your game is very cool and has great potential.

 

Steve

 

Steve,

 

Thanks for the code from batari. I looked at it and unfortunately it uses 16 variables per player (since I can't reuse player1 and 2 x and y coords since I share player0 and 1 with players 2 and 3), which would mean 64 variables for all 4 cars. If there is some part of it that you think I could reuse or if you think that it is going to suck too bad without bank switching let me know and I'll do what I can. I'll definitely look at it to see what I can use though. I was really hoping to keep it under 4k to try to make it more accessible (isn't 4k the lowest common denominator?).

['pfread' and 16kSC kernel option...]

I'll check on what I'm doing wrong

 

Bob

 

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

 

Also, note you can't use pfread with multisprite kernel.

['pfread' and 16kSC kernel option...]

I'll check on what I'm doing wrong

 

Bob

 

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

Michael designed the pit stop (now I just need to implement a need for it). Curtis did the 4 player colored lap counter. Thanks to Michael, Batari, Curtis, Lord Mike, and everyone else for the advice.

 

I was wondering about what need a pit stop for. How about a fuel gauge that runs out when the players are driving, when a player hits something, like a wall, the fuel gauge loses a bit of fuel. The pit stop is the place to refuel.

 

I do have a question about the track designs. Are you planning more tracks?

 

Decrementing fuel would be good. I'm not sure about how I would indicate fuel and damage (was thinking changing color of car to show that).

 

One of the problems with having more than one track unfortunately is that if I have to worry about where the pit stop or finish line/halfway point are (if they are different for different tracks) it will require more space (and probably at least one more variable or so and some additional code in the selection part of the game that doesn't even exist yet - I might need to drop the title sequence to fit that in). I think I need to get the mechanics of the game figured out before I worry about that, but if I have space I'll definitely try for at least 2 tracks in the beginning. Maybe different tracks could just be released as different games if space were really tight.

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

In other news- I tried to duplicate the playfield bug last week in separate code and determined that the thing that is causing 2 cars to have playfield collision detection issues is my use of temp variables. I don't know what bit(s) it is nor the exact condition that makes this happen, so I'm hesitant to list it as a bug. But it definitely seems to either make it look like player sprite is always colliding or never colliding with playfield. Wish I had more time to look into it. I wish I didn't have to use temp vars but I ran out of regular ones.

A number of functions use temp variables internally. At some point I hope to document them all. If you stick to TEMP4 through TEMP6 you should be fine.

 

Thanks! Will try limiting to those 3!

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

So, I *finally* loaded this up on a real Atari with my Supercharger and real paddles...

 

It looks good, but the steering is still waaaaaay too touchy! The acceleration and deceleration work well, although maybe should be more sensitive....

 

So, basically, cut back on the steering sensitivity and increase the acceleration and deceleration sensitivity and you've got a good thing going!

 

Thanks,

 

Mike

 

Thanks, Mike! Will do!

[Ultimate Indy 500 (0.8 released - Real Indy cars)]

I can't remember exactly where I found this, but I believe batari wrote it. I did a quick search on the forums and I couldn't find the original post. It's an indy 500 demo game that has the all the car physics for the car configured just like the original indy 500 game. It works really well - It might be a good example to look at if you want to tweak your game.

 

Great job by the way! Your game is very cool and has great potential.

 

Steve

Steve,

 

Thanks a lot! Will definitely take a look at it and do what I can! Glad to hear you think it is cool! I kind of thought no one was really interested in it.

 

Batari had some/all of the indy physics in the game that comes with bB (zombie chase). I tried not to look at it in the beginning because I wanted to see what I could do on my own, and later found out that I couldn't really use much of what he had for 4 players in a 4k game because there weren't enough variables. So the physics take a serious hit because of that. If I changed it to a larger bank-switched game maybe it would be more fun. I will do that if people think that is the best direction to get this jump started again. My goal has been previously not to write any game that couldn't be played on a future Atari product that may not support superchargers, so I thought 4k was the best I could do to be safe. Is that right? Also, I don't want to limit who can play them on regular 2600s (for those with croc cart/etc but no supercharger).

 

In other news- I tried to duplicate the playfield bug last week in separate code and determined that the thing that is causing 2 cars to have playfield collision detection issues is my use of temp variables. I don't know what bit(s) it is nor the exact condition that makes this happen, so I'm hesitant to list it as a bug. But it definitely seems to either make it look like player sprite is always colliding or never colliding with playfield. Wish I had more time to look into it. I wish I didn't have to use temp vars but I ran out of regular ones.

[2 Player Adventure]

I tried it today on my emulator and I have a graphic glitch when I start the game using reset:

 

 

It is the part below where the yellow blocks can be seen. On the emulator this part is permanently flickering, but only in this screen. I'm using Stella 2.4.

 

This is just an Info for you

 

Yes, I saw that too in Stella 2.3.5. I think it is either a bug in bB or a bug in Stella. Can anyone figure out why it would be doing this?

 

Figured that flickering out. Had too many sprites on the y=100 coordinate. Here is the latest (interim version with fix and diff maps)

2padv0.5.bas.bin2padv0.5.bas

[2 Player Adventure]

I tried it today on my emulator and I have a graphic glitch when I start the game using reset:

 

 

It is the part below where the yellow blocks can be seen. On the emulator this part is permanently flickering, but only in this screen. I'm using Stella 2.4.

 

This is just an Info for you

 

Yes, I saw that too in Stella 2.3.5. I think it is either a bug in bB or a bug in Stella. Can anyone figure out why it would be doing this?

[2 Player Adventure]

One more thing... the selection (1 or 2) at the beginning is for # of players. The second player plays as the elusive "dot" from the first Adventure, except that the players can see the dot. However, the dragon and eye cannot see the dot player, which makes him good for sneak attacks. The player and dot must leave the room at the same time (so no one gets left behind).

 

The hardest parts about this game are:

* Finding the cross (I may actually hide the cross in a random location in the next version).

* Not getting stuck in an enemy castle/dungeon.

* Shooting the wand in the desired direction.

 

The easiest parts are:

* Killing the dragons and eyes (who would have known killing a dragon would be so darn simple? ) I may hide the staff later on or make them faster to make this harder. In a future version there may be baby dragons, and possibly an large elephant (by request).

 

Anyway... definitely looking for suggestions, so please let me know what you like, don't like, and if you can look at the code and make any suggestions, that would be way totally awesome.

[2 Player Adventure]

Ok, since the game changed a bit from my original plan here is the description:

 

* There is a cross somewhere south or just southwest of the blue castle (starting castle). The quest is to find the cross and bring it back to the castle. If so you win (you currently get killed when you win. If I can fit a win sequence in, I'll definitely add that later).

 

* The black stick with the crook at the top (the staff) just outside of the castle lets you shoot. There is a bug with it that you can just shoot the missile and it stays (somewhat) stationary. If you can figure out what is wrong, let me know.

 

* The wand (stick with big circle at top) lets you teleport. This is only useful currently to help you get out if you are trapped in an enemy castle (which will happen periodically and you have to turn it off/on to restart the game because I didn't have enough space left in 4k to reset. Will fix that eventually.

 

* Dragon and eye will kill you if they attack you long enough.

 

* If you're lucky or crafty you can walk through walls. It usually happens by accident for me. Whenever I've tried on purpose I have a hard time doing it. Walking through walls is a good way to get stuck in a dungeon.

 

Let me know how it goes! Had to switch to non maze rooms for now to save space.

[Cave-In (PAL50/60 versions available)]

Wow! Man this is fun! I just played it a few times and I got through a few brown moving block screens and the rail car screen and got a key and a dot. I couldn't open the door with green walls and then I died in the rail car. Really good job!

 

The monsters are way better looking than last time I played! I like the mosquito when it is really quick and bites you a lot.

 

If you have any more room it might be neat to have a water scene where it is all blue background and you move slowly and there is a fish or octopus or something? It also might be neat to be in a room where shakescreen is always on and there are blocks quickly dropping from the ceiling (really quickly- faster than the slow moving brown block room).

 

Great work!