Click to launch the HTML5 version of the game

First, take a look at the above link. There's score, 7 tetriminos, slowly growing difficulty - standard things for a Tetris game. The catch? There isn't a single line of code. Nor a single variable. It's all done in GameMaker's "drag & drop" visual scripting.

The story of how this even happened is like so - yesterday was another day when my internet connection disappeared for half of the day without any logical reason whatsoever. As I look at the top of my now-static TweetDeck timeline, and notice this bunch of tweets from Vlambeer's Rami Ismail. While you can generally agree with points outlined, few things could have had better clarification:

1. Difficulty depends not only on developer's coding skills, but also on the tools used.

   For example, making a "space invaders" game in most modern tools with built-in memory management, collisions, and function sets is easy enough, but should you go lower level... storing invader information in an array? Storing and moving around dynamically created player and invader bullets?? Programming trajectories and destructible defenses??? Not as much careless fun as you may have envisioned. Pong may seem suddenly simpler with base requirements of just a bunch of variables and inverting ball x/y velocity for bounces.

   Additionally, certain tools are best suited for certain task. For example, it is easy to make a turn-based puzzle game in PuzzleScript (hence the name) due to the way engine is based on "rule" definitions. Making a platformer game in PuzzleScript, however, is a much harder feat. It isn't, by no means, impossible, but requires more planning than it would take with a "platformer-centric" engine.

2. Game development isn't just about having the right tools/resources/experience, but also actually using them creatively. As such, programming in general is often about finding an approach to the problem that isn't the most blatantly obvious or expected but produces results more efficient in terms of computer of development time.

To not make it all look like a rant or a opinion piece, the rest of this post is about creative use of tools - particularly, making the aforementioned Tetris in GameMaker without a single line of code or variable.

The Common Approaches

The ways that you are generally expected to be making a Tetris-like game in are generally around the following:

• Store the field as a 2-dimensional array.
  If tools used do not support 2d arrays, store the field as a [cols * rows] long 1d array and prepare to face potential uncaught "index wrap" problems later on.
