Transistor

INTRO:

The first title by Supergiant Games was well-received, it having been released during the renaissance days of indie games. Bastion was praised for telling a riveting story, alongside otherwise solid combat.

Supergiant Games supposedly learned lessons from Bastion, though how well it applied what it had learned is debatable. Its next game, Transistor, is notably different from Bastion in many ways.

PREMISE:

The game does not start with any exposition on the backstory. In fact, it immediately begins with a tragic scene. Red, the protagonist, is kneeling over the corpse of a male acquaintance, who has been killed by a massive sword that is made of arcane electronics. She retrieves the sword, which is now apparently inhabited by the mind of her dead acquaintance, and goes out on a quest for, presumably, revenge.

WALKABOUT STORY-TELLING:

That is the most that the new player would get from the starting scenes. Everything else has to be inferred and then cobbled together as the playthrough progresses. Official written and spoken lines on the main plot and backstory would be gradually given to the player. Some bits on the lore of the setting are even placed behind certain gameplay-related tasks.

Bastion benefited from a narrator who made short remarks that reveal the backstory and the plot as the playthrough progresses. The sword’s inhabitant does make remarks too, but these are not intended for exposition. Rather, he is making a one-way conversation with Red, who has lost her voice.

The player has to search nooks and crannies to find terminals that typically summon in more enemies. The user interface of the terminals, the options that they pose to the user and the sword’s remarks about these reveal things about the city of Cloudbank, which the game is set in.

The only section of the game that has story-telling that is more reasonably paced is the last two hours or so. This is when things about the behind-the-scenes events that led to the current predicament are revealed.

THE SWORD:

The sword would eventually be named as the eponymous Transistor. The sword is made with electronics of sci-fi provenance. It would be revealed as capable of storing the minds of seemingly deceased individuals, as well as channelling the will of its wielder.

The minds of the inhabitants and the wielder happen to unlock functions in the sword. These functions – simply called “Functions” in-game – are named according to various IT terms, followed by a pair of parentheses. The names can seem cheesy, even pretentious, but they work well enough for the purpose of differentiation between them. They will be described later in another section.

MOVING ABOUT:

Like Bastion, Transistor’s gameplay occurs across a 2D plane. These are bounded, which is just as well because according to the story, Red is being corralled and hunted by those whom she seeks vengeance against. Indeed, many level boundaries appear to be formed by surreally polygonal walls; these walls would later be revealed to be the effects of the “Process”, which will be described later.

That said, Red and the sword’s main inhabitant already know where they should go as they seek out their enemies in the city of Cloudbank. If the player is wondering about where to go, the sword will eventually give reminders. (Of course, the player can still have Red wander about – likely to elicit more remarks from the sword.)

Red can be moved about using the WSAD keys on the keyboard in the computer version of the game. This is satisfactorily functional. As for the mouse, it is mainly used for setting the target for Functions. However, left-clicks with the mouse do have Red move over to where the player clicked on; her pathfinding is not always efficient though.

There are some Functions that can propel Red about. The Turn() mode (more on this later) will show where she would be after performing these functions, but the real-time gameplay will not.

EXITS TO OTHER LOCATIONS:

Red does not return to places that she has been; this is deliberately intentional, because according to the narrative, she is being hunted. Therefore, the player will want to look around a location before seeking out the exit from that location.

Speaking of which, exits to other locations will be marked on-screen with text labels and connector-lines. This can seem a bit off-putting, especially if the player wants to look at the scenery. Yet, these indicators happen to be the only way for the game to address the problem of some exits being visually obscured.

To elaborate, since the game is using an isometric camera that has its orientation fixed, the player cannot see the facing of any walls or boundaries whose surfaces are directed away from the camera. If there are exits on these walls, they have to be marked with those indicators.

Exiting the current locale and entering the next one updates the auto-save.

TERMINALS:

There are terminals that are located throughout the city of Cloudbank. These are still operational, despite the progression of the “Process” through the city. Red can interact with them to get some news on what has recently happened and what is happening.

Generally, these are just there for narrative flavour and minor lore exposition. However, a few terminals do cause enemies to appear where Red is or would be going.

ACCESS POINTS:

Access points are spots that are revealed by the Transistor. The Process and the faction that is after it and its wielder do not seem to be able to do much about these, other than to sometimes have combat groups appear next to these. However, these points are disabled if Red is engaged in combat.

Anyway, interacting with these updates the auto-save for the player’s playthrough. Then they bring up the user interface that lets the player configure the functions.

The configurations of the functions and what they do will be described shortly.

FUNCTIONS – OVERVIEW:

Red fights through the use of the sword’s Functions. The sword’s main inhabitant does not know what Function would be unlocked next, but Red somehow knows what to do with whatever that comes up (much to her companion’s astonishment at times).

The Functions go into slots in what is presumably Red’s deck of capabilities. (Why these slots are there are unclear in the narrative.) Not all slots are enabled from the get-go. In order to unlock them for use, Red has to gain some levels. There is, of course, a progression system in this game. This will be described later.

INSTALLING AND UNINSTALLING FUNCTIONS:

For better or worse, the player does not get to see a magnified view of the installed functions until the player selects a function to install. The player will have to make do with the small bar of hotkey icons at the bottom centre of the screen when deciding which Function to select for installation.

Similarly, if the player wants to uninstall a Function just after activating an Access Point, the player has to depend on that bar too. This can be a problem if the player intends to uninstall Functions that have been installed in upgrade or passive slots, because the icons for these are small.

Selecting a Function brings up the full-sized view of the slots. Even so, the player can only use this view to install the selected Function. Furthermore, the player does not get to manually select already-filled upgrade slots; only empty upgrade slots can be selected.

Considering that the rest of the game seems well-designed, these limitations can appear unseemly.

ACTIVE SLOTS:

Anyway, functions have to be installed in the active slots in order for Red to have something to use in battle. There are four active slots – all available from the get-go – and it is in the player’s interest to have as many of these filled as possible.

UPGRADE SLOTS:

Each active slot has two upgrade slots in turn. One of these slots is available from the start.

Interestingly, the player fills these slots with Functions too. Different Functions impart different properties unto the Function in the active slot. These upgrades are generally net positive, i.e. the Function in the active slot becomes more potent without any severe setback that limits its use.

However, there are some combinations that are powerful enough to be held back by some setbacks. For example, there is an upgrade for Jaunt() that reduces its cooldown. (Jaunt() is practically a teleport-dash, to cite a typical video game term for inexplicably sudden movement over a short-range. Thus, this allows the player character to zip around incessantly. This was balanced by a shorter teleporting range for Jaunt().

PASSIVE SLOTS:

The first passive slot becomes unlocked after Red has gained several levels. As their name suggests, these impart benefits that are always available.

VARIETY OF FUNCTIONS:

Having used every function, I would say that each one does have an impact on gameplay. None of them appears to have design issues that make them impractical, thus suggesting that the developers have play-tested them quite well. This is a feat, considering that there are a significant number of functions – far more than there are active slots, and far more than the player could ever use at any time (more on this later).

However, there are some functions that are notable for being more reliable than the others. These include the two starting functions: Crash() and Breach(). When used as active slots, Crash() is an efficient hard-hitter which also de-buffs enemies, whereas Breach attacks everything in a straight line.

Another example is Jaunt(), which is also an early-game function. Jaunt(), when used in an upgrade slot, renders the active function usable even during the cooldown time of Turn() (more on this later). Yet another example is Stealth(), which becomes near-indispensable later because escaping the wrath of enemies that are converging on Red is important for survival.

SYNERGY OF FUNCTIONS:

Perhaps the best appeal of the game is how some functions can be used together to result in some attacks that outright disable enemies. For example, there is a mid-game function that can stun enemies when used as an upgrade slot; combining this with an area-effect attack like Split() can be very effective at locking down multiple enemies.

Indeed, synergies of functions are how the player would deal with troublesome permutations of enemies later in the playthrough. It is also how the player can cope with the “limiters”, which will be described later.

LORE TIED TO FUNCTIONS USED IN SLOTS:

For better or worse, the writing for most of the sapient characters in the game are placed behind challenges that are associated with the use of the Functions.

Each Function is somehow assigned an association with one of the characters behind the backstory of Cloudbank and its current crisis. Each Function has three tiers of information that are tied to it. Each tier has its own unlocking conditions, which are spelled out to the player. That said, these conditions involve the utilization of the Function in all three types of slots.

Apparently, this is the developer’s way of encouraging the player to diversify the configurations of Functions. There is actually no reason to, if the player is the kind that prefers to stick to what he/she is comfortable with.

“MEM.”:

The player is held back from using all available slots. This limitation is the result of the implementation of “Mem.”, which limits the number of functions that can be put into slots. For ease of reference, this factor will be henceforth referred to as “Memory”.

The player character has a meter that represents her capacity of Memory. As more Functions are installed, more of this meter fills up. That said, different Functions can have different Memory requirements. Typically, the most powerful Functions have high costs.

Generally, it is in the player’s interest to completely fill out the meter, for reasons that will be described shortly.

LOSS OF FUNCTIONS:

When Red is taken down, one of her installed Active Functions and its upgrades “overload” in order to return her to the fray. Thus, Red is more durable if she has more Active slots filled, but every revival comes with the price of having reduced combat capability.

Usually, the game picks the Active Function and upgrades with the highest total Memory cost to be overloaded first; the game can be that devious.

After all of Red’s Active Functions have been removed, she goes down for good; the player loses and has to revert to the recent auto-save.

OVERLOADED FUNCTIONS RENDERED TEMPORARILY UNUSABLE:

If Red survives a combat encounter but has Functions overloaded, these Functions become unusable. The only way to restore them is to progress in the playthrough, specifically by reaching the next access point. It has to be an access point that the player has not used yet in the playthrough; the ones that the player has visited earlier does not count.

Since the player has only one auto-save per playthrough, this limitation-by-design poses the risk of the player getting into the next fight with a gimped range of Functions. Of course, there are far more Functions than there is Memory, so the player should have plenty of “extra lives”. Still, a very incompetent player may find himself/herself running out of exactly that.

TURN() - FOREWORD:

The sword’s most powerful boon is time compression for its wielder; this is named “Turn()”. When it is used, the player is given a meter that indicates the amount of actions that she can enact in a fraction of a second.

These actions can include moving about. Indeed, the player will want to be frugal with the distance that Red covers, because the distance moved does fill up the meter of actions.

Different Functions take up different amounts of the meter. That said, typically, the more powerful Functions take up more space on the meter.

The predicted effects of every action is shown to the player. The details include the damage inflicted, compounding of damage from combos and/or backstabs (more on these later) and any blocking of damage (more on these later too). The player should not expect guarantees from these though; this will be elaborated shortly.

CLUTTER OF LABELS, OR PAUCITY OF THEM:

The aforementioned predicted effects are displayed through labels that appear over or next to the sprites for enemies. The game does its best to fit them on-screen without them overlapping each other, but ultimately there are situations where this is just not possible.

In the case of area-effect attacks that hit tightly-bunched enemies, the player would get a clutter of labels that are messy.

Worse, there are circumstances where the player do not seem to get labels for affected enemies. This is especially so for the Breach function, which can hit multiple targets. The intended target will have its predicted details shown, but other affected enemies might not have labels.

PLANNING INTERRUPTION:

Late into the playthrough, there are enemies that can interrupt the player’s planning. For example, version 3.0 Cluckers launch bombs that saturate areas with currents that can harm Red if she moves over them. Incidentally, these currents also immediately trigger the enactment of a Turn() if the player has Red moving over them during the planning phase.

TURN() ENACTMENT:

When a turn is enacted, Red will perform actions exactly according to the player’s plans. There is next to nothing that can stop its enactment.

However, the effectiveness of the enactment greatly depends on the response of enemies that are affected. Although most enemies are frozen during the enactment, time is still moving, and it is possible that they can get displaced. This is especially the case for the Young Lady entity, which immediately teleports when it is damaged.

This would not have been an issue if their responses are entirely predictable. For example, if the player expects enemies to be knocked back, the player can have Red inch forward a bit after every planned attack in order to keep up the pressure from a barrage of successive attacks.

However, not all of their responses are predictable. This is especially so for the Cells that pop out of defeated enemies; the directions of their hops are randomized. (There will be more on Cells later.)

TURN() RECOVERY:

After a Turn() has been enacted, all Functions are disabled until the Turn() meter refills completely. This is when the player will want Red to move around evading enemies, because she is vulnerable during this phase.

Consequently, this also means that Red stays vulnerable for longer if the player has used up more of the meter. Therefore, the player will want to be cost-efficient with Turn().

As long as there is any capacity left on the meter, the player can fill it up with any Function. This does cause the meter to take longer to refill, however.

FEW WAYS TO HEAL:

Red’s health is generally on a one-way trip to zero. There are very means to heal, and whatever there are happen to be rather stingy. Therefore, avoiding damage is the player’s main way of keeping Red alive. Fortunately, this is not too difficult to do, at least for players who are observant and have noticed the potential of some Functions for getting Red out of hot water. (Stealth() is an example.)

THE PROCESS - OVERVIEW:

The “Process” is the name given to the pervasive enemies that Red would face. Their origins and nature would only be revealed much later, after certain characters reveal this to Red. Suffice to say for now that they are a force that is not sapient.

The Process entities that are driven to attack Red will set up force fields that prevent her from escaping. The only way to escape is to defeat every Process entity that would be spawned to fight her. These fights can be easy or tough, depending on the player’s skill and how dumb the Process can get.

The Process entities can be categorized according to their looks and animations. In other words, entities that look similar to each other behave in the same way. That said, each category of Process entities has their own idiosyncratic behaviour. More advanced versions within the same category may be stronger and have certain benefits, but their response to Red’s presence remain the same.

This is not unlike the enemy designs in Bastion. As with Bastion, the player eventually learns to associate these behaviours with their looks and animations, and respond accordingly. For example, Young Ladies always teleport to random locations within the arena upon being hit, so there is no reason to target them more than once during Turn() planning.

When the player uses Turn() for the first time during a battle that introduces a new entity, the player will see a text statement that describes one of the characteristics of that entity. This statement appears to be fixed for that encounter, however.

CELLS:

Other than dealing with their idiosyncrasy, the player has to deal with the remains that Process entities leave behind when they are slain.

Most Process entities drop cells that are proto-forms of themselves. If the player leaves these alone for too long, they will regrow into those entities again, at full health. Of course, this is not ideal.

If Red is close enough to the Cells, the Transistor absorbs them; the entities are henceforth eliminated. Getting close to them is easier said than done though. The Cells bounce in random directions when they are spawned.

There is a certain function that when used as an upgrade, might just destroy the entities outright. However, it uses an RNG roll to determine whether this happens or not, which does not make it reliable.

YOUNG LADIES & BAD CELLS:

Young Ladies are fast enemies with considerable firepower. They can create shadow copies of themselves that also have their own derivative of firepower. They also immediately teleport as soon as they are damaged. Indeed, they are among the most troublesome enemies in the game.

Young Ladies are the only Process entities that do not drop Cells that respawn into them. This is just as well, because they spawn a lot of cells that turn into Bad Cells.

Bad Cells are some of the fastest enemies in the game. They are weak, but there tend to be a lot of them. Bad Cells, fortunately, do not revert into Cells when they are defeated; they just perish.

ENEMY VERSIONS:

The Process improves its entities as the playthrough progresses; the Process may not be sapient, but it does realize the need to up-gun its expressions.

That said, when an entity of an upgraded version is introduced, using Turn() for the first time in that combat encounter has the game pointing out that this entity is of a later version. There is also a text statement that describes what benefit that this upgraded version has over its predecessor.

Generally, having upgraded versions is something that is only for Process entities that appear early in the first playthrough. The later Process entities, such as the dangerous “Man” entities, do not have upgraded versions.

PROCESS BLOCKS:

The Process is taking over the city of Cloudbank. One of the signs of this happening is off-white blocks appearing all over the place. These blocks prevent movement through them, and particularly tall blocks will block the entities’ line of sight too.

These Process blocks hamper the entities more than they do Red, mainly because these blocks prevent them from bringing their numbers to bear.

The blocks, as their name implies already, block attacks. Unless an attack is designated as “Penetrating”, the blocks will absorb any projectile or beams coming their way. They can eventually be destroyed, but they will return after some time.

That said, the function Breach() instantly lowers any blocks that its beams pass through. The player will need to use Breach() in some scenarios that have a lot of blocks in order to get to somewhere.

Certain functions launch enemies upwards and over the blocks. This happens to be a way to get explosive packets over walls, though there is the risk of the packets removing any blocks that are preventing the entities from mobbing Red.

ENTITIES HAVE LIMITED LINE OF SIGHT:

The Process entities greatly depend on their sight to spot Red, despite their otherworldly abilities.

They cannot detect the presence of Red if she is at a length of one screen away, i.e. the player cannot see the entities on-screen. If the player can have Red keep this distance between her and them, they lose interest in Red and linger about where they were.

There are some Processes that do give pursuit, such as the Creeps and the Fetches. They will go to Red’s last-known location, if their line of sight is broken. However, they still have the same range limit on their sight.

Incidentally, the sizes of the entities do determine their ability to spot Red. For example, the floating Young Ladies and the massive Jerks can always see Red over the process blocks. Most small entities cannot spot Red beyond the blocks. (Fetches can do so, however.)

That said, it is possible for the player to have Red hide in some nook of the arena and wait for a better moment to make a strike again. This is especially helpful in the survival-oriented Stability Tests in the Sandbox area (more on these later).

BACKSTABS, COMBOS & BLOCKS:

Attacking an entity from behind with most Functions inflicts more damage; this is called “Backstab” in-game. However, this is generally only doable if the player is using Turn(), because almost all enemies automatically turn to look at Red. Anyway, the additional damage is substantial enough that the player might want to spend some of the Turn() meter to move behind enemies.

“Combos” are generally only available if Crash() has been used on enemies. Combos are the bonus damage that is inflicted by any damage-inflicting Function that is used on those enemies later. More often than not, the player will want to maximize damage output from a Turn(); Crash() and combos are a good way to do so.

Blocks happen if an enemy is behind cover, i.e. Red’s attacks hit anything else in between her and her target. Blocks are usually a cue that the player might want to reposition Red.

PROTECTION:

“Cheerleader” entities can project force fields on their allies. These force fields render them practically invulnerable to damage and de-buffs. The Cheerleaders themselves may even have force fields, particularly the later versions.

Observant players might notice that the force fields rely on projected beams. If these beams are broken by cover, the beam breaks and both enemies are rendered vulnerable.

BOSSES:

There are some combat encounters where Red fights some particularly powerful enemies. These enemies are always aware of where Red is, unless she is using the Stealth function. (The final boss does know where she is even if she is using Stealth though.) As to be expected of boss fights, the player is shown the life bars of the bosses; the only exception is the final one, which is a fight that is quite different from the previous ones.

Usually, there is some pattern that the player can observe and exploit; experienced and cunning players might even defeat the bosses without taking much damage in return. Again, the only exception is the final boss fight, which is practically a damage trade.

GETTING LEVEL PERCENTAGES FROM FIGHTS:

For better or worse, there is only one thing to be gained from fighting the Process: “level %”. There are no experience points to juggle and no currency-like resource to deal with. Level % is doled out after each fight; regardless of how tough or easy it was, the base amount is always fixed. Therefore, there is no reason to be anything other than cost-efficient during combat, e.g. exploiting their inabilities (as described earlier) and hiding to replenish the Turn() meter.

“LIMITERS”:

Bastion has a system that lets the protagonist pray to rather wrathful gods for greater challenge; essentially, the player enables optional gameplay modifiers that makes combat tougher. In return, the player gets more rewards.

The limiters are unlocked as the player character gains levels; there are more than a few narrative clues that imply that these are intrinsic to the Transistor. That said, these make things worse for the player. Some limiters make the Process stronger, nastier or otherwise more troublesome; the limiters certainly do not limit the Process. Some other limiters impose penalties on the player character, such as reducing Red’s Memory capacity.

Using any limiter for at least one fight reveals the lore behind a Process entity. There is no clearly relevant association between the limiter and the entity, however, so this is just another design that places lore behind gameplay challenges just for the sake of doing so.

SANDBOX:

Sometime into the first playthrough, the player character obtains the Backdoor() function, which enables the appearance of doors that lead to the “Sandbox”. This is perhaps the strongest clue that Cloudbank is a virtual world, but no character would acknowledge that.

Anyway, the Sandbox has a bunch of recreational options that are mainly there for the purpose of eliciting more responses from the main inhabitant of the Transistor.

The Sandbox also has a tree that has doors growing out of it; the Sandbox is that weird. These doors lead to other sandy isles where there are combat-oriented tests.

Most of these tests give the player pre-sets of Functions; the player is then expected to make do with these to achieve whatever objectives that the tests set. Many of these require the player to be familiar with the Functions and to be cost-efficient with them. Being familiar with them can be a problem though, because in the first playthrough, the new player might not have obtained the Functions that are given to the player in the pre-sets.

The exception is the series of Performance Tests. These tests also happen to be the longest.

Performance tests let the player select Functions from among a range that the player has unlocked already, though not all are available. There are also limits on Memory capacity. After making the selections, the player has to get through an encounter with a fixed composition of Process entities.

A certain series of tests only becomes available after the player has finished the first playthrough and started another.

The main rewards for these tests are musical tracks that can be played on the music player in the Sandbox. Some of these are not heard elsewhere in the playthrough. The other rewards are Level % increases, which is perhaps more desirable to a player that prefers more practical rewards.

“RECURSION”:

After finishing the first playthrough, the player can start another playthrough in “Recursion” mode, which is practically “new game plus”.

“Recursion” omits all of the tutorials (in a rather entertaining way that the player can see). All enemies in the first playthrough are replaced with tougher ones, and they are more numerous. The player character’s “Level %” gains are also much more significant, which is perhaps for the better because the player character needs to be much stronger to survive.

Certain remarks by voiced characters are also slightly different. The most notable of these is the remark by a certain other inhabitant within the Transistor, instead of the main one. However, the player should not expect more exposition from the game.

VISUAL DESIGNS:

The player’s first glance at the setting of this game is that it is set in a city with a smorgasbord of architectural themes; art deco comes to mind the most. However, its surreal qualities become increasingly noticeable, e.g. raindrops don’t fall into water convincingly and pigeons appear to dissipate into pixels when they fly away. There is also the looming Process, which certainly does not look natural.

There are further visual oddities; corpses of what appear to be humans do not bleed, and instead appear to be disintegrating (for a reason that is not immediately clear to the new player, of course). The Process’s minions appear and move about in smooth but uncanny ways. Eventually, there would be so many signs that even the least observant player would have the impression that the city of Cloudbank is very artificial (and indeed it would turn out to be so – but whether it is in virtual reality or something else entirely is unclear).

MOSTLY STATIC ENVIRONS:

All these impressions were made possible through artwork that is different from that in Bastion. There are some similarities of course, especially in how the player character is animated. The similarities end there, however.

Of course, Transistor’s environs are nowhere near as amusing to look at as those of Bastion, which visibly cobble together as the player progresses through the story. The mostly static environs in the city of Cloudbank might even seem like let-down to those who really like Bastion’s presentation.

When the Process has extensively invaded Cloudbank, there are more animations, lighting tricks and particle effects, but they are nowhere near as vibrant as the environs in Bastion. In fact, they look depressing and oppressive, which is perhaps the intended effect. The player can only see these late into the first playthrough and in the “Recursion” playthroughs however.

ANIMATIONS:

There are very few living and animated human characters that the player would see in the game – again, this is not unlike Bastion. However, the humans in this game are much more believably proportioned than those in Supergiant’s previous game, so the developer has to deliver animations that are more believable.

That said, Red appears to wield the sword rather effortlessly. Her seemingly innate skill with it is never explained. In fact, the animators were so carried away with animating her that there are some control inputs for animations that do not involve gameplay at all.

Unfortunately, the camera is perhaps too far away to give the player a good view of her animations, especially those for her facial expressions. In actuality, there are very few. Conveniently, Red cannot speak. As for the only other living human character that is seen in the game, he has considerable overshadows on his features, thus masking the lack of any tertiary animations.

Most of the Process entities are limbless floating objects, which would have been simpler for Supergiant’s artists to animate than the other entities. The Process entities that do have limbs are impressively-animated though.

For example, the Fetch does look convincingly canine. For another example, the Cluckers have goofy running animations, what with them being the Process’s early attempts to imitate humans.

PARTICLE EFFECTS AND LIGHTING:

Like Bastion, Transistor makes use of a lot of particle effects and lighting, especially for scene transitions. The particle effects are most notable in the attacks of the Functions and the Process entities, more so for the latter.

Being set in a city that is being taken over by otherworldly things, most of the scenes that the player sees look understandably grim. Sources of light that were there before, such as the neon signs and headlights of popular establishments, give way to the pulsing and subdued light sources that the Process uses for whatever reason.

SOUND DESIGNS:

The game begins itself with voice-overs from Supergiant’s best assets: its musical and voice-over talents.

Logan Cunningham, who voiced Rucks (also the narrator) of Bastion, voices the Transistor’s main inhabitant, as well as one other major character. This game reveals snippets of Cunningham’s versatility – something that would only be clear in Supergiant’s next game, Pyre.

In this game, he voices characters that happen to be emotionally detached or deflated. This results in him making remarks with intonations that sometimes come across as lethargic or disinterested. This can seem like a problem to players who recall his role as Rucks, but who have yet to learn anything about the characters whom he voices in this game. The player will have to get used to this too, because he voices the only characters to have any significant voice-overs.

As for Red, she is rendered mute due to the perfidy of certain quarters. Therefore, conveniently, her voice-actress does not have a lot of legible lines to deliver. This is perhaps just as well, because her voice-actress has been contracted to sing and/or hum the songs for the game.

The music is composed by Darren Korb, who also composed for Bastion. Many of the tracks would have been entertaining to listen to during the time of the launch of this game, when indie games with great music were still not uncommon.

Then, there are the sounds of combat. All of the Process entities make noises, among which are those that they make when they spot Red. Of course, keeping an ear open for audio cues is not that important in the gameplay, due to the entities’ limited line of sight and the fact that almost all of the gameplay occurs within the current screen, and rarely beyond them.

That said, most of the sound effects are there to give the game a decidedly sci-fi impression. After all, most of the noises do not sound like something that a sword made of electronics would sound like.

SUMMARY:

Transistor may have certain superficial similarities to Bastion, like using well-animated sprites in 2D game-worlds with a seemingly isometric camera perspective. However, these similarities are due to the tech that they are using – something that Supergiant cannot switch around so easily.

That said, Transistor makes it clear that Supergiant Games will switch around whatever they can, such as having gameplay and story-telling that is different in its next game instead of making straight sequels. The results may not be wonderful or pleasing to everyone, but they are certainly not boring.