Adventure-type game

[+atari2600land]

After seeing Reventure and Piggles's "Adventure"-type game, I decided to try my hand at my own. The result so far is a very interesting Adventure-type game.

 

the story:

In I Land, the letter I's were very peaceful. Then, the G's started to invade. This is a lowercase I's quest to defeat the G invaders and restore peace to I land.

 

Weird, huh? At the title screen, the kid I's are hanging around their father. Then, when you press Reset, the big huge G comes in and the little I's get scared and run off. The game begins.

 

When you get to the screen where you first get the magic shield by touching the green box, I've accidentally made a neat thing when you press down, you can't go through the playfield. I've tried to make it do the same thing when pressing up and right, but to no avail. Maybe I can get some help. It's at lines 336-337 (the explanation that I can't figure out may be a little before that.) If I can make this work, I'll hold off all other projects and work on this one because I think this iis really cool.

i.bas

[SeaGtGruff]

When you get to the screen where you first get the magic shield by touching the green box, I've accidentally made a neat thing when you press down, you can't go through the playfield. I've tried to make it do the same thing when pressing up and right, but to no avail. Maybe I can get some help. It's at lines 336-337 (the explanation that I can't figure out may be a little before that.) If I can make this work, I'll hold off all other projects and work on this one because I think this iis really cool.

Your problem is the way you're using the collision function.

 

The collision latches are set when the objects are drawn, so you can't update the player's x and y coordinates and immediately check for a collision-- first you must draw the screen with the player's new position, so the 2600 can determine if there was a collision.

 

What I did in my Reventure WIP was to use x and y direction variables to update the player's x and y coordinates, instead of setting the player's x and y coordinates directly. That way, I could check for a collision as soon as the screen was drawn, bump the player back (by *subtracting* its x and y direction variables from its x and y coordinates) if there was a collision, then read the joystick, set the new values of the direction variables, update the player's coordinates (by *adding* its x and y direction variables to its x and y coordinates), and go back to the beginning of the loop, as in the following example:

 

loop
  drawscreen
  rem * if player0 collided with the playfield, bump player0 back
  if collision(player0,playfield) then player0x=player0x-a : player0y=player0-b
  rem * clear the direction variables
  a=0 : b=0
  rem * set the x direction variable based on the joystick
  if joy0left then a=255 : rem * 255 equals -1
  if joy0right then a=1
  if joy0up then b=255
  if joy0down then b=1
  rem * update the player's position
  player0x=player0x+a
  player0y=player0y+b
  goto loop

A different approach would be to convert the player's coordinates into equivalent pfpixel coordinates, use the pfread function to see if the player's position overlaps the playfield, and adjust the player's position accordingly. However, that's a little more work, especially if the player is moving by 1-pixel increments, because then you'd probably need to check up to four pfpixels using pfread.

 

I don't have time right now to examine your code in detail and suggest specific modifications, but if you study the example above, it should help you figure out the collision method. I see you're using a for the player0x coordinate, and b for the player0y coordinate, so you'll need to change the way a and b are used. In some places you'll need to replace a with player0x, and replace b with player0y; but in other places you'll need to change the values you're setting a and b to. I might be able to give further assistance later tonight or tomorrow, but I can't make any promises, because I'm getting ready to go on vacation, and I'm trying to make some headway on a project before I leave.

 

MR

[+atari2600land]

Thanx again, Mike! So, what do you all think? Should I keep working on this?

i2.bas.bin

[SeaGtGruff]

Thanx again, Mike!

You're welcome! By the way, you might want to add the changes to the first screen, too, to keep the "i" from being able to move through the top and bottom walls.

 

So, what do you all think? Should I keep working on this?

I have two responses to that.

 

(1) If you're enjoying working on it, then keep at it, regardless of what anyone else thinks. And even if you aren't too pleased with the final game, you'll be gaining valuable learning experience that you can use in making other games.

 

(2) I'd like to see where this goes. For one thing, the storyline-- i.e., the characters in the game-- is very different and creative. And for another thing, the lack of left and right walls on the two screens suggests that there are more screens to explore.

 

I don't know how much you know about programming adventure games, but looking at your code (in this and other games that you've written), it looks like you tend to code for a screen, then jump to another section of the program when the screen changes, and code for the new screen, etc., so that you end up with many different drawscreen loops in your program. This isn't a very efficient way to code the screens, because it uses up more ROM than you need to. If you want to program games that have multiple screens-- especially adventure games-- you should look into creating one main drawscreen loop, and then finding ways to change the screen without having to create new loops for each new screen, such as by using arrays and subroutines. For example, here is an example I just wrote that demonstrates how you could use a single loop, plus several arrays, to move around a bunch of different rooms. There's no point to it yet, no goals except to find your way around.

 

There are six different arrays-- one to store the shape of each room (room_shape), one to store the room you end up in if you go north from each room (room_north), one for east (room_east), one for south (room_south), one for west (room_west), and one for the color of each room (room_color). The main loop-- which is the only loop-- moves the player around with the joystick, changes rooms if the player moves through an exit, draws the screen, and bounces the player off the walls. There are subroutines for bouncing the player off the walls, changing rooms in each of the four directions, and drawing the shape of the new room.

 

You're welcome to borrow and modify anything in this example, but when you're studying it, there's one thing you need to be careful of. In several cases I do a gosub, but instead of doing a return from that routine, I goto a different routine, and maybe even goto another routine after that, and then I eventually return from one of the routines, which takes me all the way back to where the original gosub was. This can be a dangerous (i.e., difficult to debug) way of doing things, but I did it to keep from having a lot of nested gosubs, for two reasons: (1) batari BASIC doesn't have a lot of stack space for gosubs and returns; and (2) every gosub/return pair takes 12 machine cycles to process, so using a lot of nested gosubs can take up a lot of processing time, and there usually isn't much processing time available on the Atari 2600.

 

If you do decide to use the sort of techniques that are demonstrated in this example, don't be afraid to toss out your current code and start a new version of the game from scratch. Believe me, I've done that many times with my own programs (games or otherwise). It's pretty typical to start writing a program, realize that the way you're doing it isn't going to work well, and then start over using a different approach-- sometimes again and again, until you hit on an approach that works best. As a case in point, when I started working on my current Atari 2600 project, I had to scrap and revise my code three or four times until I found a workable solution.

 

Anyway, I'd like to see you continue your game, and expand it, because your basic storyline so far is so different. I'm leaving the country in a couple of days to go on vacation, and I don't really expect to have access to a computer (although who knows, I might get lucky), so after tomorrow I probably won't be able to offer any more assistance or suggestions for a week or so. If you have any more questions for now, try to ask them by tomorrow night.

 

MR

 

move_around_rooms.bas

move_around_rooms.bas.bin

[gambler172]

Thanx again, Mike! So, what do you all think? Should I keep working on this?

Hi Chris

yes,please continue,i would like to see a complete game.Something like "Adventure".

greetings Walter

[mos6507]

This has a lot of potential.

[+atari2600land]

Thanx for the input. I'll keep working on it, although I'll have to think about the type of thing I'll put in next. Like maybe a giant letter R to fight or something?

[+atari2600land]

Here's the latest build. After consideration, I thought at some point, I think the lowercase i should always have the shield with him (pure programming laziness on my point), so how could I make i have the shield with him at all times? Requiring him to have his shield with him to get past a certain point. Hence the wall at the end. If you don't have the shield and you run into it, you get bumped back to the beginning of the screen, and if you do have the shield and it touches the wall, the wall disappears. At that point, all I have to do is program the following:

player0x=a : player0y=b : ballx=a+15 : bally=b

without having a variable to tell whether the lowercase i has the shield or not, so I could switch that variable to tell something else (which doesn't matter, since I have a whole bunch of variables to use.) I have an idea for a different screen, but I don't know how to do it (I think I need a quick lesson about the function pfread.) See, what I want to do is have a giant G made out of pfpixels and the object is to get rid of it pixel by pixel with the shield. I think that would be cool.

i2.bas.bin

[Atari_Elite]

crazy!