INTRO:
In the history of the puzzle game genre, there had been quite a number of titles which have the player character manipulating blocks; classic examples of these include Chip’s Challenge.
However, as the years went by, this gameplay element would become dreary and dull to jaded minds. This is mainly due to the limited utility of these blocks; they often act as little more than obstacles, either to be removed from the player character’s path or placed into that of adversaries.
Fortunately, there are rare few games which shake up this gameplay element. One of them is (Singaporean game-maker) Ludochip’s Cubetractor, which makes use of the blocks as “ingredients” for the creation of other objects.
PREMISE:
The world in Cubetractor’s story is one which is populated by sentient robots, who typically behave a lot like humans so that they seem familiar. In this world, the robots engage in the art of “cube-tracting”, which is the manipulation of blocks from afar, usually with the intention of having them collide with something else.
One of these robots is Endroi. Endroi would have been just another robot, if not for its considerable talent at the skill of “cube-tracting”. Coupled with its bursting enthusiasm, considerable ego and near-disregard for what other robots have built, this talent of Endroi would become a source of frustration or amusement for other robots.
As the player guides Endroi further and further onwards through the homes of the robots, more of the backstory will be revealed, such as some hints that there had been a civil war of sorts between Blue and Red robots. On the whole though, the story appears to be a whimsical tale of an overwhelmingly self-assured robot who is always looking for the next challenge, for better or worse.
GRID-BASED LEVELS:
Players who are experienced in games which make use of 2-D sprites and grid-like environments would be quite familiar with the levels in Cubetractor.
Having said that, Cubetractor’s gameplay experience is divided into a series of levels. Each level has the player character inserted into a 2-D environment, which is bounded by the limits of the screen. The spaces within a level always follow a raster-like organization. Static objects in the level can only ever exist within one node in the raster.
The player character and a certain type of mobile hostiles are not limited to the grid-like arrangement of the levels. Their method of movement will be described shortly.
MOVEMENT:
Perhaps in a divergence away from games which use blocky grids for their environments, the sprites of the player character and other mobile characters are not contained within single nodes in the grid. The hitboxes which determine collision with other objects can exist in between nodes.
In the case of the player character, its movement-collision hitbox is indicated by its quadrupedal appendages. Its bulbous head does not have a hitbox, at least for the purpose of determining collision with objects in the environment.
This can be a bit unfamiliar to players who are used to playing games which have sprites occupying only a single cell (and thus having the boundaries of their hitboxes defined by the extent of their sprites).
Granted, one can argue that with enough practice, the player can become accustomed to associating the player character’s feet with its movement-associated hitbox. However, any lapse of concentration will certainly lead to the robot bumping into walls and blocks.
Of course, the player is to be blamed, but if the player character’s hitbox designs had been placed around its sprite instead of around its feet, there would have been less mishaps.
PULLING BLOCKS:
Early on in the game, the player character is taught about its ability to pull blocks (called “cubes” in this game) from afar; hence the titular “cube-tracting”.
Handy visual indicators show the expected sliding path of a block to be pulled, as well as which block it would be.
Blocks will always slide along a single straight path; they cannot be re-directed mid-slide. Perhaps there is a lost opportunity to implement a feature to do just that. However, considering the other gameplay elements which are associated with moving blocks around in Cubetractor, this limitation is not too underwhelming.
COLLIDING BLOCKS:
Sliding blocks become impact hazards, smashing into anything which is not a block along the way. The damage which they can inflict is not inconsiderable; the game has a few levels early on which will teach the player about this. In fact, making use of blocks to smash things is often a very effective and quick solution to a puzzle.
Interestingly, when a block collides with something, it is not always immediately destroyed. Rather, whether it is destroyed or not depends on how much damage it has inflicted; if it has inflicted up to its maximum damage, the block is destroyed. Otherwise, it will thrash and go through anything that it collided. It moves on to hit something else with reduced damage. Unfortunately, the game does not take advantage of this peculiarity in many puzzle solutions.
Sliding blocks are, of course, a hazard to the player character as well. More often than not, the consequence of goofing up the pulling of blocks is having the player character smashed by one.
GETTING DAMAGED & REPAIRS:
Endroi the Cubetractor may have plenty of enthusiasm and determination, but it is not implacable to the point of being unstoppable.
For a reason which will only be explained near the end of the game (if the player has not already figured it out before that), many machines which Endroi would encounter are automatically hostile to it. They will attempt to damage Endroi, usually by shooting or colliding with it.
Not unlike an old-school SNES-era protagonist, Endroi becomes temporarily invulnerable when it gets damaged, its sprite flashing in a manner that veteran players of that era would be quite familiar with. However, Endroi is also stunned for a couple of seconds, which can be very costly. Fortunately, the invulnerability frames last longer, so the player can have Endroi scooting away from danger.
Endroi can only take so much damage before its head explodes. Fortunately, Endroi can repair itself by running over conveniently placed (but limited) wrench power-ups.
Interestingly, Endroi’s health bar will indicate whether the player still has a chance to get the “Master” medal for the current level or not. It is initially blue, though it changes to red permanently upon the first hit.
MEANIES & TURRETS:
The main obstacles and sources of danger in the player character’s way are “Meanie” robots and turrets.
“Meanie” robots are mindless robots which are programmed to be mobile hazards in the obstacle courses. Oddly though, there are only two types of Meanies, neither of which would surprise a jaded veteran of puzzle games because they are frequently-used archetypes of enemies. One is a dumb critter which patrols back and forth between a fixed path but does nothing else, while the other meanders around until the player character comes close enough, upon which it makes a pathetically slow pursuit.
There may have been plans for more types of Meanies, considering that the game’s creators have already created a category for them. However, there are only ever two, right up to the end of the game.
Turrets are more interesting to deal with, and this is just as well because they are the main source of challenge in the game. The player will also be making extensive use of them (more on this later).
There are three different types of turrets, each of which is surprisingly different from the rest, even though they share the similarity of shooting projectiles.
The first turret fires a volley of three shots, which are easy to dodge – if there is only one turret. More often than not, there will be more than one to deal with.
The second type of turret (called the “boltgun turret”) has a short range, but fires so rapidly that any static structure which Endroi would build in front of them is very much screwed. (There will be more on building structures later.) Endroi is barely fast enough to book it past them without getting hit.
The third type of turret, called the “Spire” because of its rather disturbing look, fires homing projectiles. However, the projectiles are slow; the time between shots is also long. Dexterous players would have no trouble dodging them, though in later levels, there are quite a lot of them to contend with.
Many of the puzzles later in the game would make use of troublesome combinations of turrets, requiring the player to deal with individual turrets separately in order to make the rest vulnerable.
It has to be noted here though that the hitboxes of projectiles, particularly those of the Spire’s, are quite large. It is very easy for them to hit the corners of walls, as well as those of material cubes (more on these later). Indeed, it is in the player’s interest to observe these peculiarities, so that they can be used in puzzle solutions.
Interestingly, each type of turret also has targeting priorities. For example, hostile Spires will almost always target the player character above anything else, which is a behavior that can be exploited for some puzzle solutions.
SUPPORT STRUCTURES:
In addition to turrets, there are static structures which complement their defensive capabilities. There are barriers, which, as their names suggest, block shots from hitting anything past them, as well as blocking any mobile objects from moving past them. The only exception is Spire shots, which simply go over barriers. (They cannot go over material cubes though.)
Then there are power generators. These bolster the firing rate of the turrets which they support, but they tend to be more fragile than most other structures.
The third support structure is one which is specifically designed to counter hostile Spires. After having been placed within the field of fire of a hostile Spire, the structure will always attract their fire. However, there are not a lot of opportunities to make clever use of it, which in turn gives rise to the impression that its inclusion in the game had been a slap-dash decision.
MATERIAL CUBES & BUILDING STRUCTURES:
Material cubes are the objects which the player will be concerned with the most during the gameplay experience of Cubetractor. The player will be having these pulled around, eventually colliding with other things, typically other material cubes.
In the oddball world of Cubetractor, structures are constructed by colliding material cubes into each other. Different combinations of cubes result in different structures; the combinations can be known by looking at the “tech” screen before every level.
Newly-built structures take time to become ready, during which they are vulnerable to being damaged. Their health bars also will not appear until after they are ready. Indeed, in most of the player’s solutions, the player has to protect emerging turrets from hostile fire, usually by putting something in its path.
In addition, the player has to build structures at the correct spots, e.g. at the correct angles relative to incoming hostile fire. This is not always easy, because the player has to gauge where the blocks would collide.
Only the player character can build new structures, and these structures are always allied with it. There could have been a lost opportunity to implement a feature which allows for hostile structures to be built, though of course this would have made puzzles a lot more complicated.
SPAWN POINTS:
Fortunately, material cubes are not limited in supply, in case the player has made a mistake in placing structures. They appear on top of spawn points which will create new material cubes after the previous ones have been expended.
These spawn points are conveniently marked with dashed borders, with colours which correspond to the types of blocks which they spawn. Perhaps colour-blind players might not be well-served here, but this is otherwise adequately convenient for any other players.
There are also spawn points for mobile enemies; these are depicted with pink-red portals. These will continuously spawn in fresh mobile enemies, which will complicate matters by, for example, drawing the fire of the player’s turrets when the player would prefer that they shoot at something else.
LEVEL DESIGNS:
Most of the level designs in Cubetractor challenge the player to deal with strategic placements of hostile turrets and the barriers which protect them. The player will often need to place turrets of his/her own in order to out-range those of the enemy, or place them at certain angles relative to the location of opposing turrets such that they are protected by walls or material cubes.
Furthermore, the player will often need to decide which opposing turrets to be removed first. Amusingly, for some of these decisions, the player will need to have Endroi dash across the field of fire of more than one turret.
The levels in Cubetractor are categorized into “main levels” and “side quests”. The “main” ones are those which advance the (whimsical) storyline, whereas the “side quests” have the player character meeting and knowing other characters better (usually by thrashing the levels which they have designed).
To complete a “main” level, the player has to destroy all opposing structures and mobile hazards, in that order. To complete a “side quest”, the player has to do the same too, but also collect all batteries which have been dropped throughout the level. (Mobile hazards will keep respawning until the static ones have been destroyed, if there are spawn points for these in the level.)
Throughout every level, the player can collect batteries, which act as Cubetractor’s own thematically matching take on the gaming trope of collectibles. Other than that, there is little other substance to these batteries.
EXIT TELEPORTER:
Completing a level causes a teleporter to appear. This is where the player character needs to go in order to end a level. The location of the exit teleporter itself can also sometimes be a hint to the most efficient solution for a level.
In hindsight, considering the goals of the levels, the inclusion of the teleporter as a feature may have been unnecessary busywork. In the main levels, the player character could attempt to reach the exit teleporter as early as possible in order to score a lower time record; it so happens that to reach the highest ranking for a level, a short time record needs to be achieved.
Yet, to obtain the highest ranking in a main level, the player must collect all batteries anyway. Furthermore, to complete a “side-quest” level, all batteries in the level must be collected. Therefore, the teleporter might seem a bit unnecessary because having the player character teleport out after having collected all batteries would have been more convenient.
VISUAL DESIGNS:
Cubetractor is a 2-D game which makes use of sprites, so players who are used to games with 16-bit aesthetics would not be much surprised at the looks of this game. The characters, being robots, are not much to look at; they are rendered in a static cartoonish manner which would be all too familiar to players who had watched weekend morning shows before.
Perhaps the only character which can provide a little amusement to jaded eyes is the protagonist itself. Endroi has huge red lips, something which could be misconstrued as a visor of sorts if Endroi had not said that they are lips.
There are a few visual quirks in the designs of the levels in Cubetractor which suggest that Cubetractor might have been designed for a 2-D top-down RPG. Chief of these quirks are roads and paths which lead to somewhere off-screen in some levels.
As elaboration, these roads and paths do not always tally with the apparent progression of the protagonist’s adventures. Where the protagonist appears to go further north, as seen in the level selection screen, some roads and paths go elsewhere other than north, and for some levels there are no northerly roads. (It is also worth noting here that the protagonist does not need to use roads and paths; Endroi is teleported into and out of levels.)
This is hardly a major complaint of course, because these visual designs do not affect gameplay in the slightest. Nevertheless, to those who suspect easily, they give an impression that assets which are meant for another game had been recycled into Cubetractor.
SOUND DESIGNS:
Cubetractor has music that, with just a bit more effort, would have been quite trippy to a pair of ears which are fond of electronic and chiptune music; the track that is “Digesting Duck Circus” is a particularly good example. However, the tracks are very short, with the long ones often little more than one-and-a-half minute in length. This means that the tracks loop a lot, which causes their appeal to eventually diminish.
Other than the music, there are the sound effects, which consist of sound clips for occurrences such as explosions and shots fired. There is not much surprise from this aspect of the game. There is also no voice-acting.
CONCLUSION:
Cubetractor’s gameplay element of combining blocks to create things is nothing new in game history. After all, this has been around in other sub-genres of puzzle games, such as those that have the player dropping blocks or orbs onto other things within a screen. However, Cubetractor has implemented this together with otherwise dull block-manipulating gameplay, thus resulting in a proverbial breath of fresh air.