Anna and the Bunches

In my last post, I re-implemented all of my rendering code to take advantage of Shaders. After doing this, nothing rendered. Despite the fact that I was following a tutorial, more or less. I have been modifying it to fit my project, which has a lot of code around the rendering code already and is in C++ instead of C, and also modifying it to do something that will actually be useful for me down the line.

But, at any rate, I’ve checked every function call I make against the ones used in the tutorial. They all match. Everything is exactly the sa…

Oh. Wait.

One of the things you create when using shaders is an index buffer (also called an element buffer); a list of what order the vertices of your polygon should be drawn in. From the tutorial:

[sourcecode lang=“cpp” gutter=“false”]
static const GLushort g_element_buffer_data[] = { 0, 1, 2, 3 };
[/sourcecode]

And the equivalent line from my code:

[sourcecode lang=“cpp” gutter=“false”]
GLfloat Renderer::rect_elements[] = {0, 1, 2, 3};
[/sourcecode]

I got so used to things being GLfloat type that I made my index buffer floats, even though that doesn’t make any sense (you can’t have vertex number 0.5, after all). Not only does it not make sense, OpenGL requires that the element buffer be composed of integers. Even better, if your element buffer is of the wrong type, OpenGL fails silently: no error message, no crash. The rendering simply doesn’t happen.

So, a couple hours of debugging, down to one simple line of code. I really wish GLSL had a way to report meaningful errors back to the program using it. At any rate, after I fix the line:



I’m back to where I was several days ago. But this time, I’m using shaders, which are both less deprecated and more flexible; I’ve set up a framework that will allow me to do more interesting things later on.

Now, on to the next challenge: rendering text. In SDL this was fairly easy; the SDL_ttf library made it pretty simple to render text to the screen. In OpenGL, however, rendering text is a bit trickier. There are a few libraries out there that do it (FTGL seemingly the best option), but they all use the fixed-pipeline functions. I’d even be willing to settle for that, and worry about ripping the code out later and putting in something more shader-friendly, except switching back and forth between Shaders and the fixed pipeline seems to be a bit tricky.

So, my options are:

1. Figure out how to switch ‘out’ of the Shading pipeline properly and render text with FTGL, or


2. Use freetype2 directly and implement my own font loading, render the text to a Framebuffer Object, then blit that to the backbuffer (the buffer that represents the next visual frame).

The first option might be easier in the short term, but the latter sounds more robust, all things considered. The problem is that stopping to get font rendering working without any deprecated functions could take quite a while (I’m not even sure on a good estimate for the time). So, I hack FTGL into working and move on.

Now, I’m ready to get things back to the way they looked before I decided GLSL was something that needed to happen. I just need to figure out the best way to draw a circle with GLSL…

Puzzling - that is, solving puzzles recreationally - is a hobby of mine. I enjoy it immensely, although I enjoy some puzzles much more than others. I enjoy the sorts of puzzles that involve both intuitive leaps and a combination of generalized and specialized knowledge. The sorts of puzzles that happen at the MIT Mystery Hunt are probably the best examples of puzzles I really enjoy (and, indeed, I had a lot of fun at my first Puzzle Hunt this year).

So, in the tradition of Solving Really Hard Puzzles, I’ve decided to post logs of some of my puzzling efforts here. These may only be of interest to a very few people; feel free to ignore them if this is not up your alley.

Today’s puzzle is one that Dante Shepherd posted on twitter in this tweet. Puzzles that are simply an encoded string of characters always intrigue me, so I dived right in. It took me about half an hour to solve, and it was a lot of fun. I created a log of the process by simply periodically noting the time and writing down my thoughts, especially when I got somewhere new, such as the aha moment at 15:00. In the future, I may look for (or create) some software that will make logging a bit easier.

Also, here is the original puzzle, for the link-averse:

L 45, R 270 L 225, R 270 L 225, R 180, L 90, R 270 L 225, R 270 L 90, R 225 L 90, R 270 L 225, R 225 L 135.

Spoiler Warning: if you want to solve this puzzle yourself, don’t read my log. It contains spoilers for the intuitive leaps as well as the solution.

14:45
Okay, puzzle is gridded. What do we have here? These are obviously rotations; L and R for ’left’ and ‘right’, and the numbers are all < 360.

14:50
Oh, they’re all multiples of 45 degrees. So, they’re all nice, even angles, and they are paired off.

15:00
Aha! It’s Semaphore. For the two that are missing part of the pair, I’m assuming the angle is 0. Let me just look up a semaphore chart…

15:01
Oh crap. Is 0 at the top or bottom? Is L the sender’s left or the receiver’s left? Now I have to work out the coordinate system Dante used. At least we know that the low numbers map to the L side, and the high numbers map to the R side.

15:10
Tried 3 coordinate systems - 0 at top with L == left arm, 0 at top with L == viewer’s left, and 0 == right, coordinates going counter-clockwise (trig coordinates). All that’s left for reasonable systems is 0 on the bottom.

15:13
And solved. The solution is GOODFORYOU. It was the last coordinate system I tried, of course - moved 0 to the bottom, but got L and R backwards the first try.

So, I was playing around with the ‘sparks’ feature on Google+. Since I’ve been working with OpenGL lately, I made a spark for it. On that spark, I came across this thread, which gave me this advice:

A general rule of thumb is that if a tutorial contains calls to glBegin, glEnd and/or any of the glTexEnv functions then it’s old and you should avoid it.

Now, I wouldn’t generally trust a single person on the Internet with nothing to recommend them, but I’m seeing this advice repeated in several places now that I know to look.

So, all the tutorials I’ve been working with are for very, very old versions of the OpenGL spec, and the functions I’m calling are pretty deprecated; I’ve been learning obsolete tools. To that end, I recommend anyone following this series not use my last post as a jumping-off point for working with OpenGL, or at least know what you’re getting into. Those functions and methods still work, but they’ve been deprecated and eventually graphics cards will probably stop shipping with support for them.

Instead, I found some more modern tutorials and documentation. Luckily, I’m not terribly invested in the way I’m doing things yet; I have maybe 100 lines of OpenGL-related code in my project, and the vast majority of it (that is, all the stuff that isn’t needed for initialization and gamestate changes) is factored into a single file. It should be pretty straightforward to replace it with something better, once I’ve got a handle on the “new way” of doing things.

This exposes a deeper issue, too. There are several different versions of OpenGL: best denoted by their major version numbers (1-4). The most current iterations of each are OpenGL 1.5, 2.1, 3.3, and 4.0. There seem to be tutorials available for all of them. Now, there’s a tradeoff to using one version of OpenGL over the other; newer versions will have less support from other libraries (Linux doesn’t even seem to have OpenGL 3 headers yet). On the other hand, older versions will eventually be deprecated and phased out. Newer versions can also do things older versions couldn’t, although right now I’d be happy just learning the basics.

So, after looking around on the web for a while, I settled on learning OpenGL 2.1 (and the corresponding GLSL 1.2, which we’ll talk about in a moment), while avoiding all of the functions in OpenGL 2 that are deprecated in OpenGL 3. This is the approach that Joe takes in this tutorial series, so what I’m learning will line up well with at least one tutorial on the web. It is also nice because this version is well supported in Linux, while OpenGL 3 support (especially in SDL) is still under development.

Now, there is a huge change between OpenGL 1 and 2. A change so massive that the difference between 1 and 2 dwarfs the differences between 2 and later versions. This change is the move from having a “fixed-function graphics pipeline” to using GLSL, the OpenGL Shader Language. So, what does this mean? Well, in OpenGL 1.5, you tell the graphics card what you want to draw, and some parameters about how you want to draw it, but the details of that process - the functions on the graphics card that handles doing the actual drawing - are hard-coded and unchangeable. With shaders, you get to program those functions yourself, and then your application can send them to the graphics card, compile them, and use them. GLSL is the language the shaders are written in - it looks a lot like C, but it has neat built-in functions for matrix and vector math, and a ton of built-in variables that I haven’t quite worked out yet.

So, I rewrote my rendering engine to use shaders. I followed the tutorial closely, modifying it to fit into my object-oriented C++ code and to fit all the other code I had already painstakingly written. I refactored large sections of my program. This took several hours, during which I couldn’t even compile the program all at once, because so many changes were being made. When I finally got it to compile and run without immediately crashing, this is what I had produced:



I appear to be doing it wrong, as they say around these parts. I have simplified my program so that all it should be doing is displaying a single texture on a simple rectangle. I have no idea what’s wrong here. Is my coordinate system somehow incompatible with my shaders? I don’t think so - I reworked the coordinates to match the tutorial I’ve been using. Are my shaders for drawing a texture simply wrong? Maybe, but there’s not a great way that I can find to get debugging info out of the shaders. Is SDL 1.2 not compatible with GLSL? That’s a decent possibility; testing it will take some time, though.

This is the biggest setback I’ve encountered so far, though, so that’s a pretty good sign. Hopefully, by my next post, we’ll have something better than a black screen to work with.

Over on Shamus Young’s blog, he recently said this when talking about a programming project of his:

One of the things I like about this project is that it is uncluttered by goofy, awkwardly-designed libraries.

Shamus is working on a procedurally-generated 3D world using OpenGL. Now, I know what he means. He is trying to avoid relying on things like graphics and physics engines, or 3D model importers, or any of a number of other tools that often have asinine and byzantine APIs. I am, in fact, trying to do the same thing in my project (in my case, it is because I am using this project to learn graphics programming).

However, I have to object. libgl is a goofy, awkwardly-designed library. Of course, the fact that it that is has to be, in order to do what it does. However, code like this:

[sourcecode language=“cpp” gutter=“false”]
glBegin(GL_QUADS);
glColor3f(r1, g1, b1);
glVertex2i(x1, y1);
glColor3f(r_mid, g_mid, b_mid);
glVertex2i(x2, x1);
glColor3f(r2, g2, b2);
glVertex2i(x2, y2);
glColor3f(r_mid, g_mid, b_mid);
glVertex2i(x1, y2);
glEnd();
[/sourcecode]

is pretty goofy. Anyone with experience writing GUI code using a Windowing toolkit would be appalled to learn that this is how you draw a rectangle. A more reasonable API would let you get a ‘rectangle’ object, then define things like its x/y position, its width and height, colour, etc. Then, you might make a call like:

[sourcecode language=“cpp” gutter=“false”]
window->add(rectangle);
window->update(); // to draw the window
[/sourcecode]

But in OpenGL, we have to tell OpenGL that we want to start drawing a polygon, then tell it the colour and position of each vertex on the polygon, and then tell it when we’re done, all with different function calls. And gods help you if you get them out of order:



What happened here? I told OpenGL to draw a rectangle, and I gave it the top-left vertex first, then the top-right, then the bottom-left, then the bottom-right. This is a pretty obvious way to think about listing the points on a rectangle, right?

Except that OpenGL is designed to actually create the polygon’s bounding box based on the order you list the vertices, like so:



So, OpenGL did exactly what I told it to do; we just weren’t speaking exactly the same language. OpenGL requires that I list the vertices in clockwise (or counter-clockwise) order around the edge of the polygon.

OpenGL is an iceberg, though, and this is just the tip. There are Display Lists, Vertex Buffer Objects, shaders, 3D objects, normal vectors, projection matrices - it is a very complex beast, and all of that complexity is exposed directly to the user. So why does Shamus knock on all those other libraries, but give OpenGL a pass?

The answer is that OpenGL has to be this complicated. The reason? OpenGL lives on the graphics card. This is something that it is easy to miss the ramifications of, but they’re huge - the OpenGL function calls are talking directly to analogous function calls hard-coded in a chip on a piece of hardware. When you call glVertex2i(), you put data about a vertex directly into your video card’s memory. OpenGL is fast; it’s what lets us have advanced graphical environments that change and that we can interact with, rendering in realtime. So, subsequently, OpenGL’s end-user libraries are complicated; they have to be to let you take full advantage of what OpenGL is designed to do.

That doesn’t make it any less goofy, though.

The TreeWars project is a week and a half old (at the time of this writing). It’s come a long way; in its current form, it actually looks pretty neat:



There are now stats, and hit points, and the basic gameplay mechanic is in place. I’ve also laid the groundwork for some more complex gameplay, as well. Of course, I haven’t talked about gameplay all that much yet - we’ll get to that at some point, I’m sure. But what I want to talk about right now is how to write bad code.

Bad code happens. Sometimes, when you’re writing code, you will hit a stumbling block. Encounter a problem where the solution doesn’t jump immediately to mind. And often, you’ll look back on it later and say “what the hell was I thinking?” Well, here is an instructive example of that.

This blunder is actually pretty embarrassing; I really did know better, but that knowledge escaped me at the time. As you’ve probably noticed from the screenshot above, my program deals with drawing circles (called either ’nodes’ or ‘vertices’). If a user clicks to add a new node, my code has to check and see whether it will overlap with an existing node.

So, I had a function that answers the question “is there a node close enough to the point (x,y) that a new node there will overlap?” If you’re good at geometry, you probably already see the right way to do it. But I bet you can’t spot the very very wrong way!

My solution (and I stress that this is a really, really bad idea) was to create a ‘bounding box’ around each existing node, and a bounding box around the area that the new node would occupy, then do some complex logic to see whether the bounding boxes overlap. It looked like this (and if you’re not a programmer, just note the general size and complexity of this code):

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
bool Graph::vertex_present(int x, int y, int size)
{
   int delta = size / 2;
int x_min = x - delta;
int x_max = x + delta;
int y_min = y - delta;
int y_max = y + delta;

for (list<Vertex>::iterator cursor = vertices.begin();
cursor != vertices.end(); cursor++)
{
Vertex v = (cursor);
if (((x_min >= v.x_min && x_min <= v.x_max) &&
((y_min >= v.y_min && y_min <= v.y_max) ||
(y_max >= v.y_min && y_max <= v.y_max))) ||
((x_max >= v.x_min && x_max <= v.x_max) &&
            ((y_min >= v.y_min && y_min <= v.y_max) ||
(y_max >= v.y_min && y_max <= v.y_max))))
{
return true;
}
}
return false;
}
[/sourcecode]

It’s ugly, and hard to read, and I knew it felt like a hack when I wrote it. But at that moment, nothing better was coming to me. Now, for those of you who don’t enjoy recreational geometry, here’s the right way to do it: you know that the existing node is at (x1,y1) and that it has a radius of r1. The point you’re checking is at (x2,y2) and the new node would have a radius of r2. So, all you do is get the distance between the two points (basic geometry, I could have googled “the distance formula” and about 8 billion websites would have popped up to tell me how much I fail here), and then compare that to r1 + r2. Like so:

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
bool vertex_present(int x, int y, int r)
{
for (list<Vertex>::iterator cursor = vertices.begin();
cursor != vertices.end(); cursor++)
{
float dy = y - v->y;
float dx = x - v->x;
if (sqrt(dydy + dx*dx) <= v->;r) return true;
}
return false;
}
[/sourcecode]

See? much simpler.

Now, why did it take me 24 hours to figure that out? Well, I wrote the original code when I was pretty tired, and the nature of programming is that once you write a function and it works, it is easy to forget about it. After I needed to calculate distance somewhere else, though, an alarm went off in my head. “Hey,” said the alarm, “You could have used that over in vertex_present()! What is wrong with you?"

Well, alarm, look. Sometimes I just can’t brain as well as other times. But hey, at least it ended up being nice and pretty in the end, so thanks for that! Actually, vertex_present() doesn’t even exist in my code any more; it was refactored into some other function, because I only actually used it in a single spot.

Luckily, I can go back in time and show you how awful my code used to be through the magic of git, which I use to track all of my programming projects. It lets me periodically ‘commit’ the changes I’ve made to my code, and keeps track of everything I’ve done. I can then ‘checkout’ any commit, instantly reverting my code to an old state, and then ‘checkout’ the latest code again when I’m done. It can do a lot more than that, too. If you write code, I highly recommend using git or another version control system.

So, that’s all for today. Next time, we might even talk a little bit about gameplay! With a little luck, the game will be sophisticated enough by then that there will be something to talk about.

In D&D Post-mortem, I talk about my experiences running D&D 4e games, about 4e as a whole, and about collaborative storytelling in general.


Our most recent D&D session was pretty short - a small amount of cave exploration, and a single encounter. During that encounter, however, a few things happened that highlighted two fundamentally different approaches to roleplaying games. The scenario in question was this: the party’s Wizard wanted to use Mage Hand to disarm an enemy spellcaster. I had several objections to this idea:

1. The enemy spellcaster isn’t likely to give his wand up without a fight. Assuming, for the sake of argument, that we want to make rules for this attempt, it seems reasonable to me that a Mage Hand would have a Str 2, and would have to make an opposed grab roll, with at least a -5 penalty for the act of snatching an object out of the opponent’s grasp.


2. It sets a nasty precedent. If we allow such a simple and repeatable disarm, the game ceases to be challenging. Following this to its logical conclusion, well - the characters’ actions don’t happen in a vacuum. Word of this tactic would get around (indeed, if such a tactic worked, it would likely already be in widespread use). People would start creating defenses against it - locking gloves, magical barriers, whatever. It would necessitate an arms race between the setting and the character that would potentially alter the landscape of my setting in a way that’s not very appealing to me. I’m all for player characters leaving their mark on the world, but I don’t much care for this reactive manner. This would also make enemies with natural weapons fundamentally more useful, which would reduce the amount of variety in encounters. Which, I suspect, isn’t something anyone wants.


3. There simply are no printed rules for disarming an opponent. More importantly, I believe this was an intentional design decision on the part of Wizards of the Coast. A disarmed opponent is effectively defeated; so disarming an opponent is something that you should only be capable of doing when an enemy is reduced to 0 hit points (as anything that is tantamount to defeat should only be possible when the enemy is actually beaten, i.e. deprived of hit points).

Now, I brought up the first objection during play, and the player countered with ‘well, the enemy spellcaster would be surprised by the Mage Hand suddenly appearing’. By that logic, it seemed to me that arrows from a concealed target should always hit their targets, and enemies should likewise be able to surprise and completely defeat the PCs with a good stealth check. That doesn’t sound like a good logic to use when running a combat to me. In a combat situation, everyone involved is, to borrow a quote from Alexandra Erin, “exceptional combatants trying very hard not to get killed”. I didn’t raise the second objection directly, nor did I think of the third until I’d had some time to think about it.

And it’s the third point that I really want to focus on, because it highlights, as I said above, a fundamental divide in how one approaches gaming. On the one hand, you have an approach that focuses on simulating a realistic world (albeit with high fantasy-style magic and other trappings of the genre) in as much detail as possible. This is called (or, at least, I am calling it) simulationist roleplaying.

Simulationist gaming systems tend to be heavy on rules. A game with rules that govern everything a player can possibly do is accurately described as simulationist. This is the style of gaming that leads to damage location, rules to determine exactly where missed arrows end up (and whether they break), and a very precise set of rules governing how magic works in the setting (and categorizing it, explaining how different types of magic do or don’t work together, etc). Simulationist games give you rules for how good your character is at any skill common to the game world, from fighting to cooking, or, gods help us, crafting. If you haven’t spotted it yet, I’m culling all of my examples from D&D 3e, because it is a heavily simulationist game. Earlier versions of D&D were also heavily simulationist.

Simulationist games tend to encourage attempts to find creative loopholes. Because there is a rule for nearly everything, and everything is spelled out in as much detail as possible, it naturally supports the sort of thinking that leads to “well, the spell doesn’t say it can’t do this…”. This, to me, is one of the biggest downsides of simulationist gaming, because it turns the game into a meta-game. Instead of playing a Wizard wandering through the world, destroying your enemies and impressing your friends with your magic, you’re playing a game where you carefully read the spell description to see if you can twist the words to use the spell in a new, advantageous way.

The other style of roleplaying, which I will refer to as narrative roleplaying, involves a greater focus on the narrative of the game, and on the broad themes of the world, without getting bogged down in detailed rules that ensure the game is carefully confined by a rule. In a narrative game, there is not likely to be a table to roll on to determine the quality of the bread baked by a local baker. Narrative-focused game systems tend to be as rules-light as possible, defining the areas that require arbitration (such as combat) and getting out of the way otherwise. Narrative systems also have a tendency to encourage reinterpreting the rules in ways that don’t effect their mechanical structure. D&D 4e and the entire White Wolf canon are good examples of games with a narrative focus.

The interesting thing about games with a narrative focus, or at least D&D in particular, is that there is a disconnect between the rules and the diegetic game world that doesn’t make sense from a simulationist perspective. For example, look at Second Wind. Second Wind operates diegetically on the principle that you take a moment to center yourself, to quickly bandage a wound, or to just take a ‘breather’, and thereby gain the stamina to keep fighting. Notice first that any of those things could apply narratively - you might do one or all of them, or something else that is analogous, as the situation warrants. But more importantly, you can only do this once per battle. Why? What makes bandaging a wound the first time extend your ability to keep fighting, but bandaging a wound again ineffective? It’s the same action; shouldn’t it have the same consequences?

