Zombie Survival Horror game

[Piggles]

 

EDIT UPDATED 16 SEPTEMBER 2006

 

Ladies and gentlemen, it is with great entheusiasm that I present to you the next version of my zombie survival horror game. I'm also looking for advice on a problem, if you have the time.

 

In this version, the zombies move randomly until you're within a certain range, and then they're supposed to move toward you. Sometimes they will move toward you, but other times they'll dance around randomly even when you're right next to them. So I'm sure I missed something in my code, but I'm not exactly sure what, even after much study. So I post the code snippet for my zombie movement logic below, and attached the full code and binary. All I've noticed is that sometimes I have to move the ball a little bit and somehow they figure out to move toward you.

 

You can explore the map. Currently you are in a blank field in which I'll be adding trees/obstacles later. Go left one screen and you'll see a house. Enter the door of the house and you can explore the house. There's nothing there but a few rooms. The map has several houses and a wall around the town. Clearly my inspiration was Adventure, but imitation I suppose is the best compliment.

 

Below, the t variable is the game timer. On turn 1, player0 moves. On turn 2, player1 moves.

 

moveZombie
d = 0
rem q and r will be our temporary y and x coordinates respectively
rem s will be our random number holder
rem zombie0 will move on turn 1 and the zombie1 on turn 2

if t = 1 then q = player0y
if t = 1 then r = player0x
if t = 2 then q = player1y
if t = 2 then r = player1x

rem find distance from selected zombie to ball
if q > bally then q = q - bally
if q <= bally then q = bally - q
if r > ballx then r = r - ballx
if r <= ballx then r = ballx - r
rem if close to ball, move toward ball, else continue onto random movement
if q < 40 && r < 60 then goto skipzrnd

rem random movement until close enough to pursue
rem bits 0 up 1 right 2 down 3 left
s = rand
if s < 64 then d = d | %00000001
if s < 128 && s > 64 then d = d | %00000010
if s < 192 && s > 127 then d = d | %00000100
if s <= 255 && s > 191 then d = d | %00001000

rem Now that direction is selected, load the moving zombie's coordinates into q and r
gosub assignQR
goto directMove

skipzrnd
rem reuse q and r as y and x coordinates for movement

gosub assignQR

rem chase the ball sprite
rem bits 0 up 1 right 2 down 3 left
if q > bally then d = d | %00000001
if r < ballx then d = d | %00000010
if q < bally then d = d | %00000100
if r > ballx then d = d | %00001000


directMove

rem Now actually move the zombie

if d{0} then q = q - 1
if d{1} then r = r + 1
if d{2} then q = q + 1
if d{3} then r = r - 1

skipDirect
if t = 1 then player0y = q
if t = 1 then player0x = r
if t = 2 then player1y = q
if t = 2 then player1x = r
goto doneZombie


assignQR
if t = 1 then q = player0y
if t = 1 then r = player0x
if t = 2 then q = player1y
if t = 2 then r = player1x
return 

 

 

[edit old message below]

I'm working on AI for a zombie survival horror style of game.

 

The zombies will move toward you (you being the ball), and if obstructed, will move either horizontally or vertically to get around a wall. Very simple AI. But then again, Zombies are dumb.

 

In my original version, the zombie will move as desired, but once I insert a timer to move the zombie only every three loops through the program, it seems to get stuck on the walls. So either my AI just looks like it works, or it does work but somehow I break it when I delay the zombie from moving every loop. Please check out the attached binaries for an example of what I mean. My goal is to have the zombies move slower than the player.

 

If you have any suggestions, please tell me what my problem is! I've tried drinking lots of coffee and eating bread and butter, but even those powerful mental stimulants have not availed me.

 

In the code below, you can comment out "goto moveZombie" and uncomment "if t = 2 then goto moveZombie" and recompile.

 

The two binaries are labeled as with and without the timer.

Zombies.bas

zombies.bas.bin

Edited September 16, 2006 by Piggles

[Piggles]

Incidentally, I just updated my profile with an avatar. If someone else is using an Oink pig for an avatar, please do tell me. I'm pretty sure I haven't seen one, but I don't want people getting confused by seeing someone else's name on the same image.

[+atari2600land]

I don't know if this will help or not, but based on your problem, I'm going to make a simple game about swatting flies. Here's how I got my fly to move randomly:

 

110 player1:
 %001100
 %111111
 %101101
 %111111
 %001100
end
120 w=rand
 if w<127 then w=1
 if w>127 then w=2
130 z=rand
 if z<127 then z=1
 if z>127 then z=2
140 COLUP1=0 : COLUBK=128 : NUSIZ1=$05
150 if w=1 then a=a+3
 if w=2 then a=a-3
 if z=1 then b=b+1
 if z=2 then b=b-1
155 if b<10 then b=10
 if b>80 then b=80
 if a<40 then a=40
 if a>150 then a=150
160 player1x=a : player1y=b
170 drawscreen
180 goto 120

 

Yes, I number my lines. Hope this helps, although it'll be a little too shaky for a zombie, though.

Edited September 11, 2006 by atari2600land

[Piggles]

I like your idea. Perhaps I can instead of trying to make the zombie move around objects, I could have it move randomly, and then check occasionally if there's a clear path and move straight toward my ball-man again. Thanks for the sugestion!

 

There's nothing wrong with line numbers!

[Piggles]

It seems to me that the best way to deal with this is to use a little asm and check the playfield bits. Ugh. Well, for the greater glory of flesh eating Zombies and Atari, I'll have to check it out.

[SeaGtGruff]

It seems to me that the best way to deal with this is to use a little asm and check the playfield bits. Ugh. Well, for the greater glory of flesh eating Zombies and Atari, I'll have to check it out.

I agree that for what you want to do, checking the playfield pixels is the way to go, but you shouldn't have to use any asm for that. I'll see if I can throw something together.

 

How does this sound: The zombies wander around randomly unless you get within a certain distance of them, then they sense you and come after you?

 

MR

[Piggles]

You know, that's a good idea. I think the random movement would help get the silly things around obstacles and then close the distance when you're close enough to see or smell.

 

[EDITED]

 

PFRead!!!! I forgot all about that function! I'm so silly! Thank you MR!!!

Edited September 13, 2006 by Piggles

[Piggles]

I just realized that it would've been better to just post the new info as a reply rather than edit the original.

 

I forgot to mention, if you stand completely still at the start of the game, you'll notice that player0 on the left will attack you but for some reason that eludes me, player1 on the right will abort it's approach just before it gets to you. If you move around, they seem to get "confused". Sometimes they'll approach directly, other times they'll just dance around. I set the range for their attack to be a long distance so I can more easily demonstrate the weirdness of the result.

[SeaGtGruff]

I just realized that it would've been better to just post the new info as a reply rather than edit the original.

If you edit a post at the top of a post, to change any info or replace some attachments with newer versions, it's a good idea to post a note at the bottom of the thread, as you've done here.

 

I forgot to mention, if you stand completely still at the start of the game, you'll notice that player0 on the left will attack you but for some reason that eludes me, player1 on the right will abort it's approach just before it gets to you. If you move around, they seem to get "confused". Sometimes they'll approach directly, other times they'll just dance around. I set the range for their attack to be a long distance so I can more easily demonstrate the weirdness of the result.

I haven't studied your new code yet, but I have a few initial comments.

 

(1) I really like what you've done so far, especially the fact that it looks like it will be a sort of adventure game (my favorite genre).

 

(2) I wonder if you could vary the houses a bit, because right now there's no way to tell them apart, which makes it harder to tell where you are on the map. Some ideas for this are (a) put different landmarks like trees or whatever around the houses, i.e. the houses themselves are the same but have different yards; (b) use different colors for the houses and walls, instead of having everything be purple; © have the front door be on different sides of the house, i.e., in the west wall as now, or in the north wall, or east wall, or south wall; (d) have the different houses be in different places on the screen, i.e., sometimes in the middle as now, or sometimes more to the west, or east, or north, or south, or northeast, northwest, southeast, southwest; (e) have the ground color change, as part of the differences in the yards, i.e., don't always have a black background, but have a different shade of green or brown for each screen; and (f) have houses that are different sizes or shapes. Of course, you can also use some combination or two or more of these suggestions.

 

(3) You could vary the insides of the houses as well, which could be in keeping with the approach used from the previous suggestion. For example, if you make the houses be different colors, then the rooms inside the house would be the same color as the house. If the front door isn't always in the west wall, then the inner floorplan would need to be changed to compensate. And if the houses can be different sizes or shapes, then you could have one room inside for the smallest houses, two rooms inside for the next larger houses, then four rooms, then six rooms, eight rooms, nine, etc., possibly even having some houses (or mansions) with two or more levels connected by stairs. The arrangement of the rooms could vary depending on the shape of the house-- i.e., six rooms could be arranged as either 2x3 or 3x2 depending on whether the house is longer in a N-S or E-W direction. And of course you could change the color of the floors in each room, for different colors of wood floors, stone floors, or carpeted floors. By "room" I mean the whole screen, not the sections made by the different partitions.

 

