Multiplayer Tetris Game - MERN

Code Feedback
1

Hi, I built this game using the MERN stack. I consider it as one of two ‘flagship’ projects that I will use to fool people into thinking that I know what I am doing. Here are some highlights:

  • Wrote single player tetris game from scratch with custom shape detection algorithm on canvas
  • Uses custom socket.io design on server side for authenticated players to play in multi-mode
  • Redux state management, including for socket delivery
  • Write single games and match data to mongodb
  • Third party authentication with passport.js

Link: https://multiplayer-tetris.herokuapp.com/
Repo: https://github.com/Dereje1/Multiplayer-Tetris/tree/development

The design may not be much to look at but it’s all me.

So if you have a couple secs mind reviewing it for me? what would you change ? how well do the single player & multi player modes work ? How ugly is the code ?

give it to me raw, i’m not sensitive …

1 Like
2

Took a quick look and so far the main issue I see is the game mechanics: if I hold arrow down the piece speeds up, that’s ok, but when the piece lands speed should reset back to normal. It’s very annoying especially when the box is quite filled.

Didn’t look too much at the code, but you use both .js and .jsx for React files. Consistency :+1:

this.resetBoard(
      false, false, true, opponentInfo
        ? this.processMatch(opponentInfo[0])
        : this.processSinglePlayer(),
));

:nauseated_face:

I may shit look more on your code later.

1 Like
3

Do you mean the next shape that appears after the sped down shape lands is fast even if your finger is not on the down arrow? or you release the down arrow and next shape is still fast, I think you mean the former. It something i did not think about …, I could put a brake on new shapes speeding up for the first few seconds maybe… I also have to rethink my entire speed up logic…

oh I forgot about that, I started this project as a chingu collab, before my partners fell off the face the earth we had decided to use .jsx for the react components, I’m going to revert them back to .js

ternary arguments are a no go ?

4

I mean, when I press and hold arrow down and piece lands, the next piece should start with regular speed even if my finger is still on the button.

You have like bazillion arguments (all of them booleans) and you finish it with a ternary argument. :nauseated_face: Come back to this code in a month :smirk: Four arguments asks for an object as an argument.

5

I see, this will mean I have to interrupt the down arrow key action on a new shape, doable … will do

Maybe I could have one options object as an argument and build it separately before passing it. Are many arguments to a single function frowned upon in the industry ?

6

Compare this:

this.resetBoard(
      false, false, true, opponentInfo
        ? this.processMatch(opponentInfo[0])
        : this.processSinglePlayer(),
)

with this:

const opponent = opponentInfo
  ? this.processMatch(opponentInfo[0])
  : this.processSinglePlayer();

this.resetBoard({
  reStart: false,
  keepFloor: false,
  gameover: true,
  opponent,
});

In the industry everything comes down to personal preference and ego (aka “best practices” :smirk: ).

1 Like
7

Alright, got the arrow down issue fixed on a new shape (except maybe for a small edge case), also cleaned up the .jsx, I have to take my time on the messy arguments refactor since I have a bunch of functions and components that call this.resetBoard( ) and I’d also have to do the same thing uniformly for all other functions with messy arguments too…

10

haha , no, it’s by sloppiness thanks for the heads up

11

@camperextraordinaire it’s because I used this for the center of rotation and it looks like it flips 180 , but it is actually 90,

13

Fixed the floor update on pause for single player issue, although the floor raise is really for multiplayer mode. I also moved my entire tick logic to use requestAnimationFrame instead of setInterval for better performance and now I can get to 100 ms tick updates and it feels less taxing on the cpu.

Trying to keep just one requestAnimationFrame cycle going without all the other interactions interfering was a challenge, but I’m surprised by how well react was handling very fast state changes.

I still may have some holes in the tick update logic however, with some of the redux updates not being reduced, unless I use async/await, weird because the game actions are completely synchronous, I think maybe thunk is interfering…