The reason is that the rules account for things outside your character’s control. A battle is chaotic, and you don’t get many opportunities to step back and take stock of the situation and get your feet back  under you. Such a chance comes rarely - let’s say only once in a brief struggle of 10 rounds or so. Using Second Wind doesn’t simply represent an action that your character takes - it also represents your character taking advantage of things that are beyond her control, such as an ebb in the rhythm of the fight, to take a quick break and recover some stamina. As the player, the rules are giving you a limited ability to control things that are beyond your character’s control, for the sake of the narrative.

Encounter and daily powers work the same way. The ranger power Split the Tree is a daily power. The simulationist model would suggest that this doesn’t make sense unless the ranger has some sort of mystical ability that they can only tap into once per day that gives them the power to fire two arrows at once. The narrative approach gives us a way out, though: the ranger could fire two arrows any time she likes, but she doesn’t get an opening, or time to line up the shot, every round. That sort of opportunity only comes once in a while - hence, a daily power. The player gets the ability to decide when that opening and free time show up, but it can only happen a maximum of once per day. This is completely an arbitrary restriction imposed by the rules; for the sake of game balance, you can only do these things a limited number of times within the framework of the narrative. It is a concession to drama over realism.

This is especially noticeable in the rules on magic item daily powers. No matter how many magic items you’re carrying around, you can only use 1 magic item daily power per day (at the heroic tier). This isn’t because the magic items share a pool of magic; rather, it is because the narrative and the game balance demand that these things be used sparingly. A warrior who relies on his magic items and shows no sign of actual combat prowess is, well… Tony Stark. And Tony Stark is a tool.

Here’s another way to explain the fundamental difference between the two approaches: in a Simulationist game, the rules encapsulate the character. In a Narrative game, the rules encapsulate the narrative. And having said all of that, I’m still not certain I’ve made my point, which is that I prefer games like D&D 4e precisely because they encourage dramatic narrative thinking instead of simulationist thinking. The narrative approach gives you two important freedoms. First, you can make a balanced game without having to jump through contortionist hoops to explain why wizards and rogues have roughly the same level of power. Second, and more interestingly, they give the players a lot more room for creative expression - you can slap any narrative description or explanation on top of an existing rule, and as long as it doesn’t change the mechanics, you have nothing to worry about.

If you want to learn more about my homebrew setting of Yord, or follow the antics of the PCs, check out my campaign at Epic Words.

Doctor Who is off the air until September, and a number of questions remain unanswered. But just because we don’t get any new Who for three months doesn’t mean we have to stop talking about it! So here is my chance to answer all of your burning questions. Because I know everything that’s going to happen in the second half of series 6. All the reveals.

Spoiler Warning for everything, up to and including A Good Man Goes to War, and for the rest of the series too, if I’m right!

Okay, so I don’t really know all the reveals. I don’t have access to the scripts, and I certainly don’t have a retro-futuristic thought recorder pointed at Steven Moffat’s head (not that you can prove, anyway). But I do have a pretty good idea where the story is going, and I think I’ve got at least one reveal pegged.

To start, let’s review the two biggest questions that the show left unanswered after A Good Man Goes to War:

• Who kills the Doctor (i.e., Who is in the Astronaut suit on the lake in 2011)?


• How does the doctor survive being killed? Because, let’s face it, he does.


• Who did River Song kill?

I think I know the answer to the last one. Here’s your big spoiler: River Song kills her father, Rory Williams.

How do I know this? Moffat has left us a lot of evidence hinting in this direction. The evidence comes down to a theme in Moffat’s work: misdirection, specifically repeated misdirection.

Let’s start with the misdirection. By misdirection, I mean that there is a tendency in Moffat’s writing to tell us something in such a way that we assume something else. The easiest example to spot is in Amy’s monologues about Rory in series 6. The first one is in Day of the Moon, when she is captured by the Silence, and is talking to herself (but directing the words to Rory). She says:

I love you. I know you think it’s him. I know you think it ought to be him. But it’s not. It’s you. And when I see you again I’m gonna tell you properly. Just to see your stupid face. My life was so boring before you just dropped out of the sky. Just get your stupid face where I could see it, okay?

So, this is designed to make you assume she’s confessing her love for the Doctor - especially the phrase ‘just dropped out of the sky’. This is even lampshaded later, when she tells Rory it was just a figure of speech. That lampshade is, of course, Moffat gently mocking the audience for falling for his misdirection. He likes mocking us for falling for it, too: he does the same thing with FleshAmy and FleshMelody. Kovarian tells the Doctor, “Oh, Doctor, fooling you once was a joy. But fooling you twice, the same way, it’s a privilege.” These are both moments where the fourth wall is broken while still maintaining diegetic cohesion (Russel T Davies did the same thing with the 10th Doctor’s last line, “I don’t want to go”, which is clearly meant to be spoken by Davies, Tennant, and the Doctor simultaneously).

There is a second example of the Doctor-Rory misdirection; at the beginning of A Good Man Goes to War:

I wish I could tell you that you’ll be loved. That you’ll be safe and cared for and protected. But this isn’t the time for lies. What you are going to be, Melody, is very, very brave. But not as brave as they’ll have to be. Because there’s someone coming. I don’t know where he is, or what he’s doing. Trust me, he’s on his way. There’s the man who’s never going to let us down. And not even an army can get in the way. He’s the last of his kind. He looks young, but he’s lived for hundreds and hundreds of years. And wherever they take you, Melody, however scared you are, I promise you, you will never be alone.

