[tetrinext] Re: Ideas (fwd)

[Ka-shu Wong <zillidot@xxxxxxxxxxxx>]

Hi all,

I've been asked to forward this to the list... apparently it was not sent
to the list by mistake.
Oh well, here it is ...

---------- Forwarded message ----------
Date: Sat, 8 Apr 2000 16:09:14 -0400 (EDT)
From: Anthony <nite@xxxxxxxxxxxx>
To: Ka-shu Wong <zillidot@xxxxxxxxxxxx>
Subject: RE: [tetrinext] Ideas (fwd)

Matt Ryall wrote:

> I'm proficient in c++ and perl.

Cool. Have you written anything I can see that is OS'd? I'm curious as to what 
your abilities are (you can tell me, too).

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

That is no big deal. I don't know much about SDL either.

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

Huh? We are going to want to use a connection based protocol, most likely TCP. 
UDP might (would) be dangerous for a game, it would be slow and funny 
(depending on your sense of humor) things might happen.

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

The server will not control the clients moves. It will have to verify them in 
order to prevent cheating.

> If the client is a dumb terminal, you must wait for each
> keypress to go to the server and back again.

TINT will not be a dumb terminal.

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

What do you mean by action stream? We can't use stream sockets, too much 
degradation of the data. The only way to stop cheating is to verify moves.

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

I completely disagree. The project is open source, the second someone who knows 
anything sees the source he will be able to remove that lock and enable 
cheating with TINT.

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

We are an open source project.

> Okay, now what information do the client and server need
> to exchange during game play?

Lots, that type of information needs to go into the initial draft and therefore 
cannot be fully discussed here.

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

Keeping the stream in stream in human readable form would be incredibly and 
amazingly slow. The server would have to parse all the readable text into 
something it could comprehend. Not to mention if we use ASCII we will not be 
able to port to wider character sets, ie, Unicode.

Anthony

> Matt Ryall
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup