Search The Inquisitive Gamer

Saturday, 30 January 2016

Mechanical Criticism: Transistor and Ether One

With more time on my hands again I've actually been able to play some more games (whilst continuing to dip in and out of my ongoing Fallout 4 save, of course). Two games in particular have surprised me because I loved the one that I expected to hate (Transistor) and have decidedly mixed feelings towards the one I expected to love (Ether One). In this article, I will offer a short critique of why I think these games had these very different effects on me by analysing some of the games' mechanics and how they fit within the ludodiegesis of each game.


Transistor: Combat Flexibility and Control

I expected to hate, or at least to strongly dislike, Transistor. This was because as much I really, really tried to like Bastion (Supergiant Games' debut title), I just never felt in complete control during the game's combat. The world was lovely, the narrator excellent, the story compelling - but feeling constantly useless during combat, even after a good few hours playing, was a killer for me. To begin with, Transistor looked like it was going to do the same thing, as I struggled to get my head around the hybrid real-time/turn-based battle system.

Real-time combat in Transistor.

I persevered, driven mainly in the game's early stages by the crisp art direction and sumptuous audio treatment. I started to get the hang of the game's basic 'functions' (each ability you acquire in the game is a 'function', in-keeping with the general theme of computer code terminology throughout the game). The player can have up to 4 usable functions active at one time, and each of these can be upgraded with up to 2 additional functions which give them various buffs.

For example, the Get() function can be placed in an active slot and used to pull distant targets in towards the player, setting them up for further melee attacks. The Get() function can also be attached to another function's upgrade slot, adding the Get() effect to that function in addition to its normal effect.

In addition to active and upgrade functions, the player can unlock up to 4 passive function slots as well. Putting the Get() function in a passive slot allows the player to attract 'cells' (items dropped by destroyed enemies) from further away, giving the enemies less time to respawn from cells left on the battlefield.

When you add in the numerous other functions to the equation, the degree of potential combat strategies increases drastically. On realising this, I initially felt rather overwhelmed - too much choice can be a bad thing after all, as has been demonstrated in social psychological research such as Iyengar & Lepper (2000). This is where Transistor is clever though. The game provides access to a number of 'backdoors' as the player progresses through the game world. These are essentially portals to a training ground that also contains sets of themed challenges to test more advanced players. It was these challenges that actually helped me to learn the battle system, rather than the provided free training area.

The challenges that are particularly beneficial to learning the combat system are the ones that simply task the player with eliminating waves of enemies with the functions at their disposal. The player starts with three randomly selected functions and then is given a new function after each wave. This forces the player to think about how best to combine these randomly assigned functions and thus, allows players to experiment with the battle system in ways that they may not have in the main game. In addition to this, when the player takes enough damage to deplete their health bar, one random function is overloaded and becomes unusable. In the main game, this can be restored at a save point. In the challenges however, that function is permanently lost, thus requiring the player to formulate a new arrangement of functions at the start of the next wave. All of this combined means that these challenges expose players to the full breadth and depth of the combat system in a way that the main game, oddly, doesn't.

Indeed, in the main game mode up to the point that I started undertaking the challenges, I had been spamming through most encounters with a functional, but probably less than optimal, character set up. After seeing how effective some function combinations were in the challenges, I had a lot more confidence to experiment in the main game too. It does seem strange from a design perspective though, that the game doesn't guide players through this learning process a little more in the main game. It is clear that the developers have a good deal of respect for the intelligence of their players which is a rare thing to see and for which they should be commended. However, it seems that they made an excellent teaching tool for their game but then put it in the least likely place - the challenges designed for experienced players.

The combat in Transistor manages to provide total flexibility for players and, once the player understands how function combinations can be used effectively, the player is indeed in complete control of their fate. Failure in Transistor never felt unfair. Annoying, certainly. But that annoyance was nearly always aimed at myself for making a poor choice during combat or not being patient enough with my strategy. Very rarely did I feel the game forced me into making an error.

The real-time combat is still not perfect. It is much more manageable than the combat in Bastion due to the seemingly larger arenas that are featured in Transistor. However, the addition of the Turn() function is what sets the game apart from both its predecessor and from many other action-RPGs.

The Turn() function pauses the battlefield allowing for a sequence of actions to be planned and then triggered.

Activating Turn() pauses the battle and provides the player with what is essentially a number of Action Points that can be spent on either moving the player-character or performing actions. Once all the Action Points are spent, the plan can be activated and the actions will be carried out in quick succession once the battle resumes. This allows a degree of attack accuracy and attack chaining that could never be pulled off in real-time combat alone. It also allows for some clever evasive maneuvering as well if used as a defensive strategy. This addition to the game's combat system adds a bold layer of strategy that was sorely missing from Bastion and prevents the game falling into the trap of many other action-RPGs, in which the game simply becomes a 'spam the most powerful attack' process of rote repetition.

Transistor: Weaving Together Gameplay and Story

In narrative theory, the diegesis refers to the 'fictive reality' of the story. Something that is diegetic exists within the fictional world and can be 'perceived' by characters in that world. The narrator in Transistor is therefore, a diegetic narrator as he exists as a character within the world itself.

The ludodiegesis is simply the game-based, or ludic formation of this concept. The problem with a game when compared to a traditional story is that games have this mighty irritating thing in them called gameplay, which allows the player to interact with that diegetic world. When gameplay and story fail to be consistent, this results in ludonarrative dissonance. A common example of this focuses on games such as the Tomb Raider reboot, in which Lara agonizes over the killing of a single deer early in the game, yet mere hours later is happily gunning down wildlife and people left, right, and centre. What the player is doing does not match what the game is telling them they should be feeling. 

In games with a strong story component, a common mechanism for delivering that story is written notes scattered around the game world, or audio diaries as seen in games like Bioshock. These are perfectly functional but do tend to raise questions about how much time the inhabitants of these worlds spent recording their every thought onto paper or audiotape. Transistor manages to avoid this trope whilst simultaneously creating an additional motivator for players to experiment with the game's combat functions as outlined previously.

Each function can be inspected to view character backstory segments.

Each function in the game (i.e. gameplay elements) are directly tied to a character (i.e. a diegetic element). Each function represents a part of a character's personality and has their history woven into it. The way that players discover this character history is by using the function in different ways to fully unlock its data. Each function has three pieces of story attached to it and they are unlocked by using the function in each of the active, upgrade, and passive slots during at least one battle. This simple linking of gameplay with story is very effective. Players are kept within the diegetic reality of the game at all times and are less likely to find themselves asking questions stemming from feelings of dissonance. Moreover, in order to uncover the full backstory of all characters, players are encouraged to experiment with the functions in all of their possible arrangements, thus intrinsically connecting gameplay advancement with story advancement.

There are very few other games I can think of recently that achieve such a seamless blend of gameplay and story and thus, Transistor is a game well worth highlighting. I enjoyed it so much I had no problem playing through it a second time and collecting the Platinum Trophy as well.

Now, following the same line of discussion around the linking of gameplay and story, and ludonarrative dissonance, I would like to briefly discuss some of my initial thoughts on Ether One... 

Ether One: Tooltips Make Bad Mechanics

Firstly, full disclosure, I have not finished Ether One yet. I will. I think. If it doesn't continue to annoy me. Let me explain.

I like 'experiential' games (my own term to describe what others may derisively refer to as walking simulators). I find them extremely relaxing and an excellent break from my 'main' game collection (see the aforementioned Fallout 4 saga). I also like clever puzzles in games, although I am not above turning to a walkthrough occasionally to get past puzzles that stump me for longer than an hour or so (I have very limited gaming time, after all). Thus, I expected to like Ether One. And for the first hour or so, I did.

The first 'level' is relatively linear, tasking the player with solving some reasonably simple puzzles in order to move from A to B to C. It serves as a nice introduction to the game's story, its (rather clunky but not too hideous) inventory system, and the game's puzzle logic.

The second 'level' is quite a step up in complexity, placing the player in a much larger, less linear village environment with multiple puzzles all vying for attention simultaneously. This was challenging but nothing I thought I couldn't handle with care and attention. I spent 2 hours or so slowly exploring, gathering the items I found and making sure to turn the place upside down for written notes and clues. Yet still, after this time I hadn't solved any of the three main puzzles in the area (as indicated by the three broken film projectors that each puzzle would restore to functionality upon being completed).

What was worse, was that for two of these puzzles, I knew what I needed to do. I just couldn't work out what the trigger was to advance the puzzle to the next stage.

The order form puzzle.

In the first problematic puzzle, a letter sits on a desk. It is an order form for a Morris Dancing Supplies Company. The game has already provided clues stating that someone in this house needs to order replacement gear for the upcoming Morris Dancing event and that specifically, this person needs 1 replacement set of bells. The order form contains two text fields, one for 'item name' and one for 'quantity'. I entered 'Bells' and '1', and nothing happened. No feedback at all. Considering that text entry puzzles are rather unusual in the land of console games (I appreciate this was originally a PC game), I wasn't sure if I had just done something wrong. Player actions should be given feedback in some way otherwise there is no way to know if you have done something that the game has even recognised.

Further exploration found a further clue stating that the person needed 'bells' but that they couldn't remember what the 'proper name' for the bells was. Clearly, the item name on the order form needed to be this other term. However, nowhere in my two hours of exploration had a seen reference to the 'proper name' for these bells. Not being a Morris Dancing enthusiast, I also didn't happen to have that knowledge tucked away somewhere. Stumped, and following my 'stuck for over an hour' rule, I turned to the web for assistance.

The 'solution' to this puzzle requires the player to hover their cursor over the set of bells that is already in the house (which I had already found) and press the 'inspect' button, which makes a tooltip appear showing the name of the item. Doing this to the bells identified them as 'baldrics'. Entering this term onto the order form was the answer the game was waiting for and let me continue.

This is bad game design. In a game in which other clues had been diegetically positioned throughout the game world in meaningful ways, this puzzle seemed lazy and unintuitive. This puzzle could not have been solved by the player-character from within the game world, because the solution required the use of a non-diegetic game mechanic. The player-character could have never known to enter the term 'baldrics' onto the order form using information available within the game world alone. This broke my immersion and also, severely damaged my faith in the design of the game's future puzzles. 

As an aside, if I had been a Morris Dancing aficionado, I still wouldn't have been able to complete this puzzle through my own knowledge alone, because 'baldrics' are not actually the bells on a Morris Dancing uniform but are in fact the crossed ribbons worn over the chest. This isn't just bad game design, this is bad research.

The picture frame that hides the safe in the Crow's Nest pub.

In the second puzzle, the player finds clues pointing towards a safe being hidden somewhere within the village pub. With no obvious safe in sight, I considered the surroundings more carefully before locating a rather out of place picture hanging on the wall (as can be seen above). Clicking on it resulted in the same sound effect being played as when the player tries to place an item somewhere it cannot be placed. So, I assumed that I was interacting with the painting with the wrong item in hand.

As was the problem with the previous puzzle, the feedback has failed to give me appropriate information about my actions. Because I had previously associated that sound effect with being unable to use an item in a particular place, my natural response to hearing it was to go and try to find the correct item to use. This is compounded further when we consider the correct solution to this puzzle, which involves specifically interacting with the lower portion of the picture (underneath the 'PINWHEEL BREW' text), which takes the player to that very clever but rather uncommon text-entry mechanic.

So here the game presents a known, real-world object (the painting) and places a less well-known mechanic (text-entry) onto it, coupled with confusing audio feedback if the player clicks anywhere else on the painting. This would perhaps still not be a disaster if the text-entry mechanic made sense as a logical solution to this puzzle. Previous uses of the text-entry mechanic were in contexts where you would expect to write something in real-life - a name register in the game's opening, and the above mentioned order form puzzle. Here, scrawling some text onto a painting somehow magically opens a mechanical lock and swings the painting open. It makes no sense and is even more jarring when put alongside the game's other, really rather thoughtful and logical puzzles.

Incidentally, the text that the player is required to enter here is J.D TAYLOR - the name of one of the beverages served in the pub and brewed locally to the village. However, working this out seems to be based on luck and guess work, rather than deductive reasoning from clues in the game world. Indeed, one player on the Steam forums admits he just entered the names of every beer in the pub until one worked. Even then, I'm not sure how he managed to narrow it down to beer names in the first place.

Puzzle games that make solving their various riddles seemingly impossible without guess work or use of non-diegetic methods are, at best, poorly designed and at worst, simply lazy. If players have to resort to guessing, they are not having fun.

I must emphasise that I am still actually rather enjoying Ether One but these puzzles rather soured my experience with it so far. I reserve judgement until I have played more of the game. However, following on from my finishing Transistor and how it so effortlessly linked gameplay and story together, the explicit disconnect between player and diegetic player-character in Ether One stuck out rather noticeably.


Iyengar, S. S. & Lepper, M. R. (2000). When Choice is Demotivating: Can One Desire Too Much of a Good Thing? Journal of Personality and Social Psychology, 79 (6), pp.995-1006.

Monday, 18 January 2016

The Doctor Will See You Now

So, the primary reason why this blog has been a little 'tumble-weedy' for the last year or so has finally been finished. I submitted my PhD thesis in September and had my viva examination in November and have now printed, bound, and delivered the final copy to the University. After 5 years, I can finally fill my spare time with spurious 'stuff' again without the constant nagging guilt of not spending every waking moment writing. Or reading. Or thinking about writing or reading.

The final title is Disruptive Game Design: A Commercial Design and Development Methodology for Supporting Player Cognitive Engagement in Digital Games. Yes, a little long (as the printer reminded me as I paid for him to use two type blocks on the cover rather than one), but it gets the point across!

Here's the hard evidence! Click here for the PDF version.
This has been one of the toughest things I think I have ever done but I enjoyed every minute of it. I couldn't have got to this stage without the outstanding support of everyone else involved though: my supervisors, my family, and especially my wife and son. Thanks to everyone!

Some Simple Advice for Other PhD Students

I thought it might be handy to have a little reflection here about the process and specifically, about the viva. I turned to the internet to calm my nerves before the viva exam and reading other PhD students' experiences really helped, so let me try and give a little something back for future students too...

Firstly, if you are finding this early in your PhD career, some long-term advice: write. Write early, write often. I cannot stress enough how useful this process is for 'cleaning' your thoughts and words up before you try and turn them into anything even slightly resembling academic prose. I have over 60,000 words of 'removed stuff' in a separate document to the thesis plus a whole load of other documents scattered around my PhD folder structure. Every single one of these helped me, even if it didn't go in to the thesis or indeed, even if it didn't actually even relate to the thesis in the end. Writing helps you to organise and make sense of your own thoughts.

Secondly, again for early career PhDs, get the balance right. This is tough. I don't think I ever quite mastered this. My wife can probably recount every single time my writing guilt got the better of me and led to anything from a minor tiff to a full on, two-day argument. This is not a good place to be. It isn't good for you, the people around you, nor your work. Now, every person is different of course but, my suggestion is to work out what you will sacrifice in order to fulfill all of your responsibilities properly. A PhD requires sacrificing something in order to have the time to dedicate to the process. That something should not be family, although that is always easier said than done. If you work better in the morning, get up at 5 or 6 and work. If you're a night person, than dedicate that time when the rest of the world is asleep to get down to some serious writing. If you're just a 'daytime' person, give yourself large blocks of time to write in. An hour here and an hour there is no use - you need time to get 'in the zone' - this can take anything from a few minutes to half a day, depending on the circumstances.

On that note, take every little bit of progress as a positive step forward. I once spent a fortnight writing a paragraph. It was horrific. But, every day was a little bit of progress in understanding and in formulating my argument. Words can sometimes be slow, but the cognitive process going on in the background is important too and easy to overlook or to not consider as proper progress.

Lastly, on the topic of the viva, a few tips.

One: You cannot ever feel ready for the viva. You will almost certainly be ready for the viva though - your supervisor would not recommend that you submit the thesis otherwise (if they're doing their job properly). 

Two: Therefore, the best preparation you can do for the viva is to talk about your research. Know it like a second language. Be fluent in your core argument and the main supporting structures of your writing. This will give you confidence (you will still not feel prepared though, probably!)

Three: Know your examiners. This is an obvious tip but again it will build your confidence and your ability to answer viva questions in a way that your examiners will 'get'. 

Four: Use the online resources and communities available to you - reading other people's experiences reminds you that you are not the only one doing this herculean task. This is a good thing to remember for your sanity.

That's about it. I could go into more depth but I would only be repeating what many other places online have already said, probably more eloquently. Plus, I need to get on with writing this semester's lectures. 

Shut up - that is an entirely different form of writing guilt...

You can download an electronic version of my thesis here.

Friday, 29 August 2014

DiGRA 2014 Paper: Disrupting the Player's Schematised Knowledge of Game Components

My DiGRA 2014 Paper, Disrupting the Player's Schematised Knowledge of Game Components, is now available via the DiGRA Digital Library database. 

The paper outlines the theoretical basis for the disruptive game design philosophy and framework that I have been developing over the past 4 years and also provides a small case study of how it was implemented in two instances in Amnesia: A Machine for Pigs.

In other news, I am approaching completion of my thesis (finally) and should be submitting it for examination and viva around Christmas time. Further journal publications are in the works that will further expand some of the ideas that I didn't have space to write about in this DiGRA paper and I will post those here as they become available.

Frequent blog posts will hopefully resume once again shortly... I have many topics I'd like to write about and no time in which to write them! 

The DiGRA 2014 paper can be found here.