Telltale’s The Walking Dead Season 2

I just finished episode five of (the game) The Walking Dead Season 2, and while it was definitely a really good experience, I have definitely come out of it less happy than I did out of season 1.

I’m sure part of that is just expectations and being a sequel. It’s hard to do right. That said, I feel that they went the right direction with it, and I enjoyed it on the whole. This episode, however, I felt constantly frustrated by the lack of options availible to me.

It’s a constant problem for these kinds of games - the reality is that producing branching storylines is incredibly expensive - event a few trivial branches means having to produce a stupidly large amount of content, that a good portion of your players will only see a small fraction of. Telltale’s games have therefore always been about creating the feel of agency over what is going on, rather than necessarily giving you the opportunity to change the story massively. The plot will always go A to B, and the changes will be mostly cosmetic. That’s fine, it’s the only viable way to do these things.

The issue comes that they simply didn’t (for me at least), get that right this time. I was constantly watching the conversation scroll by, unable to do anything where it was obvious I (as Clementine) should act. I was constantly not given the choices I wanted to make.

It’s common for these kinds of games to suffer from choices lacking nuance or not allow you to progress the way you want. This breaks immersion and leaves you frustrated. Telltale have been really good at making the options work, at making the plot feel as though you were driving it, and that really fell apart for me in this episode.

It’s disappointing, and I think it all stems from the root of the plot they set out to make - the idea of season 2 was that you would evolve Clementine as you went, that she would be the person you made her through your choices,  building on Lee’s mentorship in the previous series. This rang hollow when the options were simply not there, where it didn’t really matter. As much as I loved the idea, it may well have made a satisfying ending to the series impossible.

The game is still a good one, and I enjoyed it overall, but - as with Mass Effect 3 - this was a bittersweet ending for me. It simply didn’t hold me in the same way as the first season. Instead of being completely in the role and feeling the situation, my immersion was broken and I was annoyed that none of the options availible to me were ones that expressed what I wanted Clementine to be in that situation.

Games like this that are built around immersion have to be incredibly careful with how they construct themselves, at every point. It feels like Telltale missed the mark here.

We don’t need no (low-level) education.

Every now and then, when talking about teaching children computer science, someone comes out with something like:

All these kids today just learning Java, when I was learning we had to learn pointers and assembly. They need to teach them the low-level stuff!

This is a terrible, damaging argument. We are on the cusp of moving CompSci into the core education for students at a young age, and this is great, but it’ll mean nothing if we teach it the wrong way.

Firstly, the idea that you need to understand the low level to be a good programmer these days is simply untrue. We have got a plethora of high-level languages that are extremely effective and used widely. Modern C compilers are more efficient than a human could ever hope to be in assembly. Modern garbage collectors (not to mention the amount of memory in modern machines) make manual memory management worthless most of the time.

This all said, let’s assume we live in a world where you needed to know this stuff to be good. Even today we have reasons we want to know it all - if you want to make compilers, it’s probably worth knowing. The high-level languages are (complex) abstractions, and if we invoke Joel Spolsky’s ‘Law of Leaky Abstractions’:

All non-trivial abstractions, to some degree, are leaky.

we can say that sometimes we will need to understand what’s going on below the hood.

The idea that we should be starting by teaching the low level is a fast track to putting people off computer science. Sure, I found that stuff really interesting, and ate it up - but I was already hooked on CompSci. The aim of educating at a younger age is to give children an interest in it. If we begin with this stuff, they will zone out and think it’s boring.

If you were in charge of getting children interested in chemistry, would you begin by teaching them what a Mole is, or by showing them something that explodes?

Teach a child something high-level, and let them see results as soon as possible. If they can start seeing what they can do, they can start caring - and at that point, it’s easy. If a child finds something interesting, you’ll struggle to stop them learning about it.

Once they have learnt the basics at a high level, you can go back and say ‘well actually, what we said about X isn’t strictly true, you see, it works like this, so actually Y’. Just like that moment where your maths teacher revealed that complex numbers exist. That kind of discover comes with time, as it’s needed, and as they want to discover it.

When someone loves something, they seek out a depth of knowledge. If you teach them the high-level basics, not only to they get some knowledge they can actually use day-to-day, but they might get inspired to go and get the depth later.

Abstractions are our friend, they help us inspire by showing the power of what we are teaching before revealing the huge amount of knowledge required to master it. It takes the task from daunting and a huge investment in time before seeing any pay-off to being interesting and simple to begin with.

Let’s do it right, let’s give all these children a chance to discover a love for CompSci.

JavaDocs are not documentation.

Of course, my heading is sensationalist and strictly untrue - but it is true that the standard JavaDoc you see is barely worthy of the name ‘documentation’.

Documentation is hard and expensive to do right. Wriitng good documentation can often be harder than writing code, and it’s not something most programmers relish. However, we know it’s worthwhile. Good documentation makes code usable (for APIs), penatrable (for applications) and better (for all) - documenting your code forces you to think over it’s design, just as explaining it to someone in real life does.

I don’t think I need to say more to convince anyone good documentation is a good idea, so the question becomes what is good documentation?

The point I want to make with this post is that good documentation is not what JavaDocs supply. Let’s take a look at a JavaDoc:

image

This is for SAXParser - one of the most popular ways of parsing XML in the Java standard library. Can you, from that page, parse some XML? I definitely couldn’t - it’s straight off to find a tutorial or more documentation. In this case, there is some more official documentation from oracle.

