Skill vs computer speed

[Tero]

Andy, seriously, what is the point of these maps?

Tyler21: This is a textbook example of computer speed matters.  Just land and build a nullifier.  I've looked up the scores.  The first 54 players have times between 1:00 and 1:00.9 minutes.  The next group take somewhat longer.  While merely seconds it's hard to believe every player finished the game in an unique manner.

[RrR]

This is a textbook example of computer speed matters.

Seriously Tero, what do we have to do to convince you that computer speed is irrelevant to CW3 (except that lag becomes annoying). The clock measures game time, which advances at 30 frames per second of game time. On a slow computer, frames are generated slower, so 30 frames will take more than one second of real time. You can prove this: open a large laggy map and let it run. Compare the game time with a stopwatch - see it runs slow.

The difference between the best times and the others is skill (and occasionally luck with runners etc) and perhaps the result of playing the map multiple times. Alter Old, for example, does not use a supercomputer to get those astoundingly low times!

[warren]

... I would strongly disagree. ...

Dear Tero:
It is strongly inadvisable to disagree with scientific facts as if they are opinions.
Sincerely,
A scientist.

(P.S. You should disagree with them like a scientist. By shouting PROVE IT!)

[Helper]

Dear Scientist Warren,
Are you saying (Gasp!) that a map with 24 scores is not "unwinnable"?
Pesky things those facts.
:)
H

[Asbestos]

I would strongly disagree.  A number of times there have been maps up loaded where the player only needs to land a CN and place a Nullifier next to something like a Spore Tower.  Once the scores are listed, the time tend to very.  A LOT!

That's because there's a specific technique to building a nullifier as quickly as possible. You have to build two collectors (using the N button to advance frames so no energy is ever wasted) and then build a nullifier, and the distances between the CN and the buildings matter, and everything must be set into action one at a time the immediate frame a packet is launched for that last point of construction.

[Tero]

I would strongly disagree.  A number of times there have been maps up loaded where the player only needs to land a CN and place a Nullifier next to something like a Spore Tower.  Once the scores are listed, the time tend to very.  A LOT!

That's because there's a specific technique to building a nullifier as quickly as possible. You have to build two collectors (using the N button to advance frames so no energy is ever wasted) and then build a nullifier, and the distances between the CN and the buildings matter, and everything must be set into action one at a time the immediate frame a packet is launched for that last point of construction.

Map 1842 by Andy as an example.  Place Nullifier in PZ.  Select LZ for CN.  Click on Pause or press "P" to begin.  The scores/times are surprisingly different.  Of course there are those who may choose to build a Nullifier and land a CN after clicking on Pause.

[Helper]

I would strongly disagree.  A number of times there have been maps up loaded where the player only needs to land a CN and place a Nullifier next to something like a Spore Tower.  Once the scores are listed, the time tend to very.  A LOT!

That's because there's a specific technique to building a nullifier as quickly as possible. You have to build two collectors (using the N button to advance frames so no energy is ever wasted) and then build a nullifier, and the distances between the CN and the buildings matter, and everything must be set into action one at a time the immediate frame a packet is launched for that last point of construction.

Map 1842 by Andy as an example.  Place Nullifier in PZ.  Select LZ for CN.  Click on Pause or press "P" to begin.  The scores/times are surprisingly different.  Of course there are those who may choose to build a Nullifier and land a CN after clicking on Pause.

You might want to find a better example.
In the example you cite, the first 54 scores "very" (sic) by only one half of one second.
Further, 85 (or 2/3) of the scores range from 1:00.3 to 1:01.9
Statistically, the Standard Deviation is almost meaningless; much less "surprisingly different".
H

[Tero]

This is a textbook example of computer speed matters.

Seriously Tero, what do we have to do to convince you that computer speed is irrelevant to CW3 (except that lag becomes annoying). The clock measures game time, which advances at 30 frames per second of game time. On a slow computer, frames are generated slower, so 30 frames will take more than one second of real time. You can prove this: open a large laggy map and let it run. Compare the game time with a stopwatch - see it runs slow.

The difference between the best times and the others is skill (and occasionally luck with runners etc) and perhaps the result of playing the map multiple times. Alter Old, for example, does not use a supercomputer to get those astoundingly low times!

