There are a lot of ways to do it. So what are your proposed block doing
and how do they interconnect to realize the game?
First you should be clear on the representation of the game logic in
your verilog model, then you can start to divide this into meaningful
blocks.
A simple approach could be:
Write an LED matrix control module that takes a two-dimensional
bit-array as input and updates the (monocolor?) LED matrix (as fast as
possible). This is totally separated from the game logic. The two
dimensional bit-array is your game board and the whole game logic may be
handled in one module that updates this array. A 1 in the array means,
there is sth. (ball or paddle or block or outer borders or ground).
Your game logic module updates the bit-array. Internally, it may have a
structure of a two-dimensional multi-bit array (e.g. 5 bit
one-hot-encoding to know internally what is the ball and what is the
paddle and what is a block and so on) that can be easily mapped to the
bit-array for the LED module.
In your game logic module you can create several counters. For example,
you could process the paddle input any 10 ms and trigger a bit-array
update accordingly (depends on how fast you allow to move the paddles).
A second counter of e.g. 1 s moves the ball.
The interesting thing in the game logic module is the game logic. The
ball has to be reflected from the paddle, the blocks and the outer
borders with a certain degree. So if your game logic module updates the
array, it has to check if an array element is used by more than one
element (i.e. more than one bit is 1 in the multi-bit one-hot
representation) and what happens then. Your checks are a lot faster (if
you run the verilog design on some MHz) than the LED output, so you have
enough time to "loop" through the array and trigger the according
actions.