Jump to content

Recommended Posts

This one is more interesting. It now detects oil barrels. Uses the array SC rather than GCHAR for moving the man (whom I have determined is Bobby Ewing!).

 

10 CALL CLEAR

20 DIM SC(24,32):: ! THIS WILL DETERMINE WALLS & OIL TO COLLECT

30 FOR L=4 TO 19 :: SC(L,16)=1 :: NEXT L

40 FOR L=9 TO 23 :: SC(L,L)=1 :: CALL HCHAR(L,L,36):: NEXT L

50 FOR L=1 TO 20 :: Y=INT(RND*23)+1 :: X=INT(RND*31)+1 :: SC(Y,X)=2 :: CALL HCHAR(Y,X,46):: NEXT L

60 CALL VCHAR(4,16,ASC("$"),16)

70 MAN=42 :: JR=35

80 MX=5 :: MY=5

90 JX=30 :: JY=22

100 TOG=1 :: OIL=0

110 CALL HCHAR(MY,MX,42):: DISPLAY AT(24,1):"Oil";OIL

120 CALL HCHAR(JY,JX,JR)

130 IF SC(MY,MX)=1 THEN 250

140 CALL KEY(0,K,S)

150 IF K=83 THEN IF MX>1 THEN GOSUB 310

160 IF K=68 THEN IF MX<32 THEN GOSUB 340

170 IF K=69 THEN IF MY>1 THEN GOSUB 370

180 IF K=88 THEN IF MY<23 THEN GOSUB 400

190 TOG=-TOG :: IF TOG=1 THEN 120

200 ! MOVE JR

210 CALL HCHAR(JY,JX,32)

220 TX=JX+SGN(MX-JX):: TY=JY+SGN(MY-JY)

230 CALL GCHAR(TY,TX,C):: IF C<>32 THEN 120

240 JY=TY :: JX=TX :: GOTO 120

250 FOR L=1 TO 8

260 CALL HCHAR(MY,MX,MAN):: CALL SOUND(100,-7,1)

270 CALL HCHAR(MY,MX,32):: CALL SOUND(100,-7,10)

280 NEXT L

290 STOP

300 ! MOVE MAN LEFT

310 CALL HCHAR(MY,MX,32):: TEMP=MX :: MX=MX-1 :: IF SC(MY,MX)>0 THEN IF SC(MY,MX)=1 THEN MX=TEMP ELSE GOSUB 430

320 CALL HCHAR(MY,MX,MAN):: RETURN

330 ! MOVE MAN RIGHT

340 CALL HCHAR(MY,MX,32):: TEMP=MX :: MX=MX+1 :: IF SC(MY,MX)>0 THEN IF SC(MY,MX)=1 THEN MX=TEMP ELSE GOSUB 430

350 CALL HCHAR(MY,MX,MAN):: RETURN

360 ! MOVE MAN UP

370 CALL HCHAR(MY,MX,32):: TEMP=MY :: MY=MY-1 :: IF SC(MY,MX)>0 THEN IF SC(MY,MX)=1 THEN MY=TEMP ELSE GOSUB 430

380 CALL HCHAR(MY,MX,MAN):: RETURN

390 ! MOVE MAN DOWN

400 CALL HCHAR(MY,MX,32):: TEMP=MY :: MY=MY+1 :: IF SC(MY,MX)>0 THEN IF SC(MY,MX)=1 THEN MY=TEMP ELSE GOSUB 430

410 CALL HCHAR(MY,MX,MAN):: RETURN

420 ! INCREASE OIL SCORE

430 OIL=OIL+1 :: DISPLAY AT(24,5):OIL :: SC(MY,MX)=0 :: RETURN

I'll offer another non-code design principle that may help others.

 

In my game, Christmas Carol, I use an AI technique based on Pac-Man. It works like this: on every game cycle, the enemy "decides" which way he must go. It does this by re-calculating a path to his target. Now, this path is rather short-sighted; for each available space around the enemy to which it could move, we compute the distance to the target, and the shortest one wins. Each of the surrounding spaces is tested, starting at the top and going clockwise. The sprite position is finally updated, and the entire thing starts again on the next cycle.

 

If you set the player's sprite as the target, then this ensures that your enemy sprite is always tracking and following him.

 

By slightly offsetting the coordinates of the target, say slightly behind or slightly in front of the actual target, you can have different stalking effects, like an enemy that attempts to ambush you from ahead. In fact, this is how the multiple "personalities" of the Pac-Man Ghosts are implemented: one tracks the player, another tracks slightly ahead, etc., essentially closing on the player from two sides.

 

An important consideration is that you may not need to recompute the path on every cycle, but only on specific "decision points." If you consider Pac-Man (and Christmas Carol), since the enemies can only move forward and in a straight line, we only need to recalculate the path when the enemy reaches a junction with more than one potential exits.

 

dZ.

  • Like 2

Actually, the ghost personalities in PAC-MAN were more complicated than just finding a path to PAC-MAN. Your explanation might be a simplification(?) for the sake of brevity, but if you have not read the PAC-MAN Dossier I highly recommend it:

 

http://www.gamasutra.com/view/feature/3938/the_pacman_dossier.php?print=1

 

Actually, the ghost personalities in PAC-MAN were more complicated than just finding a path to PAC-MAN. Your explanation might be a simplification(?) for the sake of brevity, but if you have not read the PAC-MAN Dossier I highly recommend it:

 

http://www.gamasutra.com/view/feature/3938/the_pacman_dossier.php?print=1

 