(4) When you move around from one room to another, it's possible to get stuck in a wall (I got stuck once), presumably because the connecting doorways don't always line up exactly with each other. For the record, the place where I got stuck was when going from the SE room to the NE room; I got stuck in the wall to the left of the door at the bottom of the NE room.

 

(5) When you move from screen to screen, the positions of the zombies on the new screen are the same as the zombies on the previous screen. This makes it possible for the zombies to get stuck inside of a wall or house, and generally detracts a bit from the illusion of having moved to a new screen, especially if both screens look the same (e.g., if both are open fields). If possible, could you give the zombies on each screen their own coordinates? The ultimate solution would be for each zombie to have its own coordinates, and have the offscreen zombies move around a bit, but I doubt if that would be doable (not nearly enough RAM to manage it). The simplest solution could be to have different zombie starting positions for the different screens, and just reset the zombies to the starting positions when you move to a new screen. This could be as simple as having four possible zombie starting positions for a screen-- NW and NE, or NW and SE, or SW and NE, or SW and SE-- then for each location you could specify which combination of zombie starting postions to use for that screen. A possible compromise between the ultimate and simplest approaches might be to remember the zombies' positions for the last location, and if you move back to that screen right away, then restore the zombies' previous positions instead of resetting them to their initial positions. That is, if you move from screen A to screen B, then the game remembers that your previous location was screen A, and it remembers were the zombies were on screen A, then sets the zombies on screen B to their initial starting positions for screen B. If you move from screen B to screen C, then screen B becomes the new previous locatiion, and the game remembers where the zombies on screen B were, and the next time you go back to screen A the zombies are at their initial positions for screen A. But if you move from screen B back to screen A (without going anywhere else first), then the game restores the zombies on screen A back to where they were at the moment you previously left screen A. That way you don't need to save the coordinates for every zombie, just the coordinates for the zombies on the previous screen.

 

(6) The logic for moving the zombies seems to be a little glitchy, aside from the problems you've already mentioned. In particular, if you stand still and let a zombie catch you, it doesn't stop right on top of you, but is slightly NE of you, due to the way bB handles the x and y coordinates of the players versus the missiles versus the ball, which is also affected by the widths and heights of the players/missiles/ball. You might want to adjust your position comparisons slightly so that the zombies end up right on top of the ball, or as close to that as possible, by adding to or subtracting from the numbers a little bit during the comparisons. For example, right now, since the zombie's head ends up being a good bit taller than the ball's height (when they're "at the same y coordinate), it's possible for a zombie to get stuck on an E-W wall when moving toward the player (if the ball is positioned up against the south side of the E-W wall).

 

(7) As I said, I haven't studied your new code yet-- and I haven't had a chance yet to post some code for checking the playfield pixels during the movement routines-- but it looks like you might still be using the collisions instead of using pfread? If you can get the movement glitches worked out by using pfread, that should help take of the "stuck in the wall" problem mentioned in (6).

 

Anyway, good job so far!

 

MR

[MausBoy]

Fantastic! I really like what you've done so far. I think you've picked a great theme, and the fenced in city is cool. One suggestion though - use no_blank_lines.

[Piggles]

Thank you first of all for your kind words and advice.

 

I haven't studied your new code yet, but I have a few initial comments.

 

(1) I really like what you've done so far, especially the fact that it looks like it will be a sort of adventure game (my favorite genre).

 

(2) I wonder if you could vary the houses a bit, because right now there's no way to tell them apart, which makes it harder to tell where you are on the map. Some ideas for this are (a) put different landmarks like trees or whatever around the houses, i.e. the houses themselves are the same but have different yards; (b) use different colors for the houses and walls, instead of having everything be purple; © have the front door be on different sides of the house, i.e., in the west wall as now, or in the north wall, or east wall, or south wall; (d) have the different houses be in different places on the screen, i.e., sometimes in the middle as now, or sometimes more to the west, or east, or north, or south, or northeast, northwest, southeast, southwest; (e) have the ground color change, as part of the differences in the yards, i.e., don't always have a black background, but have a different shade of green or brown for each screen; and (f) have houses that are different sizes or shapes. Of course, you can also use some combination or two or more of these suggestions.

 

I like your idea. Everything is purple at the moment until I work out the rest of the game. Then again, given the limitations of the hardware being emulated, I should figure out what details are going to be on each screen before I have to start chopping game play to make the game presentable. I hoped to include a game timer that would cause the game to go from day to night. So a green grass background with a brown house by day, for example, and a darker color with black background for night. At night, the player0 and player1 would be invisible until you were almost on top of them, and finding the lamp object would allow you to see them from a distance. I considered having dark houses and lighted houses.

 

Perhaps it would be helpful if I defined the end goal, and make sure I can include all the necessary eye candy to make it attractive. You're trapped in town. The government has sealed it off to prevent the zombies from spreading. The town will be nuked in X game hours. If you can find the parts of the CB radio and call for a rescue before the time is up, you win. There's a couple weapons in town you can use. You can fight with your hands at first, and then find an axe. There's a gun too. The hands and axe would work like the whip in Raiders of the Lost Ark: a missile with a very short range. The gun will cross the whole screen. There should be a lamp for night time and three parts for the radio (like in ET).

 

(3) You could vary the insides of the houses as well, which could be in keeping with the approach used from the previous suggestion. For example, if you make the houses be different colors, then the rooms inside the house would be the same color as the house. If the front door isn't always in the west wall, then the inner floorplan would need to be changed to compensate. And if the houses can be different sizes or shapes, then you could have one room inside for the smallest houses, two rooms inside for the next larger houses, then four rooms, then six rooms, eight rooms, nine, etc., possibly even having some houses (or mansions) with two or more levels connected by stairs. The arrangement of the rooms could vary depending on the shape of the house-- i.e., six rooms could be arranged as either 2x3 or 3x2 depending on whether the house is longer in a N-S or E-W direction. And of course you could change the color of the floors in each room, for different colors of wood floors, stone floors, or carpeted floors. By "room" I mean the whole screen, not the sections made by the different partitions.

 

I do like the idea of varying the style of houses and the colors. I wonder how many different houses would be enough to keep things interesting? With but a few items, I wonder if perhaps including such things as food to keep you going or first aid kits to cure zombie bites might be incentive to explore mansions, houses and hovels. With bankswitching, there's pleanty of ROM for maps and tables for item placement.

 

(4) When you move around from one room to another, it's possible to get stuck in a wall (I got stuck once), presumably because the connecting doorways don't always line up exactly with each other. For the record, the place where I got stuck was when going from the SE room to the NE room; I got stuck in the wall to the left of the door at the bottom of the NE room.

 

Thank you! I fixed that but have not yet uploaded it.

 

(5) When you move from screen to screen, the positions of the zombies on the new screen are the same as the zombies on the previous screen. This makes it possible for the zombies to get stuck inside of a wall or house, and generally detracts a bit from the illusion of having moved to a new screen, especially if both screens look the same (e.g., if both are open fields). If possible, could you give the zombies on each screen their own coordinates? The ultimate solution would be for each zombie to have its own coordinates, and have the offscreen zombies move around a bit, but I doubt if that would be doable (not nearly enough RAM to manage it). The simplest solution could be to have different zombie starting positions for the different screens, and just reset the zombies to the starting positions when you move to a new screen. This could be as simple as having four possible zombie starting positions for a screen-- NW and NE, or NW and SE, or SW and NE, or SW and SE-- then for each location you could specify which combination of zombie starting postions to use for that screen. A possible compromise between the ultimate and simplest approaches might be to remember the zombies' positions for the last location, and if you move back to that screen right away, then restore the zombies' previous positions instead of resetting them to their initial positions. That is, if you move from screen A to screen B, then the game remembers that your previous location was screen A, and it remembers were the zombies were on screen A, then sets the zombies on screen B to their initial starting positions for screen B. If you move from screen B to screen C, then screen B becomes the new previous locatiion, and the game remembers where the zombies on screen B were, and the next time you go back to screen A the zombies are at their initial positions for screen A. But if you move from screen B back to screen A (without going anywhere else first), then the game restores the zombies on screen A back to where they were at the moment you previously left screen A. That way you don't need to save the coordinates for every zombie, just the coordinates for the zombies on the previous screen.

 

Thank you again! The zombies get trapped in walls from screen to screen again because it's unfinished. All your ideas are fantastic, and I think I'll go with the corner start positions and see how that works.

 

(6) The logic for moving the zombies seems to be a little glitchy, aside from the problems you've already mentioned. In particular, if you stand still and let a zombie catch you, it doesn't stop right on top of you, but is slightly NE of you, due to the way bB handles the x and y coordinates of the players versus the missiles versus the ball, which is also affected by the widths and heights of the players/missiles/ball. You might want to adjust your position comparisons slightly so that the zombies end up right on top of the ball, or as close to that as possible, by adding to or subtracting from the numbers a little bit during the comparisons. For example, right now, since the zombie's head ends up being a good bit taller than the ball's height (when they're "at the same y coordinate), it's possible for a zombie to get stuck on an E-W wall when moving toward the player (if the ball is positioned up against the south side of the E-W wall).

 

Fixed the coordinates stuff. Attached is an earlier version with one zombie. The logic behind random vs chase movement is essentially the same as what I've got now.

 

 

 

(7) As I said, I haven't studied your new code yet-- and I haven't had a chance yet to post some code for checking the playfield pixels during the movement routines-- but it looks like you might still be using the collisions instead of using pfread? If you can get the movement glitches worked out by using pfread, that should help take of the "stuck in the wall" problem mentioned in (6).

 

I still would like to get some semi-intelligent movement in the zombies. I hoped to achieve something similar with two zombies. As I've knocked my head on that a bit, I've went on with the map movement and other bits but it'll hopefully be done soon. It seems that if I were to use playfield pixel checking, I would first figure the locations of said pixels, and then based on the x and y coordinates of the zombies, check the adjacent pfpixels if they're on.

 

In a rogue-like program I wrote a while back, I used a line of sight routine that would look for a clear line of sight between objects. If obstructed, it would pick a location that would have a clear LOS to the desired destination and go there instead. If not available, repeat n times, n being whatever you have stack memory for recusive functions. The problem here I think is time. I doubt (but am not certain) that the vcs has the juice to do even that simple path finding and have any clock cycles left for the game.

zLoc4.bas

zLoc4.bas.bin

[Piggles]

I updated the zombies.bin to make the zombies chase a point slightly below and left of your real coordinates. Fixed the room in the house.

[Piggles]

Fantastic! I really like what you've done so far. I think you've picked a great theme, and the fenced in city is cool. One suggestion though - use no_blank_lines.

 

 

Thank you for the compliments!

 

I made the fenced city because I didn't want to code in a test for being at the edge of the map. That's one if-then for each screen place on the edge of the map. No thank you! I was conscientious about making too many unnecessary calculations and tests. One can always throw in another drawscreen command if short on cycles, but I preferred to be thrifty in my code. And then it provided a good story plot.

 

I like your suggestion about no blank lines, because it would make the scenery that much more attractive. However, I think I may need access to missile1. I hoped to have random missile fire at the edges of town coming from the police/army/whoever stationed there to contain the zombies. However, if that idea doesn't add any substantive value, I'd be more than glad to trade my missile for prettier graphics.

[SeaGtGruff]

Okay, I downloaded your latest code, and have a few more comments.

 

(1) The E-W wall in the NW corner of town doesn't line up with the E-W wall on the other screens, so if you're in the NW corner and head E while hugging the wall, you get caught in the wall on the next screen. The walls do line up correctly on all of the other screens.

 

(2) The E-W wall in the NE corner of town goes off to the E, which is different than the walls in the other corner screens. For all I know, this could be by design, but the fact that it's different than the way the other corner screens are drawn makes it look like a bug.

 

(3) If the wall was put up around the town to keep the zombies from escaping, then there probably shouldn't be any zombies outside the walls. If or when you define specific starting coordinates for the zombies on each screen, you might want to make sure that the zombies on the screens with a wall are positioned inside the wall.

 

(4) It might be good to move the walls further outward on the edges and corners of town, so there's more room to move around on the town side of the wall.

 

(5) In the house, when you go through the E door in the first room, you end up in the middle of the next room, instead of just through the dorrway on the W side of the next room.

 

MR

[Piggles]

Hi folks I've been out of the loop for months. I found some .bin and .bas files for the zombie game I emailed to myself in archive. I must admit both that I bit off more than I could chew with this project and that some life priorities have changed and I will not finish the game. Therefore, if you get the motivation to make a zombie game, you may edit my code, use my code, copy my idea, do whatever you like. Consider my code public domain.