Hi there,
Right now, I’m trying to familiarize myself with UE4 and the blueprint system. In order to do that, I’m trying to build a simple Tetris clone, since that ought to teach me quite a few basic and valuable lessons about the engine and how to work with it. I’ve gotten pretty far, but now I’ve hit a significant snag and I’ve tried and failed the last three days to solve the problem on my own, so here’s hoping someone around here is kind and knowledgeable enough to help me out here.
What Works
I’m currently working with three kinds of actors (Cube, TetrisLine and TetrisGrid)
Cube is quite unremarkable right now, it only consists of the Root and a single Cube which starts Invisible.
TetrisLine spawns 10 Cube Child Actors during construction, saves them to an array and then moves them to a position corresponding to their number in the array. It also contains Events that call up Cubes to toggle their Visibility.
TetrisGrid spawns 22 TetrisLine Child Actors, saves them in an Array for easy access, and then moves them to build the proper Tetris Grid.
This, as far as I can tell, works correctly. 220 Cubes spawn in a grid and I can call up and toggle the visibility of every one of them correctly.
The Level Blueprint currently only contains the Blueprints to react to Input Events.
My logic behind this is that I didn’t want to work with “free” floating actors that get moved around and prevent clipping by collision detection and somesuch, but with a fixed grid that corresponds directly to the data structure underlying the game and it’ll be pretty helpful to the puzzle game I eventually want to do down the road. Since I don’t want gradual movement anyway, “moving” blocks by toggling the visibility on a grid seemed like a fitting idea to me.
The TetrisGrid contains an Vector2D array called “Active”, which saves the XY Coordinates for the 4 active blocks as 4 Vector2Ds. At game start (or on Space) one of the shapes is randomly generated, then all Cubes at the current active location are toggled invisible, the new Coordinates are saved into active and then the new Coordinates are toggled visible. This works fine.
What also works fine is vertical and lateral movement on WASD. The blueprint gets the coordinates, adds (or subtracts) 1 from X or Y, checks if the that’s within parameters (>=0 and <=9 or <=21) and then toggles the corresponding cubes.
What’s strange
With rotation, things got a little strange. First of all, here’s something that works and something that doesn’t but I don’t understand why.
This is how I’ve set up the rotation:
First of all, a copy of the 0 Element of our Active Array gets saved to a separate Vector2D called Rotation Center. Next, I Set the Temp Active Rotation Array to the Active array. After this, the ForEachLoop below starts.
For Each Element in the array, rotate the Element and save it back into the array. This is done by making a +/-90 Degree Rotator, subtracting the Rotation Center from the current Element, turning it into a Vector3D, rotating it, truncating it back to 2D, re-adding the rotation center and presto, the Vector2D should be correctly rotated for all four blocks. I’ve tested the numbers I get from this and compared them to coordinates I got from doing this by hand (or rather, using Matlab and roation matrices) and both this and drawing it by hand on paper shows that the coordinates should be correct, but here’s where things get funny.
First of all, I’m aware that I forgot to connect the loop with the Set Array Elem in the top picture. I’m aware of this, but this isn’t the problem. The current state is the one on the bottom, and I recreated the problematic one when I decided to make this post. This is just to illustrate the problem that puzzles me so.
In the top picture, I first save the new values back into the Temp Active Array, then I check if all values are 0 <= X <= 9 0 <= Y <= 21. Is that NOT the case, I set Move Possible to FALSE.
In the bottom one, I first check if the move is possible and if so, save the values into the Array. Otherwise I set the Bool Variable to FALSE.
Once the loop is complete, I check the Variable. If it’s false, I reset it to TRUE and the entire thing stops right there. That’s it, nobody cares about what’s inside of Temp Active Array ever. So here’s the puzzling thing: If I do it the top way, unrotated values are first saved into Temp Active Array, which are then approved by the AND gate. Then the invalid rotation happens and the entire thing rotates outside of the grid. I don’t quite understand why, because to me it seems like that the top way should work pefectly fine and it shouldn’t matter at all, but only the bottom one works correctly.
What doesn’t work
This one’s quite a lot more difficult and the question I’ve been cracking my head over the last three days:
The roation works, but at the same time it doesn’t!
Here’s what happens after we’ve calculated Temp Active Rotation Array:
If the move was deemed legal, we first go through Active by way of ForEach and feed every vector to an Event that toggles the cubes invisible. Afterwards, we set Active to Temp Active Rotation and use ForEach on Active to toggle the corresponding cubes visible. And this is where things get funny:
I’ve verified several times that Active has saved the correct coordinates. But under certain circumstances it just doesn’t work and the behaviour seems completely erratic to me (which it probably isn’t, but I lack the knowledge to identify the cause and pattern.)
Every block rotates correctly as long as all of its cubes have X coordinates that are bigger than 4 or 5 and the Y coordinates are all bigger than 6 or 7. 0/0 is in the top left corner, with increasing numbers to the right and bottom.
The T-Block always rotates correctly.
The O and I block rotate incorrectly as soon as the first or second rotation, but the O block does the fourth one right.
Some blocks screw up at the third rotation, others at the sixth (so goes one roundabout correctly, does another rotation and THEN it’s broken)
With broken I mean that either one or two cubes aren’t displayed at all, or they are displayed in the wrong place.
Once a cube is broken, it always rotates incorrectly, no matter if you do it in the top or bottom half.
Some blocks sometimes get fixed if you move them horizontally or laterally. If this is the case, you can usually reproduce this as many times as you want in the exact same spot.
The X/Y coordinates the cubes are on seem to influence the way the block breaks.
I’ve looked at a whole bunch of different error sources so far and I’m pretty much at my wit’s end. The coordinates saved are correct, I’ve built safety measures that the same cube can’t get accidently toggled visible and then invisible again and everything else seems to either work correctly, or is so broken that it’s indistinguishable from working correctly.
I’m guessing that especially for the second question, it’s pretty hard to do diagnose the problem without the project at hand, so if someone wants to have a look at it and would be so charitable to tell me where the problem is, that’d be immensely helpful. Unfortunately it’s 600 MB since just used the UE4 zipper and I don’t know how to make it smaller (if there’s a way at all)
Since the project is too big to be uploaded to the forums directly, I uploaded it to mediafire: http://www.mediafire.com/file/hlkfjcqb0q4b3az/Tetris.zip/file
WASD moves the Tetromino
Q and E rotate it
**SPACE **cycles through the shapes and resets it to the starting position. This also repairs it if it’s broken.
X displays the current coordinates saved in active.
0-9 toggles the 0 Block in Lines one through nine.
And thank you to anyone that took the time to read through this.