The fact I can't finish a great many maps!  If all things are equal, which I doubt. I should be able to get a foothold on every map I play.  The ones I can't have one thing in common.  Lack of time to build.  Despite making multiple attempts to restart. 

If I'm wrong, as you state, shouldn't the download count and scores be nearly the same number?

[Karsten75]

I would strongly disagree.  A number of times there have been maps up loaded where the player only needs to land a CN and place a Nullifier next to something like a Spore Tower.  Once the scores are listed, the time tend to very.  A LOT!

Do you think I gave you an opinion or a fact that Virgil expressed many times on these forums? It's not up to debate. It is how the software platform is designed to work.  Some small variance in simple maps is achieved by people actually floating the CN directly over the nullifier they build, thus reducing packet travel time. Again, technique, not speed of processor.

If you want to disagree some more, move this debate off a map discussion thread.

--  End of non-map specific discussion. Further discussions on processor speed and map completion times will move to a new thread. --

[warren]

... If I'm wrong, as you state, shouldn't the download count and scores be nearly the same number?

For the record, posting score is optional. Until I got really into cw3, I never posted. I could not even begin to guess how many people still do that.

But I will anyway. About 50%.

Plus, there is the number one reason why people don't finish maps: boring. Every map is boring to someone. Especially busy people. The more busy, the more stuff gets boring.

[teknotiss]

If all things are equal, which I doubt. I should be able to get a foothold on every map I play.  The ones I can't have one thing in common.  Lack of time to build.  Despite making multiple attempts to restart. 

Tero all things are equal in computer speeds affecting this game. 30 frames is one game second.
that is a fact. please don't accuse us of lying to you. this is a friendly forum and if you want to improve your times people here will help you if you ask.

it is possible that you are missing some data.
do you play using "n" to advance frame by frame? (you can use this function to prove that we are not lying to you, open a map, press "n" 30 times and watch the timer. at press 30 you will see 1 sec on the clock)
playing paused with "n" can save a lot of microseconds, which add up. and early time saving is worth a lot later on.

[asmussen]

Andy, seriously, what is the point of these maps?

Tyler21: This is a textbook example of computer speed matters.  Just land and build a nullifier.  I've looked up the scores.  The first 54 players have times between 1:00 and 1:00.9 minutes.  The next group take somewhat longer.  While merely seconds it's hard to believe every player finished the game in an unique manner.

The point is that the people who scored at right about a minute DIDN'T just land and build a nullifier. They used a more efficient strategy, resulting in a better time. If you just build a nullifier, you don't have enough energy to supply the packets as fast as the nullifier can take them. Building a collector in one of the PZ's first and THEN building a nullifier only after the collector is completed results in a quicker time, even though you don't actually start building the nullifier until several seconds have gone by.

Your assertion that this is a clear textbook illustration of computer speed mattering is based on the assumption that you are using the optimal solving method for the map, and that the people with the better scores used the same strategy as you, just with a faster computer. If that assumption was correct, you'd have a point. However, it is NOT correct. Those people used a superior strategy, and that is why they have better scores.

[Michionlion]

To add to that, computer speed doesn't matter at all - the game is frame-locked, meaning both graphics and calculations on done one after the other, so a faster computer will not make a difference in times.

[Tyler21]

Tero, you should just check Alter Old's scores. If those won't convince you that superior skills can reduce completion times drastically, then I don't know what could.

Along these lines, one of my favorite pop-scientist:
"The good thing about science is that it's true whether or not you believe in it." — Neil deGrasse Tyson


Edit: Tero, I see that you even include this speed issue on your profile. My suggestion for you is to play while the game is paused. There is a key (default "n" I think) with which you can play frame-by-frame. This way you shouldn't experience the performance issues that might occur during "real time" and you can complete maps much quicker (in game time of course, not in real time).

[warren]

... --  End of non-map specific discussion. Further discussions on processor speed and map completion times will move to a new thread. --

And so it was. But now that the thread is more appropriate, I have more to say.

I would like to start by saying that there are indeed many games out there that have computer dependent behaviour. Most notably, 3D games with multiplayer support often implement frame skip for better synching behaviour. So this is definitely a valid hypothesis.

It would be quite inappropriate for a strategy game without multiplayer support, however. It is a fact that the design goals of this game are against computer dependent behaviour. This, however, only means that if there is computer dependent behaviour, it is a bug.

