Snake game

[NikG]

I found a Snake game I created in Turing (v3 or something) way back in the day (at least 3.5 years ago). I thought I'd put it up.

Once again, feedback is appreciated. I've been meaning to go back to it for a long time and optimize the code, and perhaps create Snake II in the process.
It runs kinda slow on my work computer (but not on my home comp). I'd love to know how it runs for others.

Press any key to skip intro, Arrow keys to move, any key to pause.


EDIT: Removed game from this site to free up upload space. It is permanently available HERE.

[pavol]

wow, that's pretty good, it's kinda hard. you might want to give the user a chance to play again after they crash so they don't have to restart the program. also making different levels (as in how fast the snake goes) would be cool.
overall good job
+bits

[NikG]

Thanks for the comments (and the bits).
I take it since you said it's hard that it runs pretty well on your computer.

I had always planned to have different levels (in fact if I remember, I might have that feature in the original source code, except that it's commented out).

The reason I didn't add that functionality, and perhaps someone can explain this to me, is that the timing in Turing seems to differ based on the computer.
On my Pentium 75mhz (yes, you read that right) on which I created this game, it ran fast. It also runs fast (too fast) on my current computer (3ghz). But it runs pretty slow on my work computer (I don't know the speed but I'm sure it's at least 1.5ghz). Does anyone know why this happens?

[[Gandalf]]

Quite nice snake game. 74 is quite an impressive score, at least at full speed, my highest was 27.

Was it made in Turing 3.*.*, or in Turing 4.*.*?

I have no idea why the game's speed would vary so much on your computers, especially a 75Mhz one. Maybe you were using the DOS Turing? I do know that the speed of the game when using the delay() function will definately vary on different computers. To prevent this, use the Time.DelaySinceLast() function if it is available, or else create your own frame rate limiter by checking the time between frames (via the Time.Elapsed function, or if that is not available, clock()).
*edit* Err... Changed "vary on varying". :/

[NikG]

I made it in Turing 3.1.1 or something, I believe. I could boot up my old computer (yes, I still have it...) to check, but I'm too lazy.

Yup, 74! I think I even have a screenshot of it, but once again, it's on my other computer.

Thanks for mentioning those other functions. I'm going to definitely look into them because I use delay extensively.

[[Gandalf]]

No problem.
Which version of Turing are you using currently? Time.DelaySinceLast() and Time.Elapsed are definately available on Turing 4.0.5 and higher. I'm not sure about previous versions.

[NikG]

4.0.1 [k]

i've actually been looking to update but the patch links on the Holt Soft site don't work.

it seems there is a Time.Delay, but not a Time.DelaySinceLast()

[[Gandalf]]

Indeed, the HoltSoft site hasn't been updated in ages, they still have the newest version as 4.0.4c, while 4.1 has been released.

Time.Delay() is the exact same thing as delay(), just moved over to the Time module. To use Time.DelaySinceLast you will either have to create your own procedure for it, or else obtain a newer version in another way... "The Time.DelaySinceLast procedure is used to cause the program to pause for a given time since the last call to Time.DelaySinceLast. The time duration is in milliseconds."

[NikG]

Something like this?

code:

var Delayed : boolean := false process TimeSinceLastDelay (duration : int)     var cStart, cCurrent : int     if not Delayed then         Delayed := true         clock (cStart)         loop             clock (cCurrent)             exit when cCurrent - cStart >= duration         end loop         Delayed := false     end if end TimeSinceLastDelay

(I haven't tried this, just though of it right now)

Edit: I've tried this now, doesn't seem to work...

[TheOneTrueGod]

I don't know what clock does, and it seems that Delayed boolean doesn't do anything, but eh.

Heres my version.

code:

var lastdelay : int := 0 procedure TimeDelaySinceLast (duration : int)     if Time.Elapsed - lastdelay < duration then         delay (duration - (Time.Elapsed - lastdelay))     end if     lastdelay := Time.Elapsed end TimeDelaySinceLast TimeDelaySinceLast (1000) put Time.Elapsed put "Should be 1000 milliseconds(ish)" TimeDelaySinceLast (1000) put Time.Elapsed put "Should be 2000 milliseconds (ish)"

[NikG]

I thought you said delay wasn't reliable... so don't I still have the same problem by using it how you did?

the boolean in my code was just to check whether the delay was already running. I used clock because I thought maybe it would be better than delay. I used a process because that way I could still have my program do other things, but I could delay certain things.

i.e. in my basketball game, I want the players movement delayed by say 200 ms while when he shoots, the ball's movement (during which the player should still be able to move around) is delayed by only 50 ms. So I would need two separate delays which don't delay the whole prog, just the player/ball.

Edit: spelling, added example

[[Gandalf]]

TheOneTrueGod's version is indeed accurate.

First off, processes are bad (refer to the [Turing Tutorials] section for quite a few posts on that), especially for things which rely on time. To accomplish what you seek an alternative would be to do everything procedurally, and just have a boolean variable to decide if the player is able to move, for example:

code:

var playerCanMove : boolean := true %%% if playerCanMove and player shoots the ball    %stuff for shooting the ball    playerCanMove := false if ball has reached it's target    playerCanMove := true

As for your TimeDelaySinceLast procedure, using the delay procedure in this case is acceptable because the reason for it being inaccurate is not present. delay() is only inaccurate because it does not take into consideration the time it takes to execute the code in between (whereas Time.DelaySinceLast() does), but in your custom TimeDelaySinceLast proc there is no code in between, so it will be quite accurate.

Also, clock() could be used as a replacement for Time.Elapsed, not Time.Delay or Time.DelaySinceLast.
Note: This post was written is a bit of a hurry, sorry for any mistakes.