A New Internet Library: Add Your Website/Blog or Suggest A Website/Blog to our Free Web Directory http://anil.myfunda.net.

Its very simple, free and SEO Friendly.
Submit Now....

Monday, April 13, 2020

WHO IS ETHICAL HACKER

Who is hacker?
A hacker is a Creative person and a creative Programmer,who have knowledge about Networking,Operating system,hacking & a best creative social engineer who control anyone's mind he is also a knowledgeable person.
Hacker are the problem solver and tool builder.

                                OR

A hacker is an individual who uses computer, networking and other skills to overcome a technical problem but it often refers to a person who uses his or her abilities to gain unauthorized access to system or networks in  order to commit crimes. 


More articles


Hacking All The Cars - Part 1


A step by step lab based mini course on analyzing your car network


I wanted to learn about hacking cars. As usual I searched around the internet and didn't find any comprehensive resources on how to do this, just bits and pieces of the same info over and over which is frustrating. I am not a car hacking expert, I just like to hack stuff. This mini course will run in a fully simulated lab environment available from open garages, which means in 5 minutes from now you can follow along and hack cars without ever bricking your girlfriends car. Since you obviously wouldn't attack your own Lambo, totally use your girlfriends Prius. 

Below are the topics covered in this blog  series so you can decide if you want to read further: 

Whats covered in this car hacking mini course: 

Setting up Virtual Environments for testing
Sniffing CAN Traffic
Parsing CAN Traffic
Reverse Engineering CAN IDs 
Denial of service attacks
Replaying/Injecting Traffic
Coding your own CAN Socket Tools in python
Targeted attacks against your cars components
Transitioning this to attacking a real car with hardware

The first thing we are going to do before we get into any car hacking specifics such as "WTF is CAN?", is get your lab up and running. We are going to run a simple simulated CAN Bus network which controls various features of your simulated car. Its better to learn by doing then sit here and recite a bunch of car network lingo at you and hope you remember it.  

I also don't want you to buy a bunch of hardware and jack into your real car right away. Instead there are options that can get you started hacking cars RIGHT NOW by following along with this tutorial. This will also serve to take away the fear of hacking your actual car by understanding what your doing first. 


Video Playlist: 




Setting up your Lab: 

First things first, set yourself up with an Ubuntu VMware install, and load it up. Optionally you could use a Kali Iinux VM, however, that thing drives me nuts with copy paste issues and I think Kayak was giving me install problems. So support is on you if you would like to use Kali. However, I do know Kali will work fine with OpenGarages virtual car.. So feel free to use it for that if you have it handy and want to get started right away. 


Install PreReq Libraries: 

Once you load this up you are going to want to install CAN utilities and pre-requisite libraries. This is really easy to do with the following Apt-get commands:
sudo apt-get update
sudo apt-get install libsdl2-dev libsdl2-image-dev can-utils  

Then we are going to pull down the ICSimulator repo: 


Starting the simulator: 

Once this is done we can startup the simulator by changing directories to the downloaded repo and running the following 2 commands, which will setup a virtual CAN interface and a simulator GUI Cluster: 

Run the setup Script to get the vcan0 interface up: 
root@kali:~/ICSim# ./setup_vcan.sh 
root@kali:~/ICSim# ./icsim vcan0

On a new terminal tab we will open up our simulators controller with the following command,
root@kali:~/ICSim#./controls vcan0

Note: that the controller must be the in-focus GUI screen to send keyboard commands to the simulator. 






How to Use the Simulator: 

The simulator has a speedometer with Right and Left turn signals, doors etc.  Below are the list of commands to control the simulator when the Control panel is in focus. Give them each a try and note the changes to the simulator. 
Up and Down keys control the gauges clusters speedometer
Left and Right keys Control the Blinkers
Right Shift + X, A or B open doors 
Left Shift + X, A or be Close doors

Try a few of the above commands for example Right Shift +X and you will see the interface change like so, notice the open door graphic: 


Awesome, thanks to OpenGarages you now you have your very own car to hack

Notice in the setup commands above we used a VCan0 interface. Run Ifconfig and you will now see that you indeed have a new network interface that speaks to the CAN network over VCan0. 

ficti0n@ubuntu:~/Desktop/ICSim$ ifconfig vcan0
vcan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:558904 errors:0 dropped:0 overruns:0 frame:0
          TX packets:558904 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:3663935 (3.6 MB)  TX bytes:3663935 (3.6 MB)


Car networks run on a variety of protocols most prevalent being CAN. You can think of a CAN Bus like an old school networking hub where everyone can see everyone elses traffic. This is true to some extent although you may not see all of the cars traffic if its not connected to that particular bus your plugged into. You can think of CAN traffic kind of like UDP in that its send and forget, the main difference being parts of the CAN bus network don't actually have addresses and everything runs off arbitration IDs and priorities. Thats enough background to get you doing rather then reading.

With a little knowledge out of the way lets check if we can see our CAN traffic from our virtual car via the CanDump utility, which you installed as part of CanUtils package above. Using the following command on the vcan0 interface our simulator uses you can view a stream of traffic: 

ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0



Above we can see a bunch of CAN frames, and if we perform actions on the vehicle we will see changes to data values in the CanDump output.  However this may happen very fast, and we may not be able to see if for example we unlocked our simulators door. This is because things are changing constantly in the cars IDLE state. One single value changing may not stand out enough for us to take notice or may scroll so fast we cant see it. 


Capture and Replay CAN Actions: 

One option would be to perform an action and replay it, we should see the actions happen again in the replay if the traffic for the action we recorded is on the same bus network our device is plugged into. There are loads of networks within a car and its not guaranteed our network tap for example an OBD2 port plugin is connected to the same network as door we opened.  Or the door may not be connected to the network at all depending on your car and its age or how its configured. 

Replaying dumps with CanPlayer: 
Another useful tool included with CanUtils package is CanPlayer for replaying traffic. If the functionality we are trying to capture is on the same Bus as the adaptor plugged into the car, or in this case our Virtual CAN interface, we can use CanDump to save traffic to a file. We then use CanPlayer to replay the traffic on the network. For example lets run CanDump and open a door and then replay the functionality with CanPlayer. 

Lab 1 Steps: 

  1. Run CanDump
  2. Right Shift + X to open a door
  3. Cancel CanDump (ctrl+c)
  4. Left Shift + X to close the door
  5. Run can player with the saved dump and it will replay the traffic and open the door

Recording the door opening:  (-l for logging) 
ficti0n@ubuntu:~/Desktop/ICSim$ candump -l vcan0

Replaying the CanDump file:  (use the file your can dump created) 
ficti0n@ubuntu:~/Desktop/ICSim$ canplayer -I candump-2018-04-06_154441.log 

Nice, so if all went well you should see that your door is now open again. If this did not happen when attacking a real car, just try to replay it again. CAN networks are not like TCP/IP, they are more like UDP in that you send out your request and its not expecting a response. So if it gets lost then it gets lost and you have to resend. Perhaps something with higher priority on the network was sending at the time of your replay and your traffic was overshadowed by it.   




Interacting with the Can Bus and Reversing Traffic: 

So thats cool, but what about actually understanding what is going on with this traffic, CanDump is not very useful for this, is scrolls by to quickly for us to learn much from.  Instead we can use CanSniffer with colorized output to show us the bytes within packets that change. Below is an example of CanSniffer Traffic: 

To startup can sniffer run the following: 
ficti0n@ubuntu:~/Desktop/ICSim$ cansniffer -c vcan0




You will see 3 fields, Time, ID  and Data. Its pretty easy to figure out what these are based on thier name. The most important part for our usage in this blog are the ID and the Data fields.  

The ID field is the frame ID which is loosely associated with the device on the network which is effected by the frame being sent. The ID to also determines the priority of the frame on the network.  The lower the number of the CAN-ID the higher priority it has on the network and more likely it will be handled first.  The data field is the data being sent to change some parameter like unlocking a door or updating output. You will notice that some of the bytes are highlighted RED. The values in red are the values that are changing during the idle state you are currently in. 


Determine which ID and Byte controls the throttle: 

So with the terminal sniffing window open put the simulator and the controller into the foreground, with the controller being the window you have clicked and selected.  Pay attention to the CanSniffer output while hitting the UP ARROW and look for a value that was white but is now Red and increasing in value as the throttle goes up.  This might take you a few minutes of paying attention to whats going on to see. 

The following 2 pictures show ID 244 in the IDLE state followed by pressing the up button to increase the speed. You will notice a byte has turned red and is increasing in value through a range of HEX values 0-F. It will continue to enumerate through values till it reaches its max speed. 





The byte in ID 244 which is changing is the value while the throttle is engaged, so 244 associated in some way with the increasing speed.   The throttle speed is a good value to start with as it keeps increasing its value when pressed making it easier to spot while viewing the CanSniffer output.  


Singling out Values with Filters: 

If you would like to single out the throttle value then click the terminal window and press -000000 followed by the Enter key which will clear out all of the values scrolling. Then press +244 followed by the Enter key which will add back the throttle ID. You can now click the controller again and increase the speed with your Up arrow button without all the noise clouding your view.  You will instead as shown below only have ID 244 in your output: 




To get back all of the IDs again click the terminal window and input +000000 followed by the Enter key.   Now you should see all of the output as before.  Essentially 000000 means include everything. But when you put a minus in front of it then it negates everything and clears your terminal window filtering out all values. 


Determine Blinker ID: 

Now lets figure out another ID for the blinkers. If you hit the left or right arrow with the controls window selected you will notice a whole new ID appears in the list, ID 188 shown in the picture below which is associated with the blinker. 




This ID was not listed before as it was not in use within the data output until you pressed the blinker control.  Lets single this value out by pressing -000000 followed by +188.  Just like in the throttle example your terminal should only show ID 188, initially it will show with 00 byte values. 

 As you press the left and the right blinker you will see the first Byte change from 00 to 01 or 02. If neither is pressed as in the screenshot above it will be 00. Its kind of hard to have the controller in focus and get a screenshot at the same time but the ID will remain visible as 00 until it times out and disappears from the list when not active. However with it filtered out as above you can get a better view of things and it wont disappear.  


Time for YOU to do some Protocol Reversing:

This lab will give you a good idea how to reverse all of the functionality of the car and associate each action with the proper ID and BYTE. This way you can create a map of intended functionality changes you wish to make.  Above we have done a few walk throughs with you on how to determine which byte and ID is associated with an action. Now its time to map everything out yourself with all the remaining functionality before moving on to attacking individual components.  


Lab Work Suggestion: 


  1. Take out a piece of paper and a pencil
  2. Try unlocking and locking doors and write down the ID which controls this action (remember your filters)
  3. Try unlocking each door and write down the BYTES needed for each door to open
  4. Try locking each doors and what Bytes change and what are their values, write them down
  5. Do the same thing for the blinkers left and right (Might be different then what I did above) 
  6. What ID is the speedometer using?  What byte changes the speed? 


Attacking Functionality Directly: 

With all of the functionality mapped out we can now try to target various devices in the network directly without interacting with the controllers GUI. Maybe we broke into the car via cellular OnStar connection  or the center console units BLE connection which was connected to the CAN network in some way.  
After an exploit we have direct access to the CAN network and we would like to perform actions. Or maybe you have installed a wireless device into an OBD2 port under the dashboard you have remote access to the automobile. 

Using the data from the CAN network reversing lab above we can call these actions directly with the proper CAN-ID and Byte.  Since we are remote to the target we can't just reach over and grab the steering wheel or hit the throttle we will instead send your CAN frame to make the change.
One way we can do this is via the CanSend utility. Lets take our information from our lab above and make the left turn signal flash with the following ID 188 for the turn signal by changing the first byte to 01 indicating the left signal is pressed. CanSend uses the format ID#Data. You will see this below when sending the turn signal via CanSend. 

ficti0n@ubuntu:~/Desktop/ICSim$ cansend vcan0 188#01000000 



You should have noticed that the left signal flashed. If not pay more attention and give it another try or make sure you used the correct ID and changed the correct byte.  So lets do the same thing with the throttle and try to set the speed to something with ID 244 that we determined was the throttle. 

ficti0n@ubuntu:~/Desktop/ICSim$ cansend vcan0 244#00000011F6 

My guess is that nothing happened because its so fast the needle is not going to jump to that value. So instead lets try repeating this over and over again with a bash loop which simply says that while True keep sending the throttle value of 11 which equates to about 30mph: 

ficti0n@ubuntu:~/Desktop/ICSim$ while true; do cansend vcan0 244#00000011F6;  done




Yes thats much better, you may notice the needle jumping back and forth a bit. The reason the needle is bouncing back and forth is because the normal CAN traffic is sent telling the car its actually set to 00 in between your frames saying its 30mph.  But it worked and you have now changed the speed the car sees and you have flashed the blinker without using the cars normal blinker controls. Pretty cool right? 


Monitor the CAN Bus and react to it: 

Another way to handle this issue is to monitor the CAN network and when it sees an ID sent it will automatically send the corresponding ID with a different value.. Lets give that a try to modify our speed output by monitoring for changes. Below we are simply running CanDump and parsing for ID 244 in the log output which is the throttle value that tells the car the speed. When a device in the car reports ID 244 and its value we will immediately resend our own value saying the speed is 30mph with the value 11.  See below command and try this out. 

ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0 | grep " 244 " | while read line; do cansend vcan0 244#00000011F6; done

With this running after a few seconds you will see the speed adjust to around 30MPH once it captures a legitimate CAN-ID 244 from the network traffic and sends its own value right after.  

Ok cool, so now while the above command is still running click the controller window and start holding down the Up arrow with the controller in focus.. After a few seconds or so when the speed gets above 30MPH you will see the needle fighting for the real higher value and adjusting back to 30MPH as your command keeps sending its on value as a replacement to the real speed. 

So thats one way of monitoring the network and reacting to what you see in a very crude manner.  Maybe someone stole your car and you want to monitor for an open door and if they try to open the door it immediately locks them in. 


Conclusion and whats next: 

I am not an expert car hacker but I hope you enjoyed this. Thats about as far as I want to go into this subject today, in the next blog we will get into how to code python to perform actions on the CAN network to manipulate things in a similar way.  With your own code you are not limited to the functionality of the tools you are provided and can do whatever you want. This is much more powerful then just using the CanUtils pre defined tools. Later on I will also get into the hardware side of things if you would like to try this on a real car where things are more complicated and things can go wrong. 

Related articles

SigPloit SS7 Tool

Related posts

Saturday, April 11, 2020

Thoughts On Detroit: Become Human

By Thomas Grip

Quantic Dream learns with each game, and adresses their issues with new features. But with new features come new issues, and lots of juicy design lessons. In this blog post I will talk at length about affordance, then touch upon branching and themes.

Intro

It has been a while since my last design blog, and I felt it was finally time to write one again. And since I just played through Detroit: Become Human, that's what I decided to write about.

First off, let me say that I quite liked the game. I had issues with how they tackled some of the themes (especially in regards to robots), and felt they could have taken some aspects of the world they created more seriously.

What made up for the so-so narrative bits were the production value (such as some very cool environments), and the myriad of exciting scenarios. It's not an easy feat to create scenes that are not just narratively compelling, but also engaging play-wise – especially not in the sort of story that Detroit tells.


On top of this, the branching and the choice possibilities in Detroit are insane. It is a lengthy game, taking well over 10 hours to complete, and yet as the story unfolds there is a constant stream of differences that all depend on your previous choices. Everything to how crime scenes change to how characters make remarks depending on how you played some previous scene is amazingly well done. The scenes are constantly constructed from a wide array of options, but everything flows together into a coherent whole. Other branching games, such as Hidden Agenda, have a much more jarring presentation where the inserted lines and cuts in the flow are obvious. In Detroit, flow flaws are basically nonexistent.

So, it is fair to say that production-wise Detroit is quite a achievement. However, the game starts to stumble as it tries to be just that – a game.

Just like with previous titles from Quantic Dream, Detroit tries to be what is essentially a playable movie. Mixing film and games gives rise to all sorts of interesting design decisions and issues – issues that are hard to see in other games. It is clear that Quantic Dream are aware of the flaws they have had in their previous games, and there are a bunch of new feature that try to address the issues.

But with new features come new issues, and lots of juicy design lessons. In this blog post I will talk at length about affordance, then touch upon branching and themes.


Affordance

The first topic of this blog is how Detroit: Become Human handles affordance. The game takes place in one of the most challenging environments there is design-wise: inhabited real-life spaces. Spaces that contain a bunch of everyday items, such as drawers, pictures, tools, televisions, coffee cups, keyboards, clothes and so on and so forth. These are all objects we are not just accustomed to interact with – we also have expectations of their usage. As a player, you need to be able to figure out what objects you can interact with and in doing so you are constantly battling your ingrained notion of how these objects ought to work.


In Heavy Rain (2010), Quantic Dream's earlier game, the only way to figure what you can and cannot interact with is to carefully check your surroundings and see if an interaction icon pops up. There are some objects that signal pretty clearly that you can interact with them, such as a corpse at a crime scene that you are able to examine. A design goal for a game should be to be able to use your intuition to figure out what sort of items you ought to be able to interact with – but the Heavy Rain never lets you train that intuition. Obvious objects are more an exception than a rule, and thus the player's optimal strategy ends up being doing a brute force search of the room to try and locate all the hotspots.

So why is this bad?

There are two main issues with not being to identify points interaction. The first one is that it lessens the game's sense of immersion. The second is that it doesn't allow you to properly "play" the game. Detroit has some tricks up its sleeve to reduce both of these, but before we get into that it is worth to discuss just what is so problematic with these issues.

Immersion

Let us first go over the issue of immersion.

In order for a player to feel immersed in an environment, they need to internalize the surroundings. This is something I have covered in other posts, but basically it means that players need to actively take a part in the fantasy. And in order for a player to feel present inside a virtual world, they need to have what is called internal representation.

While it may not seem like it, real life also operates on internal representation. You don't simply "see a chair". The act of seeing a chair triggers all sorts of data about chairs: what their physical properties are, what you can do with them, what are your available actions and so forth. All of these combine into the actual sensation that there is a chair in front of you.

Here comes the issue. If you play a game where looking at a chair lacks any situational data, the player's mental representation is empty. They fail to build any vivid fantasy for the virtual scene that the game tries to build. In turn the player is unable to place themselves, as in their actual selves, inside the game world. When games fail to take this into account it results in a world that doesn't feel very immersive.

Play

Secondly, the gameplay issue with affordances is that the player lacks the ability to plan. I have gone over player planning and why it is so important for good gameplay in a previous post, but let's do a quick recap: we don't play games by just reacting to stimuli that the games send our way – instead, most of the gameplay takes place inside our heads. We survey our environments, go over long- and short-term goals, and decide what set of actions are the most optimal to reach said goals. The longer and more accurate plans a game allows the player to make, the better it will feel to play.

As a clear example, let's compare a moment playing Dragon's Lair (1983) to a moment in Civilization (1991). Civilization is filled with possibilities and room for planning. Dragon's Lair on the other hand is just a linear path where you can only get good by memorizing a specific sequence. This is not the most fair example, but should illustrate the primal differences.


Games like Heavy Rain and Detroit, as well as classic adventure games, rely on putting the player in a real-life situation and making that the core of planning one's actions. Taken at face value, it's somewhat easy to understand what your options are when trying to find shelter for the night, because it is all based around elements that we know from real life. It's much harder to know what to do during a laser-wielding vampire bat robot attack.

The issue is that the real world is incredibly complex, and a game cannot possibly recreate all the alternatives that a person could think of. This means that even though you might intuitively make up a certain plan, you can't be sure whether the game will actually support it or not.

Solutions?

The main trick of Detroit, and Heavy Rain before it, is to simply make each scene feel like a movie scene. It gives the player a feeling for how the scene ought to evolve next, and how the character(s) ought to react. So the player gains their affordances not from how they view the scene, but how they imagine the characters (and to some extend the director) doing it. On top of that, the very cinematic structure pushes a narrative that makes up for the lack of immersion.

The player's feelings here depend a lot on how they play the game. If they play as if they are the protagonist, these problems can become quite severe. It is a lot less damaging if the player views their role as a director. Then they are distancing themselves from the game and viewing the whole experience differently. Most of the discussions I bring up in this post are mainly centered around the former playstyle where you actively take on the role of a certain character.

Therefore, imagining yourself as the character in Quantic Dream games doesn't really hold up – especially when the player is supposed to have a more lengthy interaction. In Heavy Rain it is easy to fall into optimizing behaviour and do brute force search to see what you can interact with. This sort of searching turns what is supposed to be a realistic environment into an abstract play field. Heavy Rain also has real trouble giving you a sense of your options. So, most of the game is played based on moment-to-moment reactions rather than deliberate planning. More Dragon's Lair than Civilization.

It is clear that Quantic Dream know about these issues, as Detroit does quite a lot of things to try and fix this. The two major ones are explicit hotspots, and quest lists. The hotspots that pop up make it feel like a "batman mode", where the time stops and the environment gets a line-mesh overlay. When in this mode, all nearby possible interactions display glowing icons. On top of this, all of the character's short term goals are displayed as well, including those that haven't been unlocked yet. Detroit also shows various goals, and even characters' feelings, as big in-world text throughout the game. This gives the player a better idea of what they are supposed to do, and what are the available tools to achieve their goals.

Problems

The problem is that these new features don't really try to fix the underlying problems of affordance. They are more like crutches, propping a flawed system. In a perfect world, these systems should be used as a sort of tutorial for the player. Once they get a better sense of how the game works, they should be able to stop relying on them, and instead rely on their intuitive understanding.

What happens instead is the opposite. The further you get into Detroit, the more prone you get to use these systems. In my playthrough of Detroit I used the "batman mode" quite sparingly for the first few hours – but as time went on I used it more, to the point where I almost stopped trying to intuitively parse the environment at all. Why? Because if I didn't use it, I was more likely to miss hotspots and tasks, and therefore not get everything I wanted from the scene.

In the end, this style of play actually made me plan more. But all of this planning was happening in an abstract realm. I was playing a game of "choose from explicit options given to me by the game's designer", rather than actually making decisions based on the world that was presented to me. This often lead to weird situations where I did tasks that I didn't know existed (eg. go look for a bag I didn't even know was there).


Worse still, it made me act less like the characters I was supposed to be playing as. Detroit features a fair bit of detailed crime scenes that I was supposed to search, but because of the crutches I never tried to analyze the scenes as an actual detective. Instead I was simply searching for abstract hotspots. To make matters worse, the game often told me just how many hotspots there were to find, making me feel and thing even less like a detective.

The important takeaway here is just how important it is to find a way to create a game that actually makes the player engage in the game as it is. Detroit is not the only game that uses this kind of crutch, it's quite common. And it is not always bad, either. For instance in Metal Gear Solid you have exclamation points pop up over soldiers' heads when they spot you. However, they key difference here is that it adds information to the scene that is already in front of you. There are actual character models, sounds and so forth that play into the scene.

When you try to design crutches, you need to make sure that they supply something extra to the fantasy. They shouldn't act as a substitute for the game's actual world.

The magic of narrative

It might seem like I didn't like the gameplay in Detroit – but the fact is that I found it quite engaging. I think this is really interesting. Despite all of the apparent flaws in the system, it still felt like I was part of the narrative. This was especially true for the detective work. The same was also true in the 2018 Call of Cthulhu game. There the detective scenes were even more simplistic, almost like playing a basic "hidden object" game, and yet I found them strangely compelling.

How is this possible? I think a lot of this is in line with the 4-layer approach that I've written about before. The foundational thinking with the 4-layer approach is that when you put any gameplay in the context of story, doing that gameplay feels like playing a story. Detroit does a lot of things right when creating this sort of merger between systems and narrative.

First of all, Detroit is very good at setting up the context. A scene always starts with some sort of cutscene ("cutscene" feeling like a weird word in an interactive film game, but working as a distinction in this context), that lays out the story reasons as to why you are doing the investigation. So when you are essentially searching for hotspots, the whole setup makes it feel as if you are doing detective work, even if you are not mentally embracing the detective role.


Secondly, when you find a hotspot, you always get information that has something to do with the narrative. The actual value of the information varies a lot: sometimes it's useful and sometimes it's just techno babble. But in all cases it feels like narrative feedback. When this is combined with the explicit – and very gamey – feedback that says you just found one of the three clues, it feels more like progressing a case than fulfilling abstract game requirements.

Finally, when you manage to find all the clues, the abstract (game-y) accomplishment always comes with some sort of narrative reward. For instance when searching a corpse, you get to view a reconstruction of what happened to this person. In many other cases you may unlock a new dialog option. And in every case you feel like completing the tasks makes you progress the narrative. So, even though the gameplay is abstracted, you still feel like you are inside a story.

The power of holism

On the surface all of this feels a bit like cheating. But I think that's the wrong way to look at it. Instead it's something to be embraced.

In fact, on our journey to progress the storytelling potential of games as a medium, I am of the position that trying to do it without any form of "cheating" is a dead end. All entertainment is based on fooling your audience. Illusion is an essential part of the craft. The trick is just to cheat in such a way that it goes unnoticed.

What feeds into this illusion is the fact that humans tend to be bad at understanding why they're feeling something. As an example: one tends to find a potential partner more attractive when drinking something hot while around the person. That is because hot drinks activate responses similar to arousal, eg. increasing the blood flow. The brain just tends to attribute these responses not to coffee, but to the potential partner, tricking you into thinking you are feeling aroused.

In a similar manner, when you feel accomplished for finding one of the three abstract hotspots, that feeling gets entwined with the detective narrative. These two parts get mixed into a single whole, and that whole becomes a compelling experience. It is worth to note that both sides can help the other. The narrative makes simple gameplay feel exciting, and the feedback on the other hand can make flawed narrative feel compelling. It is larger than the sum of its parts in the purest sense.

You can get an especially good sense of how this two-way feedback works when the system starts breaking down. I find that this can happen quite a lot in Detroit's action sequences. There the narrative stops being the focal point, there are less narrative rewards upon success, and the input gets less clear (as it is merely about split second reactions). As long as the goals and actions are easily identifiable, eg. hiding and closing a door, the narrative-system symbiosis remains in place. But once it turns into blocking and returning punches, the player (or at least I) get distanced from the action. It becomes more of an abstract challenge than a piece of interactive storytelling.


So in a way, the increased abstraction actually works for Detroit's benefit. By showing some numbers going up, and clear objective pointers, the game manages to add a more concrete feedback loop. As explained above, it also comes with issues, but also gives the game more opportunities for narrative-system symbiosis.

Detroit uses the symbiosis to simulate all sorts of situations, often with quite pleasing results. What stood out for me was an interrogation scene with a stressed-out android, and a scene where I had to make sure a police officer didn't become too suspicious of my character. The success of those scenes came from mixing simple, gamey systems together with narrative in a holistic manner.

If you want to dig deeper into various ways to achieve this sort of merging of elements, Detroit is an excellent case study. Since the scenes featured are quite diverse, the ways of combining systems an narrative vary, and the results vary along with that.

Improvements?

While there are many interesting aspects about the game, it does have lot of room for improvement. I want to discuss that a bit.

Detroit relies heavily on increased abstractions (such as the aforementioned hotspots and objectives), and I don't think that's the right way. I find it better to try and achieve the same kind of affordance by using a story-like world. It is not the abstraction per se that allows to combine systems and narrative, but the player's understanding of cause and effect.

Using abstractions also comes with a lot of issues. In my opinion, the biggest issue is the negative effect on immersion. If the world the player navigates is just filled with simple, systems-specific abstractions, the player can never transport themselves into the world.

At best, the actual rendered world (environments, characters etc.) just becomes narrative background. Instead as a designer, you want the world's elements to be what the player uses in order to be an active part of the game. The aim should be for the player to gaze at a rendered scene, and have a mental model of all the interaction points and how these can be used for various plans, as I have written earlier.

Just compare a scene from Detroit…


...to a scene in Super Mario Bros.


In Detroit, I am not sure what things I can interact with, nor how they would affect me. From just looking at the world as-is, it is impossible to make any sort of concrete action plan. On the other hand Mario is very accessible, at least to anyone who has ever played the game. You can easily see every object, imagine how you can interact with it, and plan your progress accordingly.

The sort of readability that a Super Mario game has is what you want as a game designer. The thing to learn from Detroit is that you don't need incredibly complex actions in scenes to create an engaging narrative. In fact, the actual gameplay can be simple and "dull" – as long as you are able to combine it with a narrative. However, there would be a huge difference if the interactions you partake in are grounded in the game's world, instead of just being abstractions.

There are obviously other things to improve, especially the player's ability to plan. But as a first step, I think having Super Mario level of affordance in the game's world would be a huge improvement.


Branching

Now before I end this article, there are two more topics I want to cover. The first of these is branching.

Before making Detroit: Become Human, Quantic Dream made Beyond: Two Souls (2013). This game took a slightly different approach to the idea of a game as an interactive movie – especially when it came to branching. The game's story had a ton of different ways to play out, but as recounted in this article by Press X to Story, it went mostly unnoticed by players.

It feels like Quantic Dream really reacted to this because damn, they are now really pushing the branching angle. There is a node tree at the end of each scene, there's visual cues when conversation subjects unlock, there are lists of things you could do, the latter scenes obviously change, and so on.

And it really does feel like the open story and the branching matters. Especially interesting are the node maps. In the maps, all the choices you could have made are laid out, but the ones you didn't make in your current or previous game are blanked out. At first I really didn't like it, but the more I played the more it grew on me. It seems like it had a certain ad-hoc effect, and I can still sort of feel it. Remembering a scene often feels cooler than actually playing it. To me, the Detroit showing you potential paths I could have taken make my choices seem more compelling, when viewed in retrospect.


This might feel a bit like a cheat. But as discussed before, cheating is how entertainment works. Still, a part of me wonders if Detroit could have handled it in a more subtle way. Sometimes it felt like too much to get all the possible courses of events shoved in my face. I would have liked it if the would have treated the overall branching as it did the special dialog and changes in scenes. But at the same time, I wonder if that would have given across the feeling that the story was indeed open-ended and had tons of options – as Beyond: Two Souls failed to convey.

The best way to get away from the trap of being overly explicit is to, as explained above, up the level of affordance. In a perfect scenario, the player should know about the ways the scene could have gone simply by having mentally analyzed the scene. For instance, Civilization doesn't need a node map at the end of a round for the player to know that there are many other ways things could have gone. This is not the most fair comparison, as I don't think it's possible to make a storytelling game that is as systemically driven. But it does give you a sense of what sort of feeling games could strive for.


Themes

Given that Detroit deals with a few themes similar to SOMA, it feels like I need to say something about Detroit's themes to close this off. It would be too much to go over all aspects of the game, so I will just focus on one: robot and human similarities.

I think the game would have been a lot more thematically interesting if the robots didn't look so human. Instead I think it would have been much better if they looked like the robots from the movie I, Robot (2004), or perhaps something out of the Boston Dynamics lab.


Right now it's just too easy to sympathise with the robots. It would be much more fun if the player started the game thinking the robots did not deserve any rights, and the thinking would evolve throughout the game.

The robots' thinking is also too human. Again, it would be much cooler if they felt more alien in how they handled their emotions and so forth. There is actually less neurodiversity between humans and robots in Detroit than there is among real humans overall.

For example, right now it doesn't make much sense for a player to want for Connor to stay an obedient robot. The story pretty clearly pushes the player to want Connor to become a deviant (a robot free from human masters). If the Connor had looked a bit more spooky, or had weirder ways of thinking, it would have made the choice less obvious and forced me to think more about my alternatives.

It would also seem weird that people would want to buy servants that look so human. People can already feel bad for a Roomba, let alone something that looks like a fellow human. It would make more sense for the robots to actually look like robots.

I know that Quantic Dream wanted to show off their facial animation tech, and make sure it was easy to relate to the protagonists. But the point stands: a version of Detroit with robots that are clearly not human would be damn interesting to play.

Wednesday, April 8, 2020

Percy Bysshe Shelley's "Poetical Essay" Belongs In The Public Domain



Image assumed to be in the Public Domain


The following is a tragic tale about how valuable work of literature was rediscovered, and then undiscovered. This loss for the arts was not due purely to negligence or accident, but to a selfish violation to the memory of Percy Bysshe Shelley. Even if you don't read Shelley, you should, at the very least, be profoundly perturbed by the ways in which the wealthy claim exclusive ownership over our cultural history. Shelley was a victim of avaricious entitlement.



In 2010, The Guardian reported a finding the rocked the literary world. Daisy Hay, a Cambridge graduate, was snooping through the library, as most graduates do, and came across an old manuscript. It turns out that these writings were the unpublished memoirs of one Claire Clairmont, Byron's former lover and a friend of Percy Bysshe Shelley. In these memoirs, she described these two poets in no genial terms, calling them "monsters of lying, meanness, cruelty and treachery." Clairmont, who was at that point a Catholic, branded Byron and Shelley as worshipers of "free love", who ruined the lives of women. Clairmont had personal experience with this ruination, and good reason to be sour. Soon after getting her pregnant with Allegra (who died at age eight), Byron abandoned Clairmont, presumably because he was married to another woman at the time. For this, she labelled him, "a human tyger [sic] slaking his thirst for inflicting pain upon defenceless women" (Alberge).

The writings have proved to be a boon to historians and biographers everywhere, and has helped to increase our understanding of the relationship between Clairmont and the Shelley's. Imagine, however, if Hay decided to sell Clairmont's memoirs to the highest bidder with the new owner refusing to allow anyone else to read the memoirs except himself. Such an action would be rightfully denounced as a greedy theft of history, a selfish attempt to claim personal rights to our global cultural heritage. Distasteful though it may be to entertain such callous contempt for the ever fragile past, it isn't beyond the depravity of some human beings to do so. Daisy Hay was not such an entity. Quaritch Rare Books & Manuscripts, it appears, is.

Of course, when Quaritch sold the recently discovered "Poetical Essay" by Percy Bysshe Shelley, they may have assumed that the owner would be generous enough to share Shelley's words with the public. Though if so, then it would've certainly been little trouble to ask. They were careless, however, in hastily selling off the "Poetical Essay" to the one with the fattest wallet. Quaritch knew how valuable this piece of Shelley's was, (or at least they should have) yet they felt no responsibility to alert local historians? Shameful. I don't have to tell you the exact amount of money paid to Quaritch for selling the "Poetical Essay", except that it weighed about the same as the silver coins paid to Judas Iscariot.

The news of the "Poetical Essay's" rediscovery was the toast of The Guardian in 2006,

"The revelation in today's Times Literary Supplement that an early poem by the great Percy Bysshe Shelley has come to light, and is in the possession of a London bookseller, will cause even more excitement than most. This is a wonderful discovery: few Shelley scholars ever believed the poem, Poetical Essay, would resurface and some even doubted its existence. It is a fantastic chance to learn more about the political and poetic development of the young Shelley," (O'Brien).

However, four years later, the same year, mind you, that Daisy Hay found Clairmont's memoirs, the "Poetical Essay" had vanished once more from the public eye. Michael Rosen noted that the poem in it's entirety was never made available, the reason being that only three people had read it: owner at Quaritch, the person who bought the poem, and some lucky professor by the name of Henry R Woudhuysen. The new owner, apparently, isn't interested in letting any of us peasants read his new treasure. More odd to Rosen, though, was the lack of outrage over the whole scandal, "we were approaching the fourth anniversary of the rediscovery of Shelley's "Poetical Essay" and that we, the public, were no nearer to reading it." (The Guardian) Rosen succinctly expresses his anger well in this paragraph,

"First of all, I would like the poem to be available to read by anyone who is interested. I believe that should have happened the moment it was rediscovered. Secondly, I want to know why Professor Woudhuysen was given the right to look at the poem, but no one else was. Thirdly, I want to know why this situation doesn't seem to bother anyone in the great republic of letters, least of all that guardian of literary precision and exactitude, the TLS. Isn't it an outrage, that a long dead, great writer's work can be hidden away in its owner's drawer?"

Rosen is completely correct here, "Owning manuscripts is one thing: owning the contents is quite another." Copyright laws back him up, too. In general, works fall into public domain 70 years after the death of the creator. This has recently been stalled in the United States by corporations such as Disney, but that's a discussion for another time. What matters, for the moment, is that Shelley's "Poetical Essay" was written in 1811, well past due any claims to copyright. Thus, the "Poetical Essay" is in the public domain, meaning: it belongs to us, the public. We, collectively, have a right to the contents of Shelley's essay, and it is illegal, let me repeat, illegal for the current owner to claim otherwise. There should be a manhunt for this shrewd, elitist coward, I want a subpoena for his arrest. Quaritch should be, at the very least, fined for their blatant carelessness with such a historical artifact. Their hands aren't clean in this affair. They are complicit, in every sense of the word.

So just what was Shelley's "Poetical Essay" all about? It is an anti-militarist piece, written in defense of Peter Finnerty, a critic of Britian's suppression of an Irish revolt, who was later imprisoned for speaking out. Paul O'Brien gave the poem background upon its discovery,

"But his first and defining political campaign was about Irish religious and political freedom - and it is here where the discovery of Poetical Essay is most relevant. Shelley published it in support of Peter Finnerty, the Irish journalist jailed for libelling Viscount Castlereagh, the Anglo-Irish politician who was sent to Ireland in 1797 to crush the United Irishmen rebelling against British rule. Castlereagh's brutality made him the most hated man in Ireland. Shelley was a professed admirer of the United Irishmen, and the events and personalities of the 1798 rebellion were crucial to his political and intellectual development. His abiding hatred for Castlereagh was venomously expressed in the Mask of Anarchy:

"I met murder on the way -
He had a mask like Castlereagh -
Very smooth he looked, yet grim;
Seven bloodhounds followed him

"Finnerty was the editor of the Dublin newspaper the Press and a man of great courage. He was indicted for an article which denounced the actions of Castlereagh, found guilty of sedition, imprisoned for two years and sentenced to stand for an hour in the pillory in Green Street in Dublin. Shelley, then a young undergraduate at Oxford University, was eager to show support for Finnerty. He placed an advertisement in the Oxford Herald announcing the new work, a Poetical Essay, "for assisting to maintain in prison Mr Peter Finnerty", for sale "price two shillings" (The Guardian).

This showed great courage on Shelley's part (though his relations with women may be another matter), and made me think of another great poet who wrote on behalf of Irish suffering, William Butler Yeats. A fragment of Shelley's "Poetical Essay" has made its way into public. It's sharp and rhythmic, certainly, but what I want is meat, when we've been fed only the bone. Regardless, take it away, Shelley.

"Millions to fight compell'd, to fight or die
In mangled heaps on War's red altar lie . . .
When legal murders swell the lists of pride;
When glory's views the titled idiot guide.
* * *
Man must assert his native rights, must say
We take from Monarchs' hand the granted sway;
Oppressive law no more shall power retain,
Peace, love, and concord, once shall rule again,
And heal the anguish of a suffering world;
Then, then shall things which now confusedly hurled,
Seem Chaos, be resolved to order's sway,
And error's night be turned to virtue's day."


Bibliography

Alberge, Dalya. "Byron's lover takes revenge from beyond the grave." The Guardian, March 27, 2010. Web. http://www.theguardian.com/books/2010/mar/28/byron-and-shelley-were-monsters

O'Brien, Paul. "Prophet of the revolution." The Guardian, July 14, 2006. Web. http://www.theguardian.com/books/2006/jul/14/poetry.comment

Rosen, Michael. "Owning manuscripts is one thing: owning the contents is quite another." The Guardian, July 23, 2010. Web. http://www.theguardian.com/books/booksblog/2010/jul/23/owning-manuscripts-owning-contents

Dotnet-Interviews