Now, this one drops a really big hint, because both the phrases ’there’s someone coming’ and ‘you will never be alone’ parallels what Rory said in Day of the Moon: “She can always hear me, Doctor. Always. Wherever she is and she always knows that I am coming for her, do you understand me? Always.” And, of course, we get the reveal immediately:

Because this man is your father. He has a name, but the people of our world know him better as the Last Centurion.

So, where does this tie in with River’s story? In Flesh and Stone; when the Doctor asks River about the man she killed, she says he was “A very good man. The best man I’ve ever known.” It’s easy to assume this refers to the Doctor, but we’ve seen evidence that River has no illusions about the Doctor being a good man, particularly the line “This is cold. Even by your standards, this is cold” from The Impossible Astronaut, and her rant that begins “This was exactly you. All this. All of it. You make them so afraid” in A Good Man Goes to War. No, River wouldn’t call the Doctor the best man she’s ever known; she knows him too well. But she might say that about her father, who shows, time and again, limitless dedication to his wife.

There’s more evidence, too. In Flesh and Stone, Father Octavian says that “She killed a man. A good man. A hero to many.” Again, this could refer to the Doctor, and that’s the obvious choice. But it could also refer to Rory, in light of Amy’s line that “the people of our world know him better as the Last Centurion.” (which is interesting, because as far as we know Rory is not widely known as a hero on Earth. We appear to be missing a little bit of story there)

Ultimately, the reason I think this is more than just a lot of circumstantial evidence and idle speculation is that Moffat has already done the Doctor-Rory misdirection twice, and has blatantly lampshaded how much he likes fooling us with misdirection. A third misdirection is, at this point, a logical way to finish the series.

There is at least one problem with my theory, though I think it fits in with the same misdirection again. The episode title of A Good Man Goes to War has every indication of being about the Doctor. River’s poem certainly seems to talk about him:

Demons run when a good man goes to war
Night will fall and drown the sun
When a good man goes to war

Friendship dies and true love lies
Night will fall and the dark will rise
When a good man goes to war

Demons run, but count the cost
The battle’s won, but the child is lost

On the other hand, nothing in the poem (or the episode) explicitly says that the Doctor is the good man in question. In fact, River’s “This was exactly you…” monologue happens at the end of this episode, which leads me to believe the misdirection is complete - every reference to ‘a good man’ has been a reference to Rory, without exception.

So, how and why does River kill Rory? A friend of mine suggested that Madame Kovarian is River Song. This is plausible - River was raised as a weapon against the Doctor. There are certain physical similarities (Alex Kingston and Frances Barber have similar facial structures and hair, at least), although those aren’t even necessary given that River can regenerate. The River we know has always seemed more than a little haunted by her past, and raising an army against the Doctor, killing Rory, and being generally heartless and cruel might certainly explain those demons.

So, this is what I think we’ll see in the remainder of series 6: River is not rescued (or if she is, it is not for long). She grows up to be Kovarian, her mind being twisted by the Silence to hate the Doctor. Subsequently, she kills Rory (while trying to kill the Doctor). Somehow, she has a change of heart eventually, and becomes the River we are familiar with.

The biggest mystery left, for me, is why Kovarian and the Silence seem to be at odds with one another. The Silence went out of their way to kidnap Amy (did they know she was Flesh at the time?), and to try to make Amy tell the Doctor she is pregnant. These things don’t make a lot of sense if Kovarian and the Silence are allies, but we know River was raised, at least for some of her life, in the Silence-infested Graystark Hall Orphanage. So, either the theory about Kovarian being River is wrong, or Kovarian and the Silence have a falling out, and/or she manages to keep secrets from them.

My goal is two posts a week - typically, one on Wednesday and one on the weekend. This is usually a pretty easy goal to obtain - it doesn’t take too much of my free time to churn out two posts between 750 and 1500 words. And yet, there almost wasn’t a post this weekend. Was I playing Minecraft? Nope.

I was writing code.

Programming is something I’ve always wanted to do professionally, but somehow I managed to end up doing enterprise technical support instead. So, it has become a hobby. And when a project really starts flowing, it is easy to lose myself in it. So I spent three days this week spending every available moment adding code to my new project: a game I’m tentatively calling TreeWars. I’ve managed to tear myself away from the project for a while, but rather than put it out of my mind, I’ve decided to blog about interesting things that happen during the development process.

First, meet TreeWars:



Not much to look at, I know. But the project is still very much a work in progress.

Some interesting things about TreeWars:

• It is my second attempt at games programming, and my first was just a software implementation of a classic abstract board game (hnefatafl). And it was written using the graphics tools in GTK (which are serviceable, but not ideal). As a result, I’m learning all sorts of interesting things about the fundamentals of programming games.


• It is my first (real) attempt at graphics programming as well. I’m using SDL, and may eventually rewrite the rendering engine (and parts of the game engine) to make the game 3d and use OpenGL. Either way, I hope to make it cross-platform, although I’m currently only focusing on Linux, since it’s my native platform.


• It is based on trees from graph theory, not those other kind of trees.


• Currently, all of those beautiful graphics are procedurally generated. It is actually harder than you would think to draw a circle, at least in SDL.


• It (and the idea to blog about the process) was inspired by Project Frontier, a fascinating project by an experienced graphics programmer who is making far more interesting things than I am with procedural content generation! But hey, give me time…

