[tetrinext] Re: Ideas (fwd)

[Jared Johnson <solomon@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.

there really don't need to be any other reasons why.  TINT is going to be a GPL
project, which means that every bit of the source is available for download and
allowed to be changed provided it is available under the GPL.  Thus, having a
"secret bit" of code would either be useless because it's not secret, or it 
would
be fatal because TINT was no longer GPL and thus all of us GPL lovers would get
perterbed and either drop the whole thing or go and write exactly the same
thing, without the blessed binary approach.  Hopefully you see the problem now. 
 If
you're not sure just why the GPL is the coolest software license in the whole
world, ask for some links to informatio and I'll ablige.  Oh, and, everybody 
else,
let's not make this a flame thread about which license is best =)

About the cheating thing...as i said before, if someone successfully
accomplished just exactly what you've outlined (and this would be hard because 
of action
streams and if we added extra things to prevent it -- perhaps by including 
number
of block falls between actions in the action stream), it would give them
absolutely no advantage whatsoever in multiplayer games.  The only way that 
they could
use it as an advantage would be to prolong their survival by not having the
block drop when they were about to die -- but, the server would easily see this 
and
kick them off before they even got the advantage.  All that this cheat would do
is slow the cheating player down.  Thus, it's silly in my mind to do a blessed
binary approach just to prevent this method of cheating!

Since TINT would probably have extensible gameplay, it would be nice for people
to point out alternative, _multiplayer_ gameplay situations where this could be
an advantage, and how it could be prevented.

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

hrmm.  i don't think an array of the field _at a time delay_ would be a good
idea; how about an array each time another block is dropped into the field. 
conviniently, the client could _probably_ be made to figure out what sort of 
block
was added by the difference in the two fields, though this would be more complex
if the block dropped cleared any lines =).  perhaps someone smarter than me 
could
figure out a way for the server to send the client this extra information
without consuming too many resources (bandwidth and otherwise).

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

hrm, i proposed that, but i don't have an answer for you...

i know that Quadra made it look good! =)

i'll look into it i suppose.  perhaps the only way for a theme author to do
such a cool thing would be to use an sdl hack for the blocks?  of course, they
could do lots of other cool things with this too =)

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

seems like they should, as well as default states and such, especially the chat
"console".

hey, it sure would be nice if someone would clean my "first draft" up, solve
some of its problems, and write a "second draft" of the interface and theme
standards... especially if the guy actually knew how to code =)

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

mmmhm, let's do a whole lot of that.  it would be desireable to have a pretty
good idea of exactly what's going to be done and to make that available to you
and anybody else who wants to code it, and then get started, eh?

-- 
Jared Johnson
solomon@xxxxxxxxxxxx

What we Are is God's gift to us.
What we Become is our gift to God.

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