[tetrinext] Re: Ideas (fwd)

[Alexander Hvostov <vulture@xxxxxxxxxxxxxx>]

Greetings,

Okay, first things first: Blessed binaries are BAD, BAD, BAD. Don't use
them at any cost.

Second, what about the server and the client synchronizing -- the server
tells the client that they have x block, falling at a rate of y lines per
second, and if the field is z lines high, and the client's ping time is p,
then the server knows that if the client doesn't tell the server where the
block has been placed in (z / y) + p seconds (perhaps with a little grace 
time in case the client's ping has increased somewhat; perhaps a second
of grace time would be appropriate, with a hard limit of three seconds
or so), the client is either cheating or lagged, and it is removed from
the game.

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
incredibly sophisticated (not to mention slow) artificial-intelligence for
that...

Fourth, having the protocol in ASCII and not a compact binary format is
stupid for a real-time game. It works okay for request-response
protocols like FTP and HTTP, but I have yet to see a successful real-time
game have a human-readable protocol. It's too damn slow, and my poor
33.6 just can't take the heat. If you need to debug it, then code a debug
type client that translates the binary protocol to something
human-readable. Works just as well.

Regards,

Alex.

---
PGP/GPG Fingerprint:
  EFD1 AC6C 7ED5 E453 C367  AC7A B474 16E0 758D 7ED9

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM d- s:+ a--- C++++ UL++++ P L+++ E W++ N o-- K- w
O--- M- V- PS+ PE- Y PGP t+ 5 X- R tv+ b DI--- D+
G e-- h++ r--- y
------END GEEK CODE BLOCK------

On Fri, 7 Apr 2000, Ka-shu Wong wrote:

> 
> Hi all,
> 
> A friend of mine asked me to fwd this.  Enjoy!
> 
> 
> Ka-shu Wong
> zillidot@xxxxxxxxxxxx
> 
> #!/usr/bin/perl
> $t="RKo-6v8mW21uR_wzzwr27A_wzzwr27.1s7RR#!l865lpw1l3s5zRD7=Qt22po5QaDp=D7
> aDp=~75#o-_b-kmlan#ab-klmno-_#aDpR=~75lBcddBcbfBcdcBcbdBcbcB1lB1BDQBcefBA
> 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";
> 
> ---------- Forwarded message ----------
> Date: Fri, 7 Apr 2000 22:13:31 +1000
> From: Matt Ryall <gholam@xxxxxxxxxxxx>
> To: "zillidot@xxxxxxxxxxxx" <zillidot@xxxxxxxxxxxx>
> 
> Hi Everyone,
> My name is Matt Ryall, and I'm a friend of Zillidot's from high
> school. Currently I'm in Sweden on exchange for a year, before
> starting college in IT next year. Anyway, Zilly asked me if I'd be
> interested in helping with your project and I certainly am. I have
> quite a bit of free time over here to code in, and I'm proficient in
> c++ and perl.
> l.
> I have been thinking about this project for the past few days and
> thought of a few ideas. First off though, I should say I have no
> experience whatsoever at SDL, so I have no idea what the easiest way
> is to design or code the UI. I was thinking about the application
> protocol anyway.
> y.
> As I see it, if we want to support play over the internet (read: with
> pings sometimes greater than 500ms) neither an action stream nor a
> dumb terminal type client would work. This is simply because of the
> way tetris works. The blocks must fall at a constant speed, and they
> could not do that if the server controlled the display on the client,
> nor can you depend on the server timing a players moves, since they
> could be lagged. That didn't really come across as clear as I'd like,
> so I'll say it again. If the client is a dumb terminal, you must wait
> for each keypress to go to the server and back again. This is annoying
> on a LAN (in fact I'm on a secure shell login at the moment through
> linux, and it's annoying me) but it would be unplayable on the net.
> The action stream would work, if the client controlled it. But then
> the client can be hacked to allow the blocks to wait in midair until
> the player is ready to place them - cheating. As far as I can see,
> therefore, the only way to stop cheating is to use blessed
> d
> binaries. That is, when we release the official client version, we
> encode a secret PGP key into it that is recognised by the server, and
> the sever manager can choose an option to only let legitimate clients
> join the game. I discussed this with the Shu, and he agreed with all
> the points I made.
> .
> One consequence of this is that thematic or other changes that we want
> third parties to be able to do must not require a recompile.
> .
> Okay, now what information do the client and server need to exchange
> during game play?
> ?
> Firstly, I think the action stream idea is the best, with every action
> the client does (whether it be voluntary, like rotating a piece, or
> involuntary, like the piece falling down) being sent to the server.
> But since we want theme makes to be able to code special bonus blocks,
> the move protocol must be a textual exchange. This is because, if we
> use just integers with defines in our code, two different theme makers
> might decide to use the same number for different types of special
> blocks. However, if we set a standard for the naming of the special
> blocks and moves, there is less chance of a clash. What do people
> think?
> ?
> Keeping the stream in ASCII will be slower, however, but it also makes
> debugging easier, being able to read the protocol we send. BTW, I
> don't think we should worry about people coding an AI to play tetris.
> I think it would be great, in fact, if someone could code a decent
> one, and interface it easily with a tetrinet (or TINT :)) client.
> .
> Well, that's about drained my brain for now.. I'm gonna get some
> coffee :)
> :)
> Cheers folks,
> s,
> Matt Ryall
> ll
> gholam@xxxxxxxxxxxx
> u
> 
> __________________________________________________________________
> Get your free Australian email account at http://www.start.com.au
> 
> 
>