So, the first step on the path to TreeWars was to learn enough SDL to generate a simple accelerated 2D image (not that it really needs to be accelerated right now, but I hope that will change in time). It turns out, this is both somewhat harder and somewhat easier than I expected.

I found a reasonably nice SDL tutorial here. In fact, TreeWars was just ‘sdltutorial’ (with plans to start writing a game once I’d worked through some tutorial programs) until I got to lesson where you implement Tic Tac Toe, and my mind insisted ‘Tic Tac Toe is boring, let’s make a real game!’ I justified that I often learn better when I’m puzzling out the best way to do something myself, and leapt into it.

The problem is, I often learn better that way, but I also often learn the hard way. I stumbled through a lot of ‘wrong’ ways of doing things in SDL, wasting a good deal of time hunting down the correct function (out of numerous functions available in the API) for getting a particular result. In the middle of all of that, it occurred to me that there is a knowledge level for which tutorials are never written. Tutorials are often written in a way that is so basic that I have to skip past large portions and carefully pluck out that bits that are relevant to me. On the other hand, APIs are often dense, and each function definition assumes you know the platform generally, so getting deep knowledge out of it presents a bootstrapping problem. Libraries almost never have a ‘using our library for the first time’ guide, or a best practices document, or a list of caveats that newcomers to that particular library may need to know about. So you get your choice between a too-low-level API for a huge, unfamiliar library, or a guide that tells you over and over that you need to call SDL_FreeSurface() when you’re done with a surface.

Instead, I’d like a guide that goes something like this:

Before you start drawing anything with SDL, you need to include the headers and call SDL_Init. In Linux, the headers are typically at /usr/include/SDL/SDL.h, but for portability it is recommended that you include the SDL header directory directly with ‘-I /usr/include/SDL’ and use “#include <sdl.h>”. A common init call would look like this:

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
if (SDL_Init(SDL_INIT_EVERYTHING) < 0) {
// error handling code goes here (return false
// if calling from an object or function,
// perhaps, or possibly exit())
}
[/sourcecode]

Typically, drawing graphics in SDL starts by creating a double-buffered, hardware-accelerated SDL_Surface object with SDL_SetVideoMode, like so:

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
SDL_Surface* window;
window = SetVideoMode(1024, 768, 32,
SDL_HWSURFACE | SDL_DOUBLEBUF);
[/sourcecode]

You can think of this as your main window (or root window, if you are comfortable with that terminology). You can draw other SDL Surfaces onto it (a process known as ‘blitting’ for some reason), and you can render the current contents of the (double-buffered) window with:

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
SDL_Flip(window);
[/sourcecode]

‘Flip’ may not make much sense until you understand the metaphor in use for a double-buffered surface. Think of a flat, thin surface with 2 sides - one side is visible (facing the user). When you draw onto the surface, all of your images are drawn on the invisible side - the side facing ‘away’ from the user. When you ‘flip’ this surface, the part that they were looking at is hidden, and the part you were drawing on is exposed. This lets you do your graphics updates ‘all at once’ instead of having the user see each object as you draw it.

So, to refresh the screen once per second, you might do something like this:

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
// assuming you have already initialized
// a surface called ‘window’
while (true)
{
// draw some stuff on window here
SDL_Flip(window);
sleep(1);
}
[/sourcecode]

There are several ways to draw things on surfaces - you can blit another surface on with SDL_BlitSurface(), or use SDL_FillRect() to draw a rectangle (this is SDL’s primary primitive shape, so procedurally generating curves becomes an interesting problem).

Of course, in practice you would probably want to do other things than just continuously render images - you need to respond to user input, iterate any data that needs to periodically change, etc. You might do those things in separate threads, but it is often simpler to check for them in a loop like this one. In fact, most graphics-based programs that respond to user input do things like this.

Oh, one other thing. When you’re done with a surface, you always want to clean it up with:

[sourcecode language=“cpp” gutter=“false” wraplines=“false”]
SDL_FreeSurface(window);
[/sourcecode]

Next time, we’ll look at some particular problems I encountered, and how I solved them. Then we’ll look at how I solved them correctly, to demonstrate that there are usually many ways to solve a problem. This will also let us highlight the difference between good and bad code. And we might talk some more about the joys of using the SDL API.

The Rambling Review is a series where I review games, books, movies, and TV series, both new and old, in a rambling, disorganized style.

“Can video games be art?” is one of those questions that has been discussed to death. Of course, the problem domain of defining art is a notoriously snare-laden landscape. But by almost any definition, it is clear from nearly the beginning of the game Braid that it is a conscious attempt to argue the case that video games can be art. At the very least, it is aesthetically compelling, with strongly cohesive sprites, backgrounds, music, and animations. But I would argue that it is more than just aesthetically interesting, and that it passes muster as a piece of art by almost any definition.

But more than that, the art direction reflects the themes and mood of the story, to say nothing of the symbolism encoded in the art. And the story emerges from and is intertwined with the gameplay. As Phil of The Nintendo Project recently observed:

[In Braid,] the story extends from the gameplay. It’s a story about the passage of time, memory, and regret, but all of the aspects of the story are simply thematic meditations on things about the gameplay. When the game introduces time-locked objects, the story introduces the idea of mistakes that cannot be undone. When it introduces the ability to have a shadow Tim carry out one set of actions while Tim carries out another, it introduces the idea of regret for lives unlived.