TLDR: CRPL evidence

Spoiler

Playing around with CRPL gives insight into how the game guarantees computer independent behaviour. Each CRPL script on each CRPL core executes only once per frame. This is reproducible behaviour that can be measured, and was in fact a necessary truism for the correct functioning of some of the maps I made.

If they executed in a more haphazard manner, race conditions would be one manifestation. This game is singlethreaded. This is how race conditions are prevented. At the start of each frame, each script is executed, one after the other. Until the scripts finish, nothing else happens. Designers who place multiple threads of execution into their products are far more likely to accidentally or purposely add computer dependant behaviour. (see next spoiler section)

A more interesting question is: Is it possible to in any way to invoke computer dependant behaviour in CRPL?

And here the answer is: I don't know. There is a huge amount of possibility inherent in CRPL. But for the most part, it is unusually difficult.

We have a concept known as exposed functionality. the language of CRPL does not expose the system clock. This means, no map can look at the computer's clock and change its behaviour accordingly. Other things that are not exposed are the computer's make and model, the file system, and just about anything else that I can think of that might allow me to change a map's behaviour based on computer.

It is worth noting, that the computer's screen resolution *IS* exposed. As some people use computers that are not capable of some resolutions, this does sort of allow for the possibility of computer dependant behaviour.

[close]

In addition to that, the game seems unaware of the actual time. All times in the system are actually measured in frames, and translated into seconds only for display to the user.

In fact, a coder sort of has to go out of their way to make computer dependant behaviour.

TLDR: timey wimy stuff

Spoiler

All modern computers are based on the Turing Machine model of computation. A Turing Machine is a deterministic machine. This means that every time a program runs, the exact same thing happens.

Now, CW3 runs on both Windows and Linux machines. These two machines use very different under the hood architectures. The game had to be translated, to a degree, to work on both platforms. This results in some necessary difference in behaviour, mostly to do with how the game draws to the screen. But the game logic itself exists in a sort of emulated space. This means that the game logic is being "run" on a third "computer". This helps with porting, and guarantees that the game runs the same on both platforms, with only differences in execution speed.

This emulated space concept is central to the idea of a Turing Machine. Any Turing program can run on any computer. And it will run the same, with only differences in execution speed.

So how would you make a program run differently based on computer? The easiest way is to look at the system clock. Because the program will run at different speeds on different computers, looking at the system clock will give different times on different computers.

You actually see this a lot on cheap platformers. Some platformers will implement frame skip, and worse, some sync some functionality to game frame, and some to video frame. This can create really broken computer dependant behaviour.

The other way would be multiple threads. This is like one computer having two brains inside it. Slight variances in the speed at which each brain think mean they may finish at different times relative to one another. This is a race condition.

On computers that implement threads, it is a general rule that the exact speed of each thread cannot be known. This breaks the general contract of determinism created by Turing Machines. Without determinism, we can make no hard guarantees about computer independent behaviour. In order to restore determinism, a programmer has to write in appropriate synchronization code.

This game is single threaded.

[close]

The other major cause of computer dependant behaviour in games is dropped input events on slow computers. This is particularly a problem in flash games. Depending on the computer, sometimes if the computer gets busy, the keyboard and mouse will stop working in games for a few frames. This is really annoying.

This is not a problem for strategy games, particularly ones where you are allowed to do stuff while paused, and ones that implement a frame step key.

In summary, the game runs the same on all computers, because of the way it was built. Each frame it: Moves the creeper; moves the packets; executes CRPL; draws the game to screen. It does each step in order, and never skips any.

"The good thing about science is that it's true whether or not you believe in it." — Neil deGrasse Tyson

I disagree. The good thing about science is its reproducibility. You can confirm everything I said through trial and experiment.

Postscript: But you CAN make stuff happen white the game is paused.

Spoiler

In CRPL, there is a function that allows you to make a script that runs while the game is paused. This is supposed to be used for creating animations, but it has some extra uses for the really exotic CRPL maps.

There is even a bug associated with this. If a script is set to operate while paused, and is then destroyed, a newly created script may inherit the operate while paused status.

This is only a problem on the really advanced CRPL maps, those that use operate while paused, and dynamic creation. However, if you play one of the early sleeper maps, you may notice that sometimes one or two enemies will continue to move or fire while the game is paused.

[close]