[tetrinext] Re: Ideas (fwd)

[Matt Ryall <gholam@xxxxxxxxxxxx>]

Yep, the action stream takes care of most of the cheating problems.
But my idea of the slowing down cheat wasn't to slow falling. It was
to completely eliminate it, and replace with moves by the player. So
that instead of gravity falling, the player presses down to move the
piece down, up to move it back up again, and another key, like enter,
when they're done moving it around the screen. Somebody skilled could
cheat quite easily this way, I think, and you guys didn't really
explain why blessed binaries are bad. I guess it sort of defeats the
purpose of open source software, and all our settings therefore have
to be runtime changeable (as I said before, IIRC), but if there's some
other reason why, I'll be happy to be enlightened.

As far as a human readable protocol goes, the tags we use need not be
very long. A simple MV_L for moving to the left would do - five (you
need whitespace) characters instead of a single integer (unless you
were thinking of doing some bitfield technique..) would not slow
performance noticably, I think.
My opinions on this are a bit sceptical though, on the matter of
speed, since I've never done sockets programming before.

The other matter is then does the server send each client the action
stream of the other clients, or an array of their fields at a certain
time delay. If you use an array (which I think is easier and faster),
that doesn't really allow the player to use custom blocks for their
opposition that are graphics for the whole block, and not one little
square.
For that matter, when somebody proposed having a whole block graphic,
how was it supposed to look if part of the block was removed in a
line?

I really like the sound of the interface so far. Was it decided
whether the panes could have sliding states between just offscreen and
on. Like, could the player slide panes around so that their field
takes up less of the screen, and leave more room for chat?

If I've got time over the next few days, I'll try to type up my ideas
on what the server and clients need to know, and when and how often
updated. I think that is essential before we can go any further with
protocol design.

Regards,
Matt

PS. Sorry about the bad text in the mail before. I wasn't on the best
machine at the time, and lynx doesn't work so well with my web-based
email... :)


Original message from: Ka-shu Wong <zillidot@xxxxxxxxxxxx>
>
>Hi,
>
>[snip]
>> Third, upon receiving notification from the client that its current
block
>> has been placed, the server must calculate that it was actually
possible
>> for the client to have placed the block there, perhaps by running a
quick
>> simulation, dropping the block and trying to maneuver it through
the
>> field. Of course, this wouldn't detect bots, but then, you'd need
an
>[snip]
>
>The 'action stream' proposal that I made a while ago takes care of
this.
>Basically instead of getting the client to send field updates, it
requires
>the client to send all player actions that affect the state of the
game.
>
>In effect, the server is maintaining a copy of the player's field,
and
>manipulating it in parallel to that which is on the client.  (this is
>quite easily done if the client and server is built from the same
source)
>If the fields goes out of sync then it is likely that the player has
>attempted to cheat.
>
>
>Ka-shu Wong
>zillidot@xxxxxxxxxxxx
>
>#!/usr/bin/perl
>$t="RKo-6v8mW21uR_wzzwr27A_wzzwr27.1s7RR#!l865lpw1l3s5zRD7=Qt22po5QaD
p=D7
>aDp=~75#o-_b-kmlan#ab-klmno-_#aDpR=~75lBcddBcbfBcdcBcbdBcbcB1lB1BDQBc
efBA
>lraDp=~6lt22po5lD7la35w17QDpB1Qa";$b=$t;$b=~tr#a-z0-9 /;_#;0-9/
_a-z#;$b
>=~tr/\122\104\121\102\101\n/\n\$"\134\@/d;$b=~s/foobar/$t/;print"$b\n
";
>
>
>
>

__________________________________________________________________
Get your free Australian email account at http://www.start.com.au