9 replies to this topic

[Random Terrain]

Before I put this in a game, please take a look at it and see if you'd actually like to play a game using this random 'maze':

 demo_maze_2008y_10m_15d_0416t.bin   8K   118 downloads

In this demo, you can bring up a new maze by hitting reset or the fire button. The general maze shape is based on one that atari2600land posted:

http://www.atariage....s...t&p=1590593

Since I'm not good at dreaming up some kind of amazing algorithm that can create a maze using only a few lines of code, I'm forcing the maze into existence by splitting the maze up into three parts (7 random pieces each) and trying to make sure all of the pieces fit. Although parts of the 'maze' will be symmetrical once in a while, it's mostly asymmetrical because I found out that a symmetrical maze of this small size can give you kind of a claustrophobic feeling.

After looking at as many mazes as possible by hitting reset or the fire button, does it look like this is ready? Would you want to play a game in these 'mazes' or do you think I need to adjust something first?


Thanks.

[roland p]

Nice checkerboard-generator
It looks random enough for me.

It seems that some dots are always on and some dots are always off. Could it be modified so that dots are generated too?

Edited by roland p, Wed Oct 15, 2008 4:33 AM.

[jrok]

Random Terrain, on Wed Oct 15, 2008 4:47 AM, said:

Before I put this in a game, please take a look at it and see if you'd actually like to play a game using this random 'maze':

demo_maz...5d_0416t.bin

In this demo, you can bring up a new maze by hitting reset or the fire button. The general maze shape is based on one that atari2600land posted:

http://www.atariage....s...t&p=1590593

Since I'm not good at dreaming up some kind of amazing algorithm that can create a maze using only a few lines of code, I'm forcing the maze into existence by splitting the maze up into three parts (7 random pieces each) and trying to make sure all of the pieces fit. Although parts of the 'maze' will be symmetrical once in a while, it's mostly asymmetrical because I found out that a symmetrical maze of this small size can give you kind of a claustrophobic feeling.

After looking at as many mazes as possible by hitting reset or the fire button, does it look like this is ready? Would you want to play a game in these 'mazes' or do you think I need to adjust something first?

Thanks.

This is cool! It seems just random enough, with each maze being unique but navigatable. One thing that might be cool to add would be to use pfpixel to make an exit appear in a random postipn somewhere along one of the four external walls. Maybe when you pass though it, it could connect you to a new maze... just a thought.

In general, this could be the basis for a really cool pacman-type game. Ms. Pacman used to bother me because I'd be doing much of the same pattern repitition every screen, so even a subtly random element like rearranged portions of the maze could really keep someone on their toes.

[jrok]

You know, this demo brings to mind a question about scanline that's been haunting me lately. When I ran this demo in emulators while tracing scanlines, I noticed that whatever routine draws the random map causing the scanlines to leap suddenly, then return to 262 after the map has been drawn. I'm experiencing the same thing in my own project, when moving between screens. A couple of questions for anyone who can answer them:

1) Is this a problem - That is to say, if nothing in particular is going on your screen when the scanlines fluctuate, would it still cause problems on cartridge? For instance, I have a playfield drawing routine that operates when the player exits the left or right side of the screen. The frame that he exits on runs a DrawRoom subroutine that generates 340 scanlines, and the frame directly before the new pf appears generates only 16 scanlines. Then everything goes back to the constant 262.

2) If it IS a huge problem on cartridge, is there a way to minimize it (short of abandoning the subroutine, of course)?

Thanks,
Jarod.

[Random Terrain]

roland p, on Wed Oct 15, 2008 6:06 AM, said:

Nice checkerboard-generator
It looks random enough for me.

It seems that some dots are always on and some dots are always off. Could it be modified so that dots are generated too?

There are some places where you can't have a wall. You end up with a dead end or a tiny loop with only one way in or out.

jrok, on Wed Oct 15, 2008 9:27 AM, said:

This is cool! It seems just random enough, with each maze being unique but navigatable. One thing that might be cool to add would be to use pfpixel to make an exit appear in a random postipn somewhere along one of the four external walls. Maybe when you pass though it, it could connect you to a new maze... just a thought.

I thought about opening a door similar to Lock 'N' Chase when you meet a certain goal, except the placement of the door would be semi-random.

jrok, on Wed Oct 15, 2008 1:12 PM, said:

You know, this demo brings to mind a question about scanline that's been haunting me lately. When I ran this demo in emulators while tracing scanlines, I noticed that whatever routine draws the random map causing the scanlines to leap suddenly, then return to 262 after the map has been drawn. I'm experiencing the same thing in my own project, when moving between screens. A couple of questions for anyone who can answer them:

1) Is this a problem - That is to say, if nothing in particular is going on your screen when the scanlines fluctuate, would it still cause problems on cartridge? For instance, I have a playfield drawing routine that operates when the player exits the left or right side of the screen. The frame that he exits on runs a DrawRoom subroutine that generates 340 scanlines, and the frame directly before the new pf appears generates only 16 scanlines. Then everything goes back to the constant 262.

2) If it IS a huge problem on cartridge, is there a way to minimize it (short of abandoning the subroutine, of course)?

Glad you mentioned that. I forgot to check. The maze is created in 4 steps, so I just put a drawscreen after each step for the following test demo that just keeps making nonstop mazes and that seems to return a constant 262:

 demo_maze_constant_2008y_10m_15d_1324t.bin   8K   78 downloads

[Robert M]

jrok, on Wed Oct 15, 2008 1:12 PM, said:

You know, this demo brings to mind a question about scanline that's been haunting me lately. When I ran this demo in emulators while tracing scanlines, I noticed that whatever routine draws the random map causing the scanlines to leap suddenly, then return to 262 after the map has been drawn. I'm experiencing the same thing in my own project, when moving between screens. A couple of questions for anyone who can answer them:

1) Is this a problem - That is to say, if nothing in particular is going on your screen when the scanlines fluctuate, would it still cause problems on cartridge? For instance, I have a playfield drawing routine that operates when the player exits the left or right side of the screen. The frame that he exits on runs a DrawRoom subroutine that generates 340 scanlines, and the frame directly before the new pf appears generates only 16 scanlines. Then everything goes back to the constant 262.

2) If it IS a huge problem on cartridge, is there a way to minimize it (short of abandoning the subroutine, of course)?

Thanks,
Jarod.

If the number of scanlines is not a constant 262 (or so), then the TV may lose vertical sync for a frame or two and the image on the screen will jump or roll. Its not a great thing to do, but I have seen many commercial releases that jump/roll at the start of each level.

Cheers!

[jrok]

Robert M, on Thu Oct 16, 2008 6:51 AM, said:

If the number of scanlines is not a constant 262 (or so), then the TV may lose vertical sync for a frame or two and the image on the screen will jump or roll. Its not a great thing to do, but I have seen many commercial releases that jump/roll at the start of each level.

Cheers!

Ah, thanks. I think I get it. So basically, if my scanlines leap while the display is cleared (sprites and playfield not visible), then the roll will probably not be noticeable?

[Robert M]

jrok, on Thu Oct 16, 2008 9:12 AM, said:

Robert M, on Thu Oct 16, 2008 6:51 AM, said:

If the number of scanlines is not a constant 262 (or so), then the TV may lose vertical sync for a frame or two and the image on the screen will jump or roll. Its not a great thing to do, but I have seen many commercial releases that jump/roll at the start of each level.

Cheers!

Ah, thanks. I think I get it. So basically, if my scanlines leap while the display is cleared (sprites and playfield not visible), then the roll will probably not be noticeable?

No that is not correct. Each frame of the television image is expected to 262 scanlines tall. Each frame is divided in to 4 sections: vertical sync (3 lines), vertical blank (37 lines), the visible portion (192 lines), and overscan (30 lines). 3 + 37 + 192 + 30 = 262 scanlines per frame. There are 60 TV frames per seconds for NTSC and PAL60 televisions. NOTE: The number of lines per frame, and frames per second is different for PAL televisions.

If your code does not produce exactly the same number of scanlines for each of those four sections on every single TV frame, then there is a chance the TV image will jump or lose vertical hold. The more your code deviates the more likely it is a jump will occur. Stability with uneven line counts will depend on the intelligence of the television to clean up the bad frames. As an Atari VCS programmer it is ideal to never vary your scanline counts for any of the 4 TV frame sections.

If you are writing pure bBasic code, then your code will run during the overscan section of each TV frame. When you are done with all your code tasks for a single frame, your code must call DrawScreen, and bBasic draws the rest of the TV frame. IF your code takes more time than the 30 scanlines of overscan then the screen will jump or roll.

AS a bBasic programmer you must work out the minimal list of tasks to be done each frame to keep under the time limit.

Cheers!

P.S. There is a way to get some more time to run your bBasic code each frame during the vertical blank period. Check the online docs.

[Robert M]

BTW, I like the demo.

[Random Terrain]

Here's a question for anyone who might read this. Since the 'maze' is so small, I think I can get away with having only one bad guy. And if you have seen this demo, that enemy is stupid and he can find his way to you pretty quickly.

So would you like it if I had only one enemy to a maze, especially if the enemy will have different 'personalities' from one maze to the next? In some mazes he'll be stupid and in other mazes he'll hunt you down with varying degrees of desire. I could also see if I can match personalities to differently shaped creatures or if I stick to only one enemy shape, I can at least change his color based on how nasty he is.