[tetrinext] Ideas (fwd)

[Ka-shu Wong <zillidot@xxxxxxxxxxxx>]

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