• Store the falling block as a similar (except smaller) 2d array. With the classic variant of tetris that's a 4x4 array. You can also call it a "matrix" instead of "array" if that makes you feel cooler.
• Rotate the falling block by rotating the contents of the according array (more or less means circularly swapping the array cell values around). Also ensure that player cannot rotate a block in such way that it would get stuck in the wall or outer field edge.
• Calculate collisions between the falling block and field blocks by testing two arrays for overlaps. Note that X/Y "iterator" indexes have to be restricted accordingly to avoid misbehaviour when the falling block is close to the map edge (thus it's array bounds exceed beyond the edge by one or two blocks).
• Line clearing is done by checking if all cells are filled in any given row. If that is so, shift the contents of all rows above the filled line downwards (overwriting it), and add score bonus accordingly.

Indeed, that doesn't sound too simple. At least not to someone new to programming.

So the question is - how to make the process not that?

---

Since this blog isn't all about using increasingly more antique versions of software, this tutorial is intended for use with GameMaker: Studio.
A separate editable project file (GMK) for versions 8.0/8.1 is available in the end of this post, but uses slightly different approaches to warrant consistent looks.

Blocks (for a start)

With Tetris being a game about stacking blocks in a field, you logically need to represent the blocks and the field somehow. Arrays are relatively complicated. What is not complicated, however, is GameMaker's "objects".

Let's add two basic objects - obj_solid, which will be used for collision checking,

and obj_block, which is an actual 1x1 block/cell in the field, and inherits from obj_solid:

The sprite shared between these two objects is just a 32x32 square:

spr_block

While the mask shared is a a slightly smaller (16x16) square inside a 32x32 image:

spr_block_mask

The mask is not needed just yet, but it will later save us from having to tweak collision mask settings of some other graphics.

The Field

The next step would be to set up a room that the game is going to be taking place in. Here I'm going to make a 320x480 room, which with 32x32 blocks converts into a 8x14 field for the actual game.

Both for the sake of aesthetics and easier behaviour scripting the left, right, and bottom edges of the room are to be covered with instances of obj_solid (essentially walls and floor):

room0

The background used here is a similar 32x32 square, except lighter and with a small "frame" on the edges, giving it a bit of a texture and potentially allowing the player to estimate block distances better:

bck_grid

Piece Objects

The next important part of the game is falling blocks.

Let's start with the basis for other shape, which will also represent the square block:

As you could expect, the sprite used is just a 2x2 block:

spr_Ob (origin x32 y32)

Note, that, since the blocks are going to be rotatable later on, the sprite origin/centre point is to be set, in this case to the centre of the image (x32 y32).

Other block types are going to inherit their behaviour from obj_fall:

spr_Lb (origin x48 y48) Information about object: obj_Lb Sprite: spr_Lb Parent: obj_fall	spr_Jb (origin x48 y48) Information about object: obj_Jb Sprite: spr_Jb Parent: obj_fall
spr_Sb (origin x48 y48) Information about object: obj_Sb Sprite: spr_Sb Parent: obj_fall	spr_Zb (origin x48 y48) Information about object: obj_Zb Sprite: spr_Zb Parent: obj_fall
spr_Tb (origin x48 y48) Information about object: obj_Tb Sprite: spr_Tb Parent: obj_fall	spr_Ib (origin x64 y32) Information about object: obj_Ib Sprite: spr_Ib Parent: obj_fall

With these intact the standard set of tetriminos is complete, and sprite origins will ensure that piece rotations will comply with Super Rotation System of Tetris Guidelines (although this example in general will not comply with TG in due to non-standard field size and simplified feature set).

Also note that you will need to tick "Precise collision checking" checkbox in each of these sprites, or they will default to rectangular bounding boxes, which are not quite what you want for these.

Piece Physics: Gravity

For the falling pieces to be actually "falling", they need to move vertically.

Fortunately, the classic concept of "gravity" in Tetris is just pieces moving downwards on the timer, which translates to an alarm event in GameMaker:

As you can see, in the "Create" event the alarm is set to trigger for the first time in a moment after creation, and then, whenever it triggers, the piece moves 32 pixels downwards and the alarm is reset to 12 frames (which is 0.4 seconds on 30 FPS0.

Such approach also permits to implement "soft drop" (increasing the speed at which a piece descends) by simply reducing the alarm counter to 1 frame as long as the key is held:

Piece Physics: Horizontal

Logic for horizontal piece movement is nothing particularly complicated - if a key is pressed, and the adjacent position in that direction is not occupied, shift the piece in that direction:

Of course, it is also possible to introduce continuous movement in a direction while a button is held by using alarms or variables, but such exercise is left to the reader.

Piece physics: Rotation

As previously mentioned, normally the piece rotation could be quite a bit of a trouble.
However, since we are going to be actively taking advantage of built-in collision system anyway, we can simply rotate the object:

The logic used is dead simple - rotate the piece; if the piece is now stuck in a wall, rotate it to the original state. It is also worth mentioning that the "Transform Sprite" action misses quite an opportunity to have "relative" flag apply to the angle specified.

Another approach that you can take with this is creating separate graphics for each rotation and changing them accordingly (this is what is used in GM8 version of the example to avoid visual artefacts, by the way), but importing and linking 24 pieces of graphics to the game logic is not something that you should be doing with your life, if possible.

Controller Object (aka Piece Dispenser)

Now that the pieces are made, and a fair chunk of their logic is in place, it would be reasoned to actually implement a mechanism for their selection and creation.

In this case the controller object is going to serve 3 main purposes:

1. Displaying the current score
2. Permitting to restart the game session
3. Dropping new pieces into the field

To be able to definitely draw the score above other game elements it will need a negative "depth" (z-index), and "create" event is to contain resetting of both score and block drop timer:

Score drawing is not too much trouble - only need to set the font (for which I've imported a 3x5 monospace font at 32px height named "fnt_score"), color, and do the actual score drawing:

Restarting the session is similarly the smallest of challenges here:

Block decision algorithm is a bit trickier though. If we do not pursue a guideline algorithm for forming series of bricks to drop (which, admittedly, would be kind of a mess if done in D&D), we should at least have even chances of any piece type dropping. Thus...

What is going on here is:

• GameMaker has two D&D actions for creating instances of object - the "Create Instance", which creates an instance of specified object, and the "Create Random", which creates an instance of one of up to four types picking randomly. Noticeably, neither of two alone is not sufficient to fit all 7 piece types.
• Additionally, two piece types have their centres-of-mass set at block intersections, while the other five have them set at block centers, meaning that they have to be created at different offsets and thus two actions are not sufficient either.
• So, first we try to create a T-block with a chance of 1/7.
• If that fails (leaving us with 6/7 chance), we check for 1/3 chance and create either a I-block or a square block if it's satisfied (2/4 * 1/3 * 6/7 = 1/7 chance each).
• If that fails as well (leaving us with 4/7 chance), we create a L-block, a J-block, or either of "snake" blocks, granting 1/7 chance for each.

And, with this done now, an instance of obj_control is to be placed at the top-middle of the room (as the blocks are being created at positions relative to it):

room0 (obj_control added)

Piece Physics: Landing

Since we are still taking reasonable advantage of built-in collision system, detecting the moment of a piece landing is no problem at all:

As you can see, the previously created blocks now reside in a "location below the block is free to move in" condition, and otherwise it schedules obj_control to drop the next piece in half of second and destroys the piece.

If running the game now, it can be noted that pieces appear, fall, and can be accordingly controlled, but simply disappear when they hit the floor, as that is what exactly the event does at the moment.

Piece Physics: Splitting

Now, to the interesting part. What happens after a piece lands? It needs to converted into separate blocks on stage. And that can be a bit of a challenge.

The most obvious thing to do would be to simply "hardcode" creation of 4 blocks into each piece. Which admittedly kind of works (and is used in GM8 version of example) but that's about a hundred extra "Create Object" actions (4 for square piece and then 4 actions for each of 4 rotations of each of 6 other pieces) to be put in into the pieces, and, let's face it, it's no fun to spend a number of minutes putting in coordinates and checking if you have made no mistakes while doing that.

A more efficient way is to check, which cells of the field the newly landing piece overlaps, and fill them with blocks. The technique to doing that is not complicated, but an interesting trick. We're going to need this object:

When it is created, it sweeps over each cell in the 8x14 field by moving horizontally while in the row, and then moving back and down as the row ends (similar to a common typewriter mechanism).
For each of it's positions it checks whether it is overlapping with the falling piece, and creates a block at it's position if that is so.
Once it's work is done, it simply self-destructs, as there is no other purpose for it.

It is to be created in the previously modified obj_fall' alarm 0 second branch just before destroying the instance:

Running the game would reveal that now the pieces nicely land onto the stage, and it generally seems like an almost complete game! Except for few details, of course.

Line clearing

So, to the supposedly most complicated part of the game. Is it that complicated? Well probably not that complicated, but would take some thinking to come up with for the first time. The logic is as following:

For each row of the field,
If each cell in the row is filled,
Destroy all blocks in the row,
And move down what was above it.

Nothing of that is particularly scary, but, not to end up with one messy object, let's make each step a separate object type - in order, obj_check_field, obj_check_row, obj_destructor, and obj_gravity. Since the functions of these are going to be chained, it's recommended that you create and name 4 blank object to avoid having to return and edit actions later.

obj_check_field serves the sole purpose of creating a obj_check_row at each row, and then cleaning them and itself up. Like so:

obj_check_row is to be doing the actual work: it checks the each cell in the row for presence of an obj_block, stops execution if any are absent, and creates the row destroyer if it has made it to the end. Here's a small and a rather poorly drawn diagram to illustrate the logic:

While the behaviour is determined by just another 7 action blocks:

obj_destructor is going to be doing the actual destruction of blocks in the row - it appears for a frame, destroys blocks on contact, and disappears, while creating an instance for the last part of the process above it:

The sprite used here is a 256x32 rectangle, both serving as a collision box, and to hide the disappearing blocks for a moment before new ones are shifted in their place:

spr_destructor

obj_gravity is a 256x448 (hence the offset used in obj_destructor) rectangular object that pops into the game for a single frame, shifts blocks that it touches by one row downwards, and disappears. The logic is similarly extremely straightforward:

Except for one detail - as you can notice, it uses a sprite called spr_gameover. That is simply due to the sprite being appropriately sized, which allows to reuse it (as the object is invisible anyway) to avoid setting sprite scaling explicitly:

spr_gameover

With all that done, one thing left to do about this is to insert creation of the first-step-object (obj_check_field) into the obj_fall's alarm 0 event after the creation of obj_block_printer:

Now there are only a few things left to do.

Condition of defeat

"Game over" screen is composed from two objects - an actual "game over" overlay using the sprite imported earlier,

(depth is set to display it over the blocks, but under any potential game UI)

And an invisible "area check" object that is going to be sitting at the top of the field and waiting for a block to overlap it to trigger defeat:

Upon impact it creates the "game over" overlay, resets obj_control's alarm 0 (to prevent it from creating additional falling pieces), and self-destructs to prevent creating additional "game over" overlays.

As per name, it is to be placed at the top of the field:

room0 with obj_top added.

Scoring & difficulty

Score is to be awarded when the player clears a line.
Additionally, in the classic case score awarded depends on lines cleared at once and the game level (which we don't have here).
So the simplest method to approach this here is going to be to simply add 4 conditions (for each of 4 possible cases) with score being changed accordingly.
Here I've used 100pts for 1 line, 300 for 2 lines, 500 for 3 lines, and 800 for 4 lines cleared at once.

While levels are a bit trickier to implement, having no difficulty curve at all is not particularly good, so by least it would make sense to make pieces gradually increase their speed as player's score grows. I've decided to accomplish this with a formula being

fall_interval = 20 * 0.995^{score / 200}

Which translates to an expression being 20 * power(0.995, score / 200), which we can put in instead of the constant pace in obj_fall's alarm event. One could argue that the use of a function is "cheating" around the Drag and Drop system, but GameMaker does not have a "power/exponent" operator and thus there's no better way of doing this.

The final alarm event with all changes looks like this:

And so that's how you make a Tetris entirely in GameMaker's Drag & Drop.
You can also download the editable project files:

Download GMZ Download GMK

(again, note that GMK uses fallback approaches for older versions)

Update: just in case you were wondering, yes, of course you can also apply the same principles to do the same thing in GML - here's a GMZ. Code is largely a direct translation but with printer and line checking objects removed in favor of adding equivalent code into obj_fall's alarm 0 (as I bet that you understand the concept of loops if you know GML).

Related posts:

• GameMaker: Click ‘n drag to pan view
• Variable references in GameMaker (2023 edition)
• GameMaker: Smooth pixel-perfect camera
• GameMaker: 2.3 syntax in details
• A small guide on writing interpreters, part 2