[tetrinext] Re: Ideas (fwd)

[Jared Johnson <solomon@xxxxxxxxxxxx>]

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

this is pretty much true.  don't use them.  and even if you don't think they're
bad bad bad, you still don't have to use them.  think of it this way.   someone
can hack the client to prevent pieces from falling.  how much good does this
do?  the main factor in whether a game of tetrinet is won is speed, and a hack
like this would only slow a player down.  assuming that TINT gameplay is 
anything
at all like tetrinet, players will not even notice whether their pieces drop;
especially the fast players, who will probably have their pieces in position and
dropped before the piece drops a single space!

> 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.

sounds like a pretty good way to prevent people from using a very ineffective
cheat ;)

> 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...

yeap.  you would probably also need a sophisticated and slow ai to run a quick
simulation ;)

unless somebody comes up with some fun math to figure it out <shrug>

> 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.

might be able to get by just compressing the ascii stuff, or making the
protocol extensible enough that you can drop a binary version of our ascii 
protocol in
before a "stable" release is made.  or make some sort of alias thing happen.  or
you could be a real programmer unlike myself and probably be able to come up
with lots more ways to overcome this problem ;)

> 
> 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
> > 
> > 
> > 
> 
> 

-- 
Jared Johnson
solomon@xxxxxxxxxxxx

Fat people of the world unite, we've got nothing to lose!

-----BEGIN GEEK CODE BLOCK-----
Version:  3.12
GCS/C d+(-)>-- s:+ a18 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------