This is something that no other game in my memory has ever done. Coupling the gameplay not just to the content of the story (such as it is), but with the emotional and psychological themes of the game. Now, every game, however devoid of life, contains emotional and psychological themes. Everything we interact with does, because our minds are founded, by definition, in psychology. We approach the world by interpreting it, even if we do it on an unconscious level. Even pong can be discussed in terms of boundaries, liminal spaces, conflict, and the repetition of actions for an arbitrary and meaningless rewards.

However, games like Braid are different. They are written purposefully to draw out certain themes. They are intended to have emotive content rather than simply being circumscribed by our emotional reactions to them. Another insight of Phil’s, and the topic I really want to talk about with Braid, is this:

The thing about Braid that I think a lot of people miss, despite it probably being the most important thing about the game, is that it is one of an increasing number of games to operate in a lyrical mode as opposed to an epic mode. Implicit in this, of course, is the idea that the nearest textual medium to video games is poetry. And so Braid, instead of telling a narrative story about rescuing a princess, instead offers an extended poem in which video game mechanics, growing up, the apocalypse, and love are all intertwined into a… well… braid.

So, let’s start with something pretty basic. Phil is discussing here a dichotomy between poetry and narrative. Now, obviously he doesn’t mean poetry as an art form generally - after all, narrative poems certainly exist. Rather, what we’re talking about is a difference between two modes of writing - that is, two different things you can do with the written word. You can tell a straightforward story in which the narrative flows directly - in this mode, regardless of whether your story is allegorical or contains deeper meanings and metaphors, there is a surface level of actions that are related in some basic order. This mode, which I will call the ’narrative mode’ for simplicity, is how most stories are told.

Another mode, though, and one that is associated in many people’s minds with poetry in general, is what Phil calls a ’lyrical mode’. Narrative story is thrown out in favor of suggestive imagery and implicit connections. It is harder to tell a story in this mode, because we think of stories as following a single cause-and-effect sequence that we call its narrative. However, stories can be told like this, and Braid does so.

The result is a story that, while clearly a story, doesn’t have a single narrative in it. There are certainly many interpretations of Braid, but the only one I’ve seen that does them justice is the one quoted above. The story is not ‘a metaphor for the development of the nuclear bomb’, as one interpreter suggests. The development of the nuclear bomb is certainly a clear theme, but it is not the one correct interpretation of the story. Rather, there are many interpretations of the story that are all true, simultaneously. And the writer probably didn’t intend for all of them to be there - the interesting thing about writing in the lyrical mode is that you can make connections, while writing, that you weren’t consciously aware of, and that others can make connections from the symbols you use that you didn’t intend. It is a way of using language (and art, and music) that would seem messy to anyone who insists that a sentence only have one correct meaning, but the result is a beautiful and moving piece of art about regret, love, and the inevitability of loss.

Final Score: Yes

I have been a fan of The Escapist for a long time. I’ve been watching Zero Punctuation almost since it began. I’ve been following Unskippable, Experienced Points, and Stolen Pixels for a long time as well. And I regularly browse around the site, watching videos and reading columns that look interesting. You could say I’m a fairly loyal customer of The Escapist.

But I’ve had it. I can’t stand it any more. Look, Themis Media, I get that your product is advertising. That the Escapist exists, to you, as a medium through which you can deliver ads to people. But you’ve gone overboard. Your site now has all the charm of a geocities page from 1998 combined with an ad/malware site from 2005. You have made your site so horrible to look at and difficult to use that I can only conclude you are actually trying to drive people away from your site. Were you getting too many pageviews? Is that it? Because if that’s the case, feel free to redirect every, oh, 10th user or so over to http://stringofbits.net instead. I could use the traffic.

If you are trying to drive people away from your site, well, you succeeded. I’m unsubscribing from my Zero Punctuation and Unskippable RSS feeds, and I’ll be ignoring Shamus’ blog posts about Experienced Points and Stolen Pixels. Because your site really is that bad.

Look, I can’t even always use your site. Sometimes, when I try? I get this:



I tried to watch the latest Zero Punctuation recently, and that’s what I got. Your ads crashed my browser. If I looked at an ad in a magazine, and it sprayed me with a chemical that temporarily blinded me, I think we could probably agree that it is a poorly designed advertisement (the cause, by the way, appears to be a full-screen flash ad that overlays the entire screen with a semi-transparent background, then plays a video in the middle of that). And even when the site doesn’t crash, well, it still isn’t exactly pretty:



I’ve already enumerated my objections to Duke Nukem Forever, and I have to say I’m a bit disappointed that you’re still agreeing to show ads for that now that you’ve had time to learn about the game’s content. Also, that image is repulsive all by itself. But mostly it’s the sheer number of things vying for my attention here. It’s obnoxious, and it immediately drains the excitement that was building at the thought of watching another Zero Punctuation.

And keep in mind, this was a fairly light instance of the page, ad-wise. Usually I get a full-screen video ad, or an ad popping up annoyingly from the bottom of the screen (usually right as I’m trying to click play, so it intercepts my mouse click).

This just isn’t a good way to do business. I know, I know. You’re giving away free content! Why am I complaining? Well, yes, you’re giving away free content. So are tons of other ad-revenue-driven sites, and they manage to find a way to make my browsing experience much more pleasant. There are better ways to spend my time. And even if there weren’t, you have exceeded my personal threshold for how much I’m willing to be annoyed when I’m trying to be entertained. You have literally made it not worth my time to visit your site.

Congratulations, I guess?