This is terrible. Having documentation split like this is a sin that makes JavaDocs worse than no documentation so much of the time. To make good documentation this way, you need to:

  • Ensure your broad documentation is versioned the same way as your JavaDocs, and make it easy to swap between versions.
  • Ensure your broad documentation links to your API docs, and vice versa.
  • Encourage people to actually read both documents.
  • Actually write both documents.

Oracle manages to produce both documents, but that’s it. Most third party code I’ve seen does none. They publish their JavaDocs and call it documentation. It’s not. Alone, JavaDocs are just a convinent way to read through the definitions of the source code.

Some people try and shove all the detail of the broad documentation into their JavaDocs - this is almost as bad - it results in an unreadable heap, and bloats your source code - no doubt causing developers to fold comments away and never read them.

Good documentation needs to be curated, and needs to have two components - documentation from code structure and comments, and the broad documentation.

The idea of only producing reference documentation, and not broader documentation is like testing only with unit tests - it completely misses an entire dimension. For anything non-trivial (and hence, anything worth documenting) 'x takes y and gives z' is useless.

So what is the answer? Personally, I have found the tool that does the job right is Sphinx. Sphinx allows exactly what I’ve mentioned above - curated and automatically generated documentation existing side-by-side.

image

(Surprise, surprise, I think Python did it right)

Sphinx is used for Python’s documentation, and it shows why it’s infinitely better. The documentation explains how to use the code first, then goes into the fine detail of reference (with more curated content mixed in where needed). This produces what I have found to be the best standard library documentation of any language.

And, if you look at Python projects, they tend to follow suit. The ecosystem is full of really well documented libraries and applications - while the Java standard is a JavaDoc with trivial comments at best. The damage JavaDoc has done to the Java community is huge in the way it has encouraged developers to let documentation fester.

Look closely and notice the stuff that makes your life easier - inherantly you are encouraged to link through your documentation, the whole thing is versioned together, it’s virtually impossible to miss the broad documentation or the reference documentation - when you go in looking at one, you inherently see the other.

Do documentation right. I’m not saying you have to use sphinx (although it does support other languages, and will make your life easier), but just make sure to cover the bases. Ensure your broad documentation has the same status as your reference documentation. One without the other will hurt you more than you realise.

I also highly recommend checking out Read the Docs, an awesome site that hosts documentation for projects, all built around sphinx - it’s a great way to get your documentation somewhere easy to find and use, and it’s a great example - click through a few projects on there and see how much better, on average, curated documentation is.

Gone Home

Gone Home is one of a new breed of games that doesn’t let the pressure to have ‘game-like’ elements in order to be an interactive experience. Like Dear Esther, Gone Home doesn’t involve much in the way of gameplay, exactly (although more than the afformentioned Dear Esther).

Gone home subverted my expectations, and kept me interested as I went along. It has some nice little bits of humour mixed into some serious and powerful subject matter. It manages to keep a strong tone the whole way through. It’s not too long - I clocked in at around 100 minutes for my first playthrough. There isn’t likely to be much replay value, although I’ll probably do a runthrough in the commentary mode, and maybe in the future I’ll run through it again, like re-reading a good book.

I’d highly recommend it if you don’t mind a slower pace and lack of gameplay. If you liked Dear Esther, definitely give it a go. If you found Dear Esther too slow or the plot not gripping enough, I think Gone Home does better on both those fronts, and is more likely to be enjoyable to more people.

On Evolution

I am an atheist - and it’s important to me. Not in the way a religion is important to someone religious, but more because it bugs me that atheism isn’t just the norm. It’s weird. I imagine the feeling is similar to how someone would feel if they were to go back to a time where racism or sexism was accepted - it’s just so obviously wrong that it would feel crazy that it was normal behaviour.

Every now and then, I see something and it bugs me, because it doesn’t make sense. I’m not going to try and tackle the existence of a God here - there are a huge number of bases you have to cover. What I am going to try and cover is the idea that evolution is somehow ‘wrong’. Of course, evolution and religion are not mutually exclusive - but some people still think that is the case, and they “don’t believe in evolution”.

The reason that this is so unbelievable to me is that evolution is completely provable. I think one of the core issues of understanding is that people hear evolution and think of monkeys turning into humans.

Evolution is a process. You can see evolution works right now. Let’s begin by asking what a process is - and the easiest way to do that is to give an example. Erosion is a process. Imagine a canyon. If I were to say that the canyon exists because of water running over land and removing rock and soil until the canyon was formed, no one would debate that fact. It’s obvious that the process works - take a hose and try it - you’ll quickly see that it works. Anywhere you have that scenario, erosion will happen.

Evolution is the same thing. Take a collection of items that reproduce with slight random variations, and somehow make the ‘better’ items by any criteria reproduce more effectively, and the items will trend towards being better. That is a process that is guaranteed to happen. We can simulate this - write a program (hell, paper and dice would even work) that runs this process, and you will see it happen. Genetic algorithms are used a lot now, and they rely on the fact this process works given enough time. Likewise, ask a farmer if selective breeding is true - of course it is, it’s a cornerstone of modern agriculture.

We know that animals reproduce. We know they have DNA which varies randomly in offspring. We know that the world ‘selects’ creatures that are better at surviving. The conditions for evolution are met, and so the process occurs. Suggesting it doesn’t is like suggesting the river definitely didn’t form that canyon.

Evolution is fact - it’s a process with only one logical and provable outcome, and all the requirements for the process occur in life.