The personalities of the Ghost were clever and effective, but rather simple in concept. The key is in computing the specific target each one tracked.

 

Yes, my explanation was an oversimplification, although the example of an offset ahead and behind the player's position as targets covers Blinky's and Pinky's seemingly coordinated ambushing tactic accurately, respectively.

 

The Pac-Man Dossier is a fantastic resource, and pretty much what I used as the specification for my Pac-Man port to the Intellivision (reverse-engineering the game from it), which became the basis for my Christmas Carol game. In my game, the Evil Snowman uses Blinky's logic (targeting the player directly), while the Bad Toy uses something similar to Clyde's.

 

dZ.

  • Like 1

Cool. It is nice to know you dug deep when working on your remake. Excellent job! The general perception is that the old coin-op games were "simple". I can't tell you how many times I have seen PAC-MAN suggested as a "starter" game to write when learning to program, albeit this is usually in reference to a present-day environment like Java, a compiled BASIC (Blitz, PureBasic, etc), or something similar. Still, the suggestion that PAC-MAN is an easy starter game reveals the complete lack of knowledge and respect for the amount of complexity that really exists in the classic games.

 

  • Like 2

Hi,

 

In order to do that in XB you'll need VPEEK and VPOKE, which are absent, if I recall correctly.

 

Yes POKEV and PEEV are faster, but I went one step farther and decided RAM is much faster.

What RXB IN THE DARK game did was use LOAD and PEEK in RAM as VPEEK and VPOKE are just as slow as HCHAR or VCHAR are SLOW.

A faster way was to change characters in RAM of lower 8K then on one single command write the entire screen.

 

An example is CALL HCHAR(1,1,32,768) vs CALL HCHAR(1,1,32) vs CALL MOVES("RV",768,8192,0)

ONE MINUTE TEST:

100 CALL HCHAR(1,1,32,768) :: A=A+1 :: GOTO 100 ! A=77

or

100 CALL HCHAR(1,1,32) :: A=A+1 :: GOTO 100 ! A=2386

or

100 CALL MOVES("RV",768,8192,0) :: A=A+1 :: GOTO 100 ! A=754

 

So writing the entire screen at once from RAM is much faster then writing to screen more often many times only a few characters at a time.

When I wrote IN THE DARK it occurred to me that what was the slowest thing in the GAME was updating and checking characters on SCREEN in VDP!

 

As RAM is many times faster then VDP if I wrote the entire screen at once but only when needed to do so it would really speed up the game.

Also as a Sprite was used to move my character it never needed to write and erase the location as it just moved but left behind a invisible for my enemy to follow where it had been.

 

Testing POKEV and PEEKV vs HCHAR and GCHAR:

100 CALL POKEV(0,128) :: A=A+1 :: GOTO 100 ! A=2943

or

100 CALL PEEKV(0,X) :: A=A+1 :: GOTO 100 ! A=2707

or

100 CALL HCHAR(1,1,32) :: A=A+1 :: GOTO 100 ! A=2386

or

100 CALL GCHAR(1,1,X) :: A=A+1 :: GOTO 100 ! A=2366

 

Using this methods was faster then HCHAR and GCHAR but when using MOVES instead and using LOAD and PEEK from RAM was even faster then that!

My main loop doubled in speed after a key press and the enemy also doubled in speed chasing that player.

 

Rich

Joe, - if you're going further with this, like also ultimately compiling with Wilhelm, then please, please change the ESDX control to joystick control.

 

:jango:

 

I'm not sure if I can get it to compile - I tested it some days ago and it crashed on me when it loaded, even though it assembled with no errors .... there /are/ certain commands that we can't use in the compiler, I'm starting to wander if SGN isn't one of them?

No, SGN should be fine. But you got stuff like this - remember only linenumbers after THEN

 

IF MX>1 THEN MX=MX-1 

 

;)

 

Shiiiiiiiiiiit ............... :dunce:

 

 

Actually, thinking about it, I'm pretty sure I did a seperate text-file with the logic in THEN statements branched off to seperate lines .... ah well ... I'll have another go with it later on.

Edited by Retrospect

I've now made it so all logic in THEN statements branch off to separate lines ( I had missed 4 lines )

 

Can we use the AND statement in the compiler, so long as everything after THEN goes to a different line?

 

Example;

1101 IF MY=JY AND MX=JX THEN 1260

Yes, absolutely. I've used AND in my IF statements (in my Shooting Stars).

 

:)

 

In that case, I have not got a clue what is wrong with the damn program. It starts, the title screen, then I press any key, it goes into the game screen, JR sees me, sets off towards me, I try to move - and it locks up .... every time.

 

I've used different lines for my logic in THEN statements, so I'm clueless.

John Ross, though a fictional character, has psychopathic tendencies and constantly plots subterfuges to plunder his foes and their wealth. So of course you stand there - completely paralyzed. He's an amazing actor. My advice is to get a gun. IF shot and lastEpisode THEN perhaps 90210

 

Let's have the code in a zip. I'm sure Harry Hackman will spot the err in a flash.

 

;)

  • Like 1

John Ross, though a fictional character, has psychopathic tendencies and constantly plots subterfuges to plunder his foes and their wealth. So of course you stand there - completely paralyzed. He's an amazing actor. My advice is to get a gun. IF shot and lastEpisode THEN perhaps 90210

 

Let's have the code in a zip. I'm sure Harry Hackman will spot the err in a flash.

 

;)

 

HA HA!! :thumbsup:

  • 7 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...