As I am like an 'oover when it comes to collecting tittle tattle, here's an example file of Spin scripting written by big D in about 1909 I expect.
In the script file, you should change the first line to match the location of the snapshot file on your own computer ;)
In Spin 07 and 0666 which are the only ones that work on my compo, the file goes wrong whilst trying to jump on a lift in the dumb waiter room but it did work properly on an earlier version for those able to test it. Either way, it's a great help file for those eager to try it and create their own.
I hope big D doesn't mind me posting it but he doesn't come here anymore so will never know :)
I asked if Dunny would give any info about it, and he said that people should have taken notice of it when he added it years ago! Nobody was interested
Not true that!
I did talk with him about it asking for assistance/pointers on a few occasions ... but then again, it might have been after he thought people weren't interested ... and I guess my interest just wasn't enough to spur him on :cry:
Dunny's a cool guy, I consider him a "software inventor of the highest degree" in my books.
I've just had a little go making a script for Airwolf with the help of now knowing the commands. An hour later and I'm nearly through the first wall. Its very time consuming without a frame counter.
There are only a few commands. wait N (N=frames), keypress KEY, keydown KEY, keyup KEY.
I suppose it shouldn't be too difficult to patch in a frame counter in the game itself. But I expect this will mess up the timings on a snapshot without the frame counter running.
Now I can see that this "scripting" was at a rather early development stage when it was abandoned.
It's hard to imagine how one could create a game walkthrough by writing thousands of commands in text editor without playing the game itself.
I think that the further development could look something like that:
1) play the game, and instead recording to rzx, choose recording to script.
2) modify the created script
3) watch the recording
4) if happy=done with this part, if not=go to 2)
But as I said before, to create these kind of recordings, you must be a REAL PERFECTIONIST :)
I have just had a look at it and for the commands I know of it works well enough but as Ralf said it is very early in development (or ended :razz:) and it will only work for certain games, those with a fixed path so any game with a random element won't work.
good feature though that I knew nothing about so sorry for not showing any interest but...you know....throw me a frickin bone....:smile:
and it will only work for certain games, those with a fixed path so any game with a random element won't work.
As far as I understand game recording, it is not true.
When you play the game, there is a lot of events that you consider random. For example, enemy may appear in left window or right window and it is not predictable for the player.
But these events aren't truly random for the computer. To decide where the enemy will appear it uses some numbers stored in its memory and makes calculations with it. As the player doesn't know these numbers or aloghoritm, the result may seem random to him
If you make a recording file, you put two things into it:
- Spectrum memory state at the beggining
- player's input recorded over some time
So if you always start from the same memory state and always give the same input, the "random" events will always be the same too. The enemy will always appear in the right window and player's shoot into this window will always kill him.
Game recordings reveal a hidden but true nature of a computer - a deterministic beast.
And I think there would be no difference between rzx and this "script". It's just a different way of storing the input.
All the 'random' numbers on computers are pseudo-random, this makes input recordings possible. This fact is also used for a very common thing in TAS called 'luck manipulation'.
As far as I understand game recording, it is not true.
When you play the game, there is a lot of events that you consider random. For example, enemy may appear in left window or right window and it is not predictable for the player.
All the 'random' numbers on computers are pseudo-random
Not on a modern machine. Linux provides /dev/random, which gathers entropy from "random" events such as keypress and network packet timings and uses that to produce its output. If it doesn't have enough entropy, reading from it will block until it does. I imagine other operating systems have an equivalent.
Comments
yeah, ever since the global adoption of IPv6 we've not had the problem of mistaken identity... Oh wait ;)
I dont know, i'm thick
http://www.zx-spectrum.cz
Willy could team up with Bob Stains ;)
In the script file, you should change the first line to match the location of the snapshot file on your own computer ;)
In Spin 07 and 0666 which are the only ones that work on my compo, the file goes wrong whilst trying to jump on a lift in the dumb waiter room but it did work properly on an earlier version for those able to test it. Either way, it's a great help file for those eager to try it and create their own.
I hope big D doesn't mind me posting it but he doesn't come here anymore so will never know :)
Not true that!
I did talk with him about it asking for assistance/pointers on a few occasions ... but then again, it might have been after he thought people weren't interested ... and I guess my interest just wasn't enough to spur him on :cry:
Dunny's a cool guy, I consider him a "software inventor of the highest degree" in my books.
There are only a few commands. wait N (N=frames), keypress KEY, keydown KEY, keyup KEY.
I suppose it shouldn't be too difficult to patch in a frame counter in the game itself. But I expect this will mess up the timings on a snapshot without the frame counter running.
My ZX Art Music Page
Carlos Michelis Theme
The game should not be modified in any way, it is the main principle of TAS.
Careful now, you're bordering on the perverse..
Now I can see that this "scripting" was at a rather early development stage when it was abandoned.
It's hard to imagine how one could create a game walkthrough by writing thousands of commands in text editor without playing the game itself.
I think that the further development could look something like that:
1) play the game, and instead recording to rzx, choose recording to script.
2) modify the created script
3) watch the recording
4) if happy=done with this part, if not=go to 2)
But as I said before, to create these kind of recordings, you must be a REAL PERFECTIONIST :)
And I agree with Wikipedia that it may become really unhealthy:
http://en.wikipedia.org/wiki/Perfectionism_(psychology)
good feature though that I knew nothing about so sorry for not showing any interest but...you know....throw me a frickin bone....:smile:
As far as I understand game recording, it is not true.
When you play the game, there is a lot of events that you consider random. For example, enemy may appear in left window or right window and it is not predictable for the player.
But these events aren't truly random for the computer. To decide where the enemy will appear it uses some numbers stored in its memory and makes calculations with it. As the player doesn't know these numbers or aloghoritm, the result may seem random to him
If you make a recording file, you put two things into it:
- Spectrum memory state at the beggining
- player's input recorded over some time
So if you always start from the same memory state and always give the same input, the "random" events will always be the same too. The enemy will always appear in the right window and player's shoot into this window will always kill him.
Game recordings reveal a hidden but true nature of a computer - a deterministic beast.
And I think there would be no difference between rzx and this "script". It's just a different way of storing the input.
For the most obvious example of this, reset a (48K) Spectrum and do "PRINT RND": you will always get ".0011291504".
I can't program like Dunny can. I'm learning Blitzmax at the moment, but it's a slow thing.
:-o
oh yeah.... ooops
Not on a modern machine. Linux provides /dev/random, which gathers entropy from "random" events such as keypress and network packet timings and uses that to produce its output. If it doesn't have enough entropy, reading from it will block until it does. I imagine other operating systems have an equivalent.