Looking for an efficient way to design random patterns for my Tetris-like

So I’m working on a kind of “tetris-like” game where the player is controlling a sidescrolling character and must platform around on the falling pieces, which they can also control. It’s a sort of multitasking challenge where the player has to make sure they don’t build to the top of the screen while simultaneously avoiding getting squished or falling off the screen, etc.

Anyways, I’m trying to create a robust system for designing different piece patterns. The blocks within the pieces can sometimes be swapped out with platforming elements like ladders or platforms, so the way my current system works is, when a piece spawns in, it randomly picks something from an array of arrays of vector3s (accomplished using structs), with the X and Y values determining the location of each block in the piece and the Z serving as a kind of “ID” to change the block’s type. Here’s an image of the values for the classic “T” piece, as an example.
imageimage

And here’s a modified version of the 4x1 piece, one big ladder topped with a platform.
image

Needless to say, this system is really impractical, messy, and inefficient. I have plans for all sorts of patterns and variations, and an array of arrays of vector3s isn’t going to cut it. At first, I tried looking for a kind of “hybrid variable,” say, a vector 2 and an int, so I could make an array of those instead, but even if such a thing does exist, I feel like it still wouldn’t be the best way of doing this. Any suggestions on what I could do to make this system better?

It depends on how complex you want your end product.

If, for example you knew you were going to create, at largest, a 3x3 piece where every part had the same dimensions, then you could spawn ‘holes’ in for areas with nothing, so a singular set of logic to make a 3x3 could also potentially generate the tetris-shapes.

Otherwise if the different parts are different sizes, can be rotated, etc, it’s more like assembling legos (to my mind) and you’d want to use things like sockets to help align/orient things and then actually build it piece by piece. Start with one, then add another here on this socket, next on that socket, etc.

my 2cents.

What, specifically, do you feel is inefficient about it?
If you have the frame rate you need on the target hardware, that’s good enough, at least for a game made by a single developer.
If you have the ability to express the things you need to express, and iterate on the gameplay, that is good enough for building a game.

The #1 enemy to shipping a game, is trying to perfect a game. You have to become comfortable with sweeping ugly ■■■■ under the rug and ship it anyway, as long as it’s not structurally deficient or has cost/security problems that kill the product. You won’t ship anything if you believe that everything can and must be perfect.

Now, if the tools are so bad, that you simply can’t/won’t iterate enough to make a fun game, that’s the time at which you build better tools.
And if the runtime is so obese that your target hardware simply can’t deliver the experience you want (frame rate, battery life, response time, etc) then you need to fix that.

From your post, it’s not clear where along this spectrum you currently are.

If I were to build a bunch of “pieces” like “life sized Tetris” blocks, somewhat like you describe, then I would make one blueprint based off of Actor for BP_Piece, and then I would make additional pieces based off of that, where each chunk is a static mesh component. (And other components, for particles/sounds/lights/ladders/etc.)

The base BP_Piece would implement the necessary shared bits of gameplay, and the components would then make up the totality of the actually spawned “piece” in the game.

The good thing with this is that you get a lot of flexibility in how you build the pieces (they are all blueprints derived from BP_Piece) and you get a lot of editor support already built in (you can use the 100 unit movement grid in the editor window to make sure all components snap into reasonably logical places, for example.)

If you need to procedurally generate each piece using random numbers, then that’s something different – you’d probably start with something like a grid, and have components of various size/attachment that you can add to the piece being generated, until it is “big/complex enough.” But it doesn’t sound like that’s what you’re doing – you’re just building N different kinds of pieces (just like Tetris) and spawning them using some random function?

You make some good points. The system, as it is currently, is pretty flexible, I can make just about any shape I want and easily implement new interactibles/“special blocks” by making new BP classes. The overarching “Tetronimo” BP picks one of the patterns from the aforementioned array of structs on construct, adds the appropriate amount of “Block” child actors, gives them the proper offsets (derived from the X and Y of the chosen pattern), then changes their own internal child actor if they are flagged as a non-standard block (the Z value).

I guess the issue I have is more of a tools/QoL thing. The Vector3 solution just feels…scuffed, like it could be improved upon, you know? It’s doable, but adding new patterns is a slow, clunky process that’s hard to organize. I guess I was looking for something akin to the big libraries of room layouts you see in roguelikes like The Binding of Isaac or Enter the Gungeon (presuming that’s how those games work, I don’t know for sure). Probably just me overshooting for perfectionism’s sake, especially considering this is largely a personal project to pass time. :sweat_smile:

Yes, this is why I suggest that each pattern should be a blueprint.
This is also why I suggest to use child components not child actors.
At that point, “make a new pattern” is simply “subclass the base blueprint, and add the actors, inside the Unreal Blueprint Viewport editor.”
When you instantiate the blueprint, it comes ready-made just like how it was in the editor; no need to manually assemble anything.

I’m working on a game concept that involves a character maneuvering on falling blocks, similar to Tetris. I’ve got a system in place where blocks with varying functionalities can be used within the falling pieces. Currently, I’m using an array of arrays of Vector3s to determine block positions and types, where the Z-axis serves as a kind of “ID” for the block’s type. However, I’m looking to make this system even more versatile. Does anyone have suggestions on how to expand this system for more complex patterns? :saluting_face: