A big MisCALculation

The theme for this week's CompSoc social was esolangs, which gave me the opportunity to do something that I've been meaning to do for a few years now: write a program in INTERCAL.

INTERCAL is designed on the basis that a person whose work is incomprehensible is held in high esteem. The sort of work where you're boss appears, asks what you are doing, and then nods slowly whilst going "uh huh".

So Toby and I set about making a program which would print out the CompSoc logo using Os and Xs:

OXOX  
XXXO  
OXOO  
OXXO

Seems easy, right? 

How printing in INTERCAL works

Intercal processes input on a cyclical tape that has one cell representing each of the 256 extended ASCII characters. The tape head begins at zero when the program starts, and can only move left.

This is relevant because output characters can be thought of occupying the reverse of this tape. That is to say that that the output head (which is thankfully seperate from the input head) can only move to the left in descending order of charcter codes (so from Z back to A). The task of printing characters thus becomes the task of describing the movements of the output head along the tape.

This isn't too bad until you realise that because the output head moves from right to left, it reads the binary of the characters it encounters from most significant bit to least significant bit. If the head is moved to position 108, presumably because the user was attempting to print an 'l', the output head will read the binary representation of 'l' backwards. In this way 0110 1100 becomes 0011 0110, which is in fact '6'. As you might imagine, this quickly becomes confusing! Printing subsequent characters will need to take into account that the head is now starting from an offset of 108 instead of 0.

Annotated snippets

1. DO ,1 <- #20 
Each line of INTERCAL must start with either PLEASE, DO, or PLEASE DO. These can be used interchangably in order to improve program aesthetics. It is worth noting that a program which is too impolite will not compile. This line allocates the array that we are going to use to hold the program output, and assigns it a length of 20.

2. PLEASE DO ,1 SUB #1 <- #14
Set the first subindex (SUB) of the array to 14. This represents a shift of 14 places to the left of the zero starting index of the output tape, which is ASCII character 242 (256-14), which is 1111 0010 (‗). This is read as 0100 1111, which is character 79, which is the 'O' that we want. Be careful not to use PLEASE too liberally, as the compiler will refuse to compile any overly polite programs as it gets suspicious.

3. DO ,1 SUB #2 <- #216
The next character of the output needs to be X, which is charcter 0101 1000 (88). This means we need to move to character 0001 1010 (26), which is the substitute character (␚). Because the output head is already at character 242 the offset we need is thus 242-26 which is 216 (remember that we can only move the head to the left).

...

4. PLEASE READ OUT ,1
Next we have the program read out the contents of the array by making the output head follow the pattern we stored in the array.

5. PLEASE GIVE UP
Then the program gives up. At this point, I suggest you do too.

Check out the code on Github.

Hellblade: Senua's Sacrifice

Hellblade: Senua's Sacrifice is a deeply unsettling exploration of psychosis, grief, and death. Self-published by Ninja Theory, who have previously released Devil May Cry, Enslaved, and Heavenly Sword, the game is part of a wider effort by the studio to champion "independent AAA" games.

Not played the game before? Here is my advice:

1. Don't play unless you can play with headphones. They really make the game the experience that it is, and you can only experience it for the first time once.
2. Make sure you aren't distracted while playing. At first I was being interrupted by pings and buzzes from my phone and the GOG overlay, and it really drags you out of the experience.
3. Stop reading articles about Hellblade :P Seriously, the game will be better the less you know in advance.

With that said, here's the rest of the article :D

I. Visuals

The first thing that hits you when you start playing Hellblade is that this game is a looker. For reference, all of the pictures in this post are screenshots I took. Ninja theory evidently noticed this too, as the game comes with an in-depth photo mode that lets you pause the action and line up screenshots. The attention to detail on Senua is astonishing, and is backed up by an impressive performance by Melina Juergens (even though the script doesn't require her to exhibit a huge range).

Senua's Sacrifice makes great use of filters layered over the top of the game. They take the already dark world and twist it into a true hellscape. The more intense sections of the story, such as escaping from the beast, are characterised by smothering overlays that lead to a disorienting sensory overload.

One thing that I did notice while I was playing Hellblade was that occasionally the animation would dip down into the uncanny valley. Particularly in the earlier sections of the game Senua's eyes would take on a distinctly inhuman look, but this is something that goes away as the story progresses. Occasionally I also had issues where the camera would clip through walls (particularly on spiral staircases), and the detailing on objects like torches is jarringly low-res. All little niggles, but they stand out when the other visual work is near perfect.

II. Audio

But to build the atmosphere required for a story such as Hellblade's, you need more than an environment that just looks oppressive. The game makes use of binaural audio to make it feel like the voices that haunt Senua's existence are in your head too (the furies). They accompany you throughout the game, and are fickle companions. Sure, sometimes they encourage you. They tell you that you're strong enough and that you can get through the trials ahead. But those same voices will quickly shift to messages of despair and hopelessness. More than a few times I started to second guess myself as I was trying to solve puzzles, the furies telling me that I was going the wrong way. That I was being too slow. That I couldn't see the obvious solution.

Ninja Theory have also done something really clever here to bring the uneasiness levels to something unlike any other game I've played. Everything from the soft pops of the whispering voices to the pitter-patter of rain and crackling of fire is an ASMR trigger. The reason why you feel like your spine is tingling in Hellblade is because it actually is. The game made my skin crawl in a way that was overwhelming at points, and makes the game draining and emotionally exhausting in a way that's rare for AAA action games. That and the flawless voice acting in this game really draws you in to the experience - the cast deserve credit for a job well done.

The game takes several opportunities to play with sensory deprivation. There is a section during the game where Senua is effectively blind, and has to use sound to navigate, and another where making noise is what attracts the attention of the monsters. These both work really well because of the tight audio, and are all the more fraught because you're only afforded hazy outlines of what's lurking in the dark. By forcing you to make use of previously ignored audio cues the game puts a new spin on familiar environments and mechanics.

III. Gameplay

Gameplay falls broadly into two categories: combat and puzzle solving. The former feels a little out of place, not really serving any narrative purpose except to reinforce Senua's identity as a warrior. But it's what Ninja Theory are good at, and fights have a weight to them that is both very satisfying and somewhat grotesque. The focus mechanic helps to break things up during combat, and partners well with the adaptive difficulty to make sure that fighting feels fraught but not impossible. As an aside, I really like the idea of the game altering the difficulty level behind the scenes - much closer to Left 4 Dead's AI director than Modern Warfare's condescending prompts that suggest you're not part of the intended audience of the game.

Puzzle solving is centred around the fact that Senua sees the world differently, and is strongly tied in to the overarching narrative surrounding her psychosis. This was always going to be a tricky one to get right - make it too easy and it feels throwaway and token, but make it too hard and you risk drawing people out of the immersion as they traipse back and forth looking for an obscure clue. Overall I felt that the puzzles were pitched about right; the visual overlays and level design made it clear where you needed to be to progress, but stopped short of giving you any information on how to actually find a solution.

The gameplay also portrays a more nuanced view of Senua's physical capabilities. Unlike the protagonists of similar games she's strong but not bulky, and panics a little the first times she has to negotiate a high beam in a way that gave me a little bit of vertigo. Plus, when Senua is hurt in combat, this is reflected in the gameplay mechanics. She can't move as fast, and the player has to adapt how they play in order to beat what are more dangerous foes now that she can't dodge and parry at her usual pace.

IV. Story

The story takes a while to become interesting. I guess this isn't so bad, as you spend the first few levels getting the hang of the mechanics and settling into the world, but it would have been nicer to have felt a bit more involved during the earlier sections. Put another way, I felt like was watching Senua's story for a while before I really began playing it. The shift probably occurs when the game stops recounting episodes from the past and begins focusing on the Senua of the present.

The second half of the game builds on the paranoia and uncertainty that Senua experiences as a result of events from her past. Characters and voices shift as the story progresses, leaving you in a world where what's true begins to stop mattering as you discover that real, physical threats make up the minority of the dangers you have to face. As mentioned above, Senua's condition is presented as something that makes her see the world differently, and forces you to capitalise on this in order to make progress. Having to rely on this hazy view of reality only feeds the sense of paranoia built by the narrative.

The game plays with this by telling you during the first few levels that every time you fail, the dark rot will spread up Senua's arm until eventually it will reach her head and consume her. The threat of permadeath hangs over you during the game and adds to the general anxiety induced by the atmosphere and the furies. But there is no permadeath. You become paranoid after believing something the game told you which isn't true. It's a startling way of getting players into Senua's mindset, and helps you to understand that what she's experiencing is real for her in a way that is hard to do for psychotic hallucinations where you know that something is imagined.

To wrap up, this game is something special (it reminds me a lot of Spec Ops: The Line in the way the story plays out). Easily one of the most unsettling experiences I've had in a while, and I hope that future horror experiences take note of the more novel techniques used in Hellblade. It's also really exciting to see a mainstream game tackle the portrayal of a mental health condition well. Senua's psychosis is not the sole thing that defines her: in her own words, she has other stories to tell.

Cyber catastrophe - like a normal catastrophe, but with more cyber?

Last week I was in one of three Oxford teams which traveled to the Geneva Center for Security Policy last week to take part in a cyber policy competition against 21 other teams from around the world. Each team was sent an intelligence brief before the competition, from which they had to prepare a briefing outlining their policy suggestions to an assembled task force. The exercise was an attempt to simulate challenges that face decision makers during a crisis. The competition was tough, with colonels and diplomats heading up teams from military academies and schools of governance and policy. After seeing how seriously the other teams were, our own delegation (coached by the first professor we could grab on the afternoon of the deadline) seemed lackluster in comparison.

After each presentation, teams had to answer questions from the judges before being scored for the round. Two of our teams managed to rank high enough and made it through to the second round on day two, whilst the third was left to enjoy Geneva in the sunshine. While they were catching up on sleep, the advancing teams were given a new briefing at 20:00, asked to prepare a new presentation. The catch was that instead of having two weeks to prepare a new briefing, this time we had until 07:00 the next morning. Cue a long night trying to prepare a set of policy alternatives that would get us through to the final on Friday afternoon. 

Unfortunately neither of the qualifying Oxford teams made it through to the final, which was eventually won by the home team from the Geneva Center for Security Policy. One thing that we we missing was a strong media strategy across the board. As one of the judges rightly pointed out - media isn't optional in a crisis situation. Secondly, teamwork is key; teams going into Cyber 9/12 that hadn't worked together before were at a serious disadvantage when the going got tough. Another strategy the winning teams employed was drawing a clear line between policies which considered the unfolding events a criminal incident, and those that escalated it to a matter of national security.

Overall the event was really insightful, and I'm glad I made the most of the opportunities I had around the presentations and keynotes to ask the assembled experts how best to become more involved in the policy sphere. We'll be back in Geneva next year for certain, and maybe then we can bring the trophy home to Oxford.

Competitive Securiwhat?

Competitive Security - apparently that's a thing. Otherwise known as Capture the Flag (CTF), these events pit teams against each other in an attempt to compromise systems and solve challenges. After taking part in a few, here are some observations I've made.

1) Being comfortable with Linux is half the battle

The problems that you have to solve during a CTF will be hard, and the last thing you want interrupting your thought process is five minutes of fumbling while you try and remember how to compile something with GCC. This is something that comes with practice, so make sure you spend some time after each event going over the things that you were embarrassed you couldn't do! Using Linux on a daily or semi-regular basis is the best way to proactively build up these skills outside of competitions; you'll find that over time the number of non-standard tasks you need to do builds up until eventually you'll be navigating the command line with more confidence.

2) Competitions are not the place to learn new skills

They're great places to highlight the things you need to work on, and you will pick up tips and tricks, but it's unreasonable to expect to come away from an event knowing how to use a tool or technique that you didn't know when you arrived that morning. One way to mitigate this is to corner people you want to learn from during breaks or after the close of play. This way you can still make use of them as teachers without it getting in the way of what you're there for - the competition. As above, make a note of what you struggled with so you can get some practice before the next event, and don't start googling C++ hello world tutorials or asking the network guru about WiFi frequency bands when there are puzzles to solve.

3) The 10X factor

Excusing the slightly cheesy name given to it by a company I interned for, this refers to the idea that it's normally better to sacrifice some of your own productivity in order to keep your team working at full efficiency. Everyone in the team should be roughly aware of what each member is working on - if people are starting to drift, call a huddle or go around and get everyone up to speed. If you don't you'll just end up wasting effort when you forget to tell the network specialist that you also connected to the VPN and they end up spending half an hour defending your operation from this new adversary who's running Kali. Doubling up and working in pairs can help to reduce typos and silly gotchas, but more than two people round a keyboard can end up with the situation where everyone thinks someone else is paying attention. 

I feel like there should be something here about having fun, but that's probably unnecessary...

Gaze into the IRIS

After playing around with/doing research with a pair of the department's quadcopters as part of my masters dissertation, getting my own drone seemed like a good idea. The problem is that commercially available drones cost a lot of money - the low spec Parrot AR 2.0 model that Warwick lent us costs about £200 (and was even more at the time it was released). There is an alternative though, which is to make your own!

Step one was creating the frame. I found a set of designs for the IRIS+ by 3D robotics and sent one copy of each component to the Radcliffe Science Library (RSL) here at Oxford, and 24 hours of printing later (5 days real time) the first parts were ready. It took another 13 hours before the whole frame was ready, but the whole shell only cost £47. The only problem with this approach is that there's no component list to go with the IRIS; the only thing you have to go on is general advice and a list of suggestions from the MiniFactory comments.

3D printers work by extruding a small stream of plastic about 0.1mm thick, in layers that get built up over time. The plastic used here was polylactic acid, refered to as PLA, which melts at around 200 degrees and is biodegradable. Annoyingly, this method of layering up from the base of the printer means that printing curved or otherwise non-flat surfaces is difficult. One way to solve the problem (and the method that the RSL use) is to print a flat surface anyway and then layer supports up to the point where you actually want to print. On a smaller model this isn't so bad, but removing all of this excess material from the drone case was an arduous task. In an improvement from my previous rockets project, recourse to plasters was only required once!

Normally hidden from consumers, the inner workings of the average quadcopter are quite interesting. To be able to hover in mid air, opposite pairs of rotors must spin in the same direction, with adjacent rotors rotating in contrary directions. But while this makes hovering easy, it makes turning harder - increasing power to the clockwise motors will turn the drone in one direction, and vice versa for the counter clockwise motors. Banking and moving is achieved in a similar fashion but with adjacent motors instead of opposite ones.

Things get even more involved when you move to actual electronics. Each of the four motors must be connected to an electronic speed control (ESC) unit which is responsible for using a low power control signal to alter the speed of the motors using larger currents. This type of setup would normally require two separate batteries, which is not ideal when every gram counts. Battery eliminator circuits (BEC) solve this problem by allowing one power input from the battery to power both low voltage control and high voltage motor circuits, as well as prioritising control circuits in the event of power loss. The last thing you want when the battery goes is complete loss of control! In practise, most ESC units have built in BECs.

Next we get to the brains of the operation: the flight controller. This component is responsible for turning high level commands from the remote control into voltage changes at the ESCs. The controller also has to keep the aircraft stable through gusts of wind and other types of tilt by making slight adjustments to the motor speeds (informed by its gyroscope and accelerometers). Eventually I'd like to write my own flight controller, but making high frequency real time adjustments on what would probably end up being a Raspberry Pi is tricky. For now I'm sticking to something that's more likely to work first time.

The goal with the build was to make everything as modular as possible so that it would be possible to swap out components in the future, either for upgrades or to reuse kit in other builds. Coming in part two: putting the frame and electronics together!

The First Thinkpad

On holiday recently I had the opportunity to take a look around some of the places in the bay area which have played key roles in the history of computing. Despite the fact that most of the developments when it comes to what we now consider 'the computer' have happened in the last 100 years, scientists and inventors have been making progress in the field for over two millennia.

As with most fields, most of the advancements beyond the few well known breakthroughs remain confined to the realms of obscurity. Now that I've committed to computer science as a pursuit, it was fascinating to be able to look into the past and be inspired by the pioneers who paved the way for the technology of today.

One of the things that stood out for me was one of the original think pads in the Computer History Museum. So many times, someone made a decision or said something that went on to be far more popular or influential than could ever have been imagined. What started out as a prompt on a notebook now adorns millions of laptops worldwide. Email is another prime example of something growing out of all proportion (for better or for worse).

Anyway, there's not much more to show - otherwise this just becomes holiday snaps of a museum. Just remember that beyond being interesting, history can be a valuable guide when forging something new. Although a bit hackneyed, the well known George Santayana quote still applies:

Those who cannot remember the past are condemned to repeat it

A font of knowledge

One of the projects which I had lined up for the lull after exams were over was to make a font. It's nice to go behind the scenes of something that everyone takes for granted, and unless someone somewhere has done a really bad job, never notices. Typography is important though, having an impact on how easy a text is to read, as well as shaping the way in which we think about what we're reading. The font that I'm creating has more of a script/handwritten style than the more commonly used ones, but it seemed like an easier starting point for a beginner.

The main tool involved for this project was FontForge, a free and open source font editor. At a basic level, the task is simple - create a glyph for each letter - right? The first thing that becomes apparent is that this means drawing a lot of glyphs. Obvious though it may seem, I hadn't done the calculation beforehand: 26 lower case, 26 upper case, 10 numerals, and about 30 bits of punctuation. So before you even consider multilingual support (another 10 or so marks and 50 anchor points) you need to create around 90 characters. And the second realisation follows the first, as soon as you get down to drawing your first letter - there's a lot to think about beyond just the shape of the letter.

Because each glyph is composed of a series of lines and Bezier curves (curves which are defined by two endpoints and a polynomial equation), you need to take the picture of the letterform in your head and replicate it in FontForge. So far so good, but what about serifs (the small lines attached to the ends of lines in some fonts), and the weight of each part of the letter? Many letters which appear to be equally weighted, such as the vertical and horizontal bars in a capital H, are not, because the letters look odd to the eye when balanced. Similarly with positioning. The dot of a lowercase i is slightly off-centre to offset the serif on the top of the stem (obviously not the case in a sans-serif font!)

Then we come to proportions and spacing. The shape and size of most of the letter shapes is often derived from others with similar forms. For example, the glyph for b is created from the stem of the i character combined with the bowl of the o character, and the shape and slant of the e also comes from that of the o. These relationships are key to making a font seem coherent, so that all of the characters feel like they have come from the same font. On a similar note, the feel is always more important here than precise values. Having characters which are not exactly symmetrical or evenly weighted will often look more pleasing to the eye than their mathematically perfect counterparts. Next, we have spacing. The letters above are equally spaced, and you can see that it looks off. The size and weight of the different glyphs has a lot to do with how close together they should be, as well as how symmetrical they are (An o will often have more balanced left and right spaces than an h, for instance). One can also 'kern' pairs of letters (or sets of letters) to make more precise adjustments to the spacing. This can often be seen after capital letters, such as where the a in Ta is adjusted to fit under the horizontal stroke of the T.

As with any project like this, there are endless tweaks and adjustments that you feel you need to make, and calling a font done is something you rarely feel happy doing. At some point I'll come back and finish off the more obscure punctuation glyphs and add some ligatures, but that's for another post!