Thank you both for your response.
The graph certainly doesn’t need to be sent every time. If packets aren’t going to be dropped, then I can afford to send the graph every few seconds instead; whenever a piece is added to it. So this would mean I would need two seperate sorts of packets: a current position packet that doesn’t mind being dropped, and a graph packet that absolutely needs to be recieved or game play deteriorates.
If that’s the case, then I will only need to include 3 numbers (thanks Kova ;)) per send in the current_position packet; an X and Y pixel position for the falling block, and the current orientation for the block. This is necessary because the game implements smooth scrolling, and I know that it’s within the realm of possibility for every player to see every other players screen in (what looks like) real time, so I want my game to be capable of that. The pixel positions will unfortunately need to be more than a byte in length, since it’s certainly fathomable for someone to create a skin that has a larger than 256x256 gameplay area, but a word will certainly suffice.
For the graph packet I will need to send the current graph(NxM bytes), the current block(byte), the next block(byte), and however many attack lines(byte).
The graph is NxM array (flexible in size by user definition, but I can’t imagine it being more than 20x30, which would be huge) who’s numbers are (-2) - 6. -2 for a wall, -1 for empty, 0-6 for each of the possible blocks.
Let me explain a two person game in detail, as any more players scales similarly.
Each player has his own screen and plays tetris the normal way. Whenever a player clears some lines, his opponent is sent a number of junk lines that will fill the bottom of his graph. Currently I have this configured so 1 line cleared sends 0 junk lines, 2 sends 1, 3 sends 2, and 4 sends 4, but nearly every setting about this game is configurable so that’s not set in stone.
In a 4 player game there would be two different options I can think of at this point, a FFA or a Team Battle. The names should be self explanatory, but in a FFA everyone’s attacks are applies to everyone else’s graph, and in a team battle everyone’s attacks are applied to either the entire other team’s graph or to one particular player’s graph.
Pragmatically this means that our game must always be capable of sending our game and attack information to every other player in the game.
It seems to me that some sort of UDP/TCP hybrid would be the best scenario; we only need to guarantee that the updated graph packet is recieved, the current_position ones can drop occasionally (theoretically always) without causing any real problems. We just put the block wherever the newest packet says to put it, disregarding any older packets that arrived late.
Another question: Is it necessary to use a server? I have been doing a little reading and is broadcasting or peer-to-peer more reasonable?
[quote]Are you going to be implementing a hard-drop?
[/quote]
The game currently supports 9 move options: Soft Drop, Hard Drop, Soft Left, Hard Left, Soft Right, Hard Right, Rotate CW, Rotate CCW, and Flip. I can’t think of any more move options that don’t betray the basic gameplay of tetris, so that’s all it will support unless something else comes along that I haven’t thought of.
[quote]And when you get to level 20 the speed will have reached 20 UPS - having said that I suspect that their play does not directly affect the other players in your game
[/quote]
Well, this game supports smooth scrolling, so I’m not familiar with your terminology. Internally it thinks in two numbers, how many pixels to increment the pixel each game loop, and how long to delay between game loops. So for example, level 1 is currently set to {26, 1}, that is, delay for 26 milliseconds every loop, and increment the pixel 1 in the y position every loop. The fastest the block currently falls is {12, 4} and the fastest it changes is {8, 1}, but these should be used only as a guideline; it’s certainly fathomable to configure a different set of rules where the fastest update is shorter than 10 milliseconds. That said, it doesn’t really make sense pragmatically to update the game thread every 2 or 3 milliseconds; the user won’t be able to see the increase in resolution, but the computer will be significantly more taxed. Rather we should update at a max of 8 or 9 milliseconds, and increase the increment by the appropriate factor. Realistically it would never make sense to update more than every 7 or 8 milliseconds.
. This is way too much for server. I hope you meant numbers when you said ints because you can really use bytes and shorts for most of your needs in tetris.
