# Never got it to work -> sprites and walls

Page 2/2
1 |

I haven't given it much thought yet, but mainly the A.I. I don't want the enemy to follow a fixed path in the maze. The enemy can go up, down, left and right. So I could randomize and create outcomes ranging from 1 until 4. But then the enemy will probably frantically go left, right, up, down without any natural behaviour.

So I'm in search of a way of making the enemy react somehow natural on the maze, but still randomized. And maybe the enemy should even react on the position of the player and move in its direction a little.

Typing the question doesn't immediately solve it, but you're right, Manuel, it does help

Latok, you can use a variable as direction (1 up, 2 down, 3 left, 4 right). When chosing direction you have to check last direction and follow it if it's possible. If an obstacle is in this direction then you can randomize (and checknif it's possible else randomize again). Before randomize you can check if enemy " saw" player (do a check to determine if player sprite is in a range of tiles around the enemy, without a wall that hide it)

Latok wrote:

So I'm in search of a way of making the enemy react somehow natural on the maze, but still randomized. And maybe the enemy should even react on the position of the player and move in its direction a little.

Pyramid Warp (T&E Soft, 1983) uses a very simple but also very effective approach:

• In every frame, checks the available directions of the enemy (i.e.: the directions with no wall).
• If there is only one direction available, moves in that direction (thus handling dead ends). End.
• Otherwise (more than one direction available), removes the opposite of the current direction and then:
• If there is only one direction left, moves in that direction (the enemy is following a corridor). End.
• Otherwise, its a crossroad, and the enemy moves in a randomly choosen direction (that will be never be the opposite of the current direction).

The skull (the enemy of the game that actually chases the player) uses the same approach, but instead of a random direction at a crossroad, the decision is taken based on the relative position of the player.

You can check the annotated disassembled code; particularly lines 2107-... (for the randomized behaviour) and lines 1290-... (for the skull).

A quite interesting article on this topic is Understanding Pac-Man Ghost Behavior.

@dracul:

I would say:

Forget about sprites for now. Just make the game work on paper, which could indeed be by using a 2D array. When the game works on paper, then you merely use sprites as a way to build up the screen. The game itself should work without any screen output though. In your defense: that separate approach (functionality and screen output) is barely ever explained in those old BASIC books, so you won't get all that far with just those kind of books. The advantage of this is that sprites could in theory be replaced by bitmaps later on, and the game engine would still work!

@Wolf
It's absolutely ridiculous that it isn't explained in books about programming MSX-Basic. I've got several lying around over here, but none explains how that works.
They all describe how to put a sprite on to the screen, how to calculate them, how to move them... and that's it!

As I'm just a beginner, it seems to me that the first step is to put the actual sprite on the screen. Learn how to manipulate them... and then the second step being collision with other sprites and environment.

I've tried over and over again in the last few years, to get some basic programming skils... everytime I dropped it for several reasons... But I was indexing all the games that I have... and it appeared to me that several games from the beginning (1983/1984) could have been done in Basic ... and even better than they were done back then... So it got my willing to learn spark on again... So I'm trying... and at this time.. I'm only trying ;-)

You'd best spend some time investigating ON INTERVAL GOSUB, see the wiki here.

The basic idea is that you have a main game timer, e.g. 25 or 30 times per second. Each interval you GOSUB to a sub routine that deals with all the technical game stuff, like player positions, enemy positions, collisions, change of map positions etc. Next you GOSUB to another sub routine that does all the drawing according to all the updated variables. This way, the game mechanics and screen updates are separated.
You could e.g. choose to deal with interval ticks like this:

tick: update game mechanics
tick: update screen
tick: update game mechanics
tick: update screen
tick: update game mechanics
tick: update screen
etc.
You get a frame rate of 25 or 30 FPS (depending on your machine or VDP(10) settings)

All this is timer based. The examples in the old books (I bet you're referring to that sprite/joystick example from A.Sickler?) use a technique called polling.

Polling is easy to understand:
10 a\$=input\$(1)
20 if a\$=chr\$(27) then end
30 goto 10

This runs as fast as possible, there's no timer attached. It also means that if you add more functionality, things get slower and slower. With a timer you enforce a frame rate. You will get this exact frame rate, but with the catch that what you want to do might eventually not fit the time given by this frame rate. A solution then is to lower the frame rate. This means you can do more during each frame, but the overall speed of the game is slower.

thegeps wrote:

Latok, you can use a variable as direction (1 up, 2 down, 3 left, 4 right). When chosing direction you have to check last direction and follow it if it's possible. If an obstacle is in this direction then you can randomize (and checknif it's possible else randomize again). Before randomize you can check if enemy " saw" player (do a check to determine if player sprite is in a range of tiles around the enemy, without a wall that hide it)

Thank you thegeps!

theNestruo wrote:
Latok wrote:

So I'm in search of a way of making the enemy react somehow natural on the maze, but still randomized. And maybe the enemy should even react on the position of the player and move in its direction a little.

Pyramid Warp (T&E Soft, 1983) uses a very simple but also very effective approach:

• In every frame, checks the available directions of the enemy (i.e.: the directions with no wall).
• If there is only one direction available, moves in that direction (thus handling dead ends). End.
• Otherwise (more than one direction available), removes the opposite of the current direction and then:
• If there is only one direction left, moves in that direction (the enemy is following a corridor). End.
• Otherwise, its a crossroad, and the enemy moves in a randomly choosen direction (that will be never be the opposite of the current direction).

The skull (the enemy of the game that actually chases the player) uses the same approach, but instead of a random direction at a crossroad, the decision is taken based on the relative position of the player.

You can check the annotated disassembled code; particularly lines 2107-... (for the randomized behaviour) and lines 1290-... (for the skull).

A quite interesting article on this topic is Understanding Pac-Man Ghost Behavior.

Very interesting! I'm using this concept now. Thank you very much :)

Page 2/2
1 |