Wednesday, July 25, 2012

Video Games & Movies

Dozens of films inspired by video games have come and gone over the years, and they're rarely worth your time. It's for this reason that I was in no hurry to start "blogging" when I heard, a couple of weeks ago, that the (supposedly) upcoming Assassin's Creed movie had become a bit too real with the casting of an actual, famous, relevant actor, Michael Fassbender, for the lead role. Needless to say, I'm a bit late to this party.

So why bring it up now? Well, it seems to me that now is as good a time as any to discuss the making-movies-based-on-video-games trend in general, since we've all had plenty of time to process the latest news of this particular game-to-film adaptation. We've gone through the initial excitement of imagining some of our favorite characters appearing in a big-budget movie, the sobering realization that nearly all game-to-film conversions are mediocre at best and that the best part of the game was actually playing it, and perhaps a resurgence of hope that this movie could be the one that makes up for all the bad ones that came before. As for me, that last part might not apply. I'm finding myself increasingly confused by the absurdity of taking a concept designed for an interactive medium and translating it to a medium which involves no interaction whatsoever. It hardly ever works, but they keep doing it.

Might the plot from Assassin's Creed make a good movie? Sure. Will it add anything of value to the franchise? Only if it's more fun than watching someone play the game, and one could argue that a lot of video-game-inspired cash-grab movies fail this test.

Part of me wants to believe that an Assassin's Creed movie could work, but the rest of me knows how unlikely this is. It's not my intention to hate on any particular franchise or developer, but things didn't go so well the last time they tried to make a movie inspired by the story from an Ubisoft video game. Not even Jake Gyllenhaal could save Prince of Persia: The Sands of Time, which might have been okay for an action movie if only they had dropped the mind-numbingly obvious (and stupid) parallels to the Iraq War... and pretty much everything else in the script.

An uninteresting plot can be ignored amidst the special effects and gratuitous violence and perhaps a smoking-hot (I mean "talented") female actress, but a downright stupid plot is just too distracting and can ruin a movie entirely. Perhaps I was also a bit overly annoyed by the lack of resemblance between this movie and the video game I so enjoyed, but hey, I can't pretend to be unbiased. And why should I? Wasn't I the intended audience?

In all fairness, I suppose we should be glad that the writers of this Prince of Persia film hadn't decided to follow the storyline of its namesake with deadly precision, since that would necessitate killing all but three characters within the first five minutes, one of whom would then be absent for most of the story. In fact, like many video games (though, perhaps, mostly the older ones), Prince of Persia: The Sands of Time doesn't have very much "story" at all. What's there is very good, for a video game, but it's not enough (and not appropriate) for a full-length movie.

Sure, the game itself takes many hours to complete — there are tons of monsters to fight, some platforming puzzles to solve, and some character development via dialogue during the completion of those puzzles — but the important parts of the story are told through a few cutscenes which don't add up to a whole lot. Of course, they might have instead used the collective plot from the entire "Sands of Time trilogy" (encompassing the sequels Warrior Within and The Two Thrones) — in fact, the film they released did borrow minor elements from all three games — but the disjointed plot you would get by trying to fully combine these three stories probably wouldn't have made a very good film either.

All of this, however, makes me wonder why they ever decided to make a movie based on this game if the story would have to be changed to the point where the script hardly even resembled the source material. If not for the familiar title, as well as the fact that the time-travel-enabling device happens to be a dagger and the fact that the main character is a Persian prince (albeit an adopted one), I never would have guessed that the film was inspired by one of my favorite video games. Actually, given that the film was published by Disney and that the main character is street-rat-turned-royalty and receives magical powers from an ancient artifact, I might have assumed instead that it was some kind of re-imagining of Aladdin. Not even the character names would have given it away, since none of the names used in the film appeared in any of the Prince of Persia games. It almost seems ridiculous to keep the title.

But of course they're going to keep the title, because a movie based on a video game typically has no attractive qualities other than its association with a popular franchise. The only people who see these movies are fans of the respective video games, parents of those fans, other old people who don't know what they're getting themselves into, and, of course, girls who care more about the lead actor than the subject matter. ("Um, a video game? Whatever, nerd, I just want to see Jake Gyllenhaal's abs.") The first two groups are arguably the most important, so filmmakers continue to draw inspiration from video games even though these movies usually turn out to be garbage and subsequently draw ridicule upon the franchises from which they spawned. The movies don't need to be good; they just need to be good enough that you, the video game fan, purchase a non-refundable ticket. In other words, while the critics might scoff, it's a neat way to make a quick buck... that is, unless your name is Uwe Boll and you just produced and directed a film based on BloodRayne.

The fact that lots of people played a stupid video game with a sexy vampire doesn't mean a movie based on its characters and aesthetic will turn a profit, so it's all kind of risky. Unfortunately, coming up with an original idea is riskier, and more expensive. That's why so many of the movies released so far this millennium are one or more of the following:
  1. an adaptation of a novel or short story,
  2. an adaptation of a graphic novel or comic book,
  3. an adaptation of a TV show or cartoon,
  4. an adaptation of a video game,
  5. an adaptation of a theatrical play or musical,
  6. a sequel or "prequel" to a previous movie,
  7. a remake or "reimagining" of a previous movie,
  8. borderline plagiarism, or
  9. crap.
Video game adaptations are particularly problematic because most would argue that the primary function of a video game, like any game, is to provide entertaining gameplay, rather than to tell a story. As such, most video games don't have awesome storylines, and that's okay if the games are still fun. What's so often substantially less than okay is taking a plot which exists solely for player motivation and using it as the inspiration for something that can't be played.

But we might, someday, see a genuinely good video-game-to-feature-film adaptation. After all, a lot of modern games are practically interactive movies already. Some video game fans will tell you that this is the end of "gaming" as we know it, but let's not get carried away just yet. While it's true that we often get stuck with less challenging, less sophisticated gameplay in exchange for a more "cinematic" experience, the industry has churned out a decent number of story-driven games which miraculously nail the winning combination of worthwhile gameplay and an engaging narrative.

Ironically, it's usually the heavily gameplay-driven titles, fun as hell to play but often lacking in depth, that end up having films named after them (see Doom). As a result, these films are mostly the trashy action/horror sort, which only sometimes do well at the box office and almost never do well with the critics. Why not make a movie out of a strongly story-driven game like Metal Gear Solid or Alan Wake or... Assassin's Creed?

Maybe it's finally happening.

Although it's too early to tell if the film will ever be made — a famous name attached to a project does not necessarily guarantee its completion — it's an interesting possibility. A film based on Assassin's Creed could actually follow the plot of the game rather closely without sucking. Furthermore, a film based on the Assassin's Creed franchise just makes a whole lot of sense. The publisher has already branched out into every medium they can afford to exploit. In addition to the five games that make up the core of the series, and a bunch of handheld/mobile spin-offs, they've released several books, some comics, a Facebook application, and even a few short films.

The irritating part is that some of these tie-ins occupy their own space in the series' alternate history, rather than simply re-telling or expanding the story from an existing game. It gives me the sense that I'm missing part of the expansive story if I don't check out all this peripheral stuff (including the one comic which was only printed in French). The film, if they're serious about making it, could be the same way. Rather than basing it on an existing game, they might instead stick it chronologically between two existing games, or give us a new story with a new protagonist and only subtle ties to the familiar story we've all been following. All we know so far is that Ubisoft wants to retain as much creative control as possible, which means they probably won't screw up their own canon.

In other words, it might be cool. Certainly it can't be worse than the short film Ubisoft made to promote the original game's first sequel.


I'm still not getting my hopes up, however, because the very thing that makes an Assassin's Creed feature film seem so natural is exactly what makes it kind of pointless. The game is "cinematic" enough. Modern video games, for the sake of becoming more mainstream, attempt to emulate movies, so creating a movie based on one accomplishes nothing but an upgrade of visual effects and the complete removal of interactivity. Films based on video games are primarily for the video games' fans, and fans of video games don't often wish they could experience a video game without actually having to play it. Playing it is the whole point. (Perhaps somewhere out there is a screenplay based on a game with an amazing story and horrible gameplay — a film adaptation of a game that should have been a film all along — but no one is going to see a movie based on a game that basically sucked.) The only way to make it worth watching is to make the story new and original, but then the fans will say they liked it better how it was.

When fans of a game care too much about the canon, a movie based on it is almost sure to fail in their eyes. Game-to-film adaptations are often despised by the game's fans for changes to the story and, more generally, for not living up to unrealistic expectations. Meanwhile, those unfamiliar with a game often don't care enough to see the film at all. It's for this reason that I'm always surprised by the few adaptations that actually do well (see, for example, Resident Evil... although I guess you can't go wrong with zombies).

Finally, whether the filmmakers appease the hardcore fans and create a faithful adaptation, or take a risk and try to improve upon the narrative, or do something completely off-the-wall and unrelated to the game (see Final Fantasy: The Spirits Within), they also have to deal with the fact that the film's association with a video game can easily do more harm than good. It might snag all the fans, but it might also alienate everyone else, namely the older audiences who think they're too grown-up for video games and, by extension, too sophisticated for such a movie. Then there's everyone else who didn't play the game, everyone who hates the game, et cetera.

But I hope for Ubisoft's sake that I'm just being pessimistic. Maybe all they need to make it work are good actors, good writers, and a good director. It's pretty clear that a lot of game-to-film adaptations have none of these things.

Wednesday, July 18, 2012

How To: Steam Offline Mode

Digital distribution and digital rights management are touchy subjects among consumers of video games. The idea that we don't really "own" the software that we buy has been the source of much debate. Many refuse to buy games protected by DRM of any kind, while many more try to avoid downloadable games entirely. Others, meanwhile, have accepted that the way things are going now is the way of the future. And it's okay, mostly. Digital distribution is just too darn convenient and most DRM is only a minor annoyance. (I have to log in? Okay. Wow, that was easy.) Steam, in particular, is often considered an example of digital distribution done right (if there is such a thing), but it still gets a lot of harsh criticism — sometimes for good reasons, and other times because it's cool to hate popular things.

Steam obviously has its perks; the interface is well designed, the features are useful, and the sales aren't bad. The major drawback, though, is that you typically need to be running Steam in order to play a game. (Yes, some games can be launched manually outside of Steam, but others cannot.) Since the Steam client is meant to be used online, it might appear at first glance that you also need to be online in order to play your Steam games. Fortunately, Steam has an "offline mode" to get around that. The problem is that misconceptions about offline mode are widespread and a lot of people don't seem to understand how it works. So let's try it out and see what happens.





Before we start, please note that Steam has its own Offline Mode How-To, which warns that offline mode might stop working if the Steam client is closed improperly (e.g., by shutting down the computer without exiting the program) or if the Steam client is outdated and fails to update (e.g., due to incorrect firewall settings). The rest of Steam's support page consists of step-by-step instructions on how to "configure" offline mode.

In my opinion, however, these instructions are somewhat misleading. The first step, for example, is to check the "Remember my password" box on the log-in window. As far as I can tell, this step is merely a recommendation and is by no means necessary. If you prefer not to let Steam remember your password at the log-in screen, go ahead and leave this box unchecked as shown below.

Steam login window

For the record, I didn't allow Steam to remember my password while I was testing offline mode for the purpose of writing this post, and everything still worked. (Do note that, while Steam does save account credentials to the computer as a necessary step in configuring offline mode, this is entirely separate from the "Remember my password" feature, which is only meant to save you the trouble of typing your password every time you use Steam online.)

Also somewhat misleading is the way the official guide ends with instructions to restart Steam in offline mode while you're online and signed in. This might be the reason for the widespread misconception that offline mode can only be used if you're already online. Of course, this is not the case. Once configured, Steam will be able to start in offline mode when there's no internet connection without the need to log in immediately beforehand.




Before attempting to use offline mode, you should make sure you haven't explicitly disabled it. You probably haven't — because that would be stupid — but if you have, you'll obviously need to go online to access your account so that you can fix the problem. (If you disabled offline mode and now you have no internet access, you're out of luck. Sorry.)

Here's how it works: The use of offline mode requires that Steam be permitted to save account credentials on your computer. If you disallow this and then try to start Steam without any internet connection, the following error message will appear:

Unable to connect to the Steam network. 'Offline Mode' is unavailable because there is no Steam login information stored on this computer.

To avoid this, we need to make sure that Steam is allowed to save your account credentials. Go online, start up the program and log in, then click on "Steam" in the upper-left corner of the window, and then click on "Settings."

Steam settings

Go to the "Account" tab, and near the bottom of the window, you'll see a check box labeled "Don't save account credentials on this computer."

Steam account settings
Don't save account credentials on this computer

Having this box checked prevents offline mode from working, so you need to make sure it's unchecked. You probably don't need to worry too much about this feature, since it seems to be unchecked by default, but it's important to know where these options can be found. (Note once again that saving account credentials for offline mode by leaving this box unchecked is not the same as telling Steam to remember your password at the log-in window.)


Obviously, enabling offline mode won't help us if we don't allow our games to finish downloading or updating before we attempt to launch them. Download progress is shown in your Library tab if you're using the "Detail View" or "List View" options (shown below).

Steam download progress (detail view)
Steam download progress (list view)

There's a total progress bar on the bottom of the Steam window as well.

Steam download progress

Clicking the words above that progress bar will show more details for all of your downloads. Before proceeding, you should make sure that all downloads are complete. Otherwise, when you attempt to play a game in offline mode, you might run into this:

This game is not ready to be played in Offline Mode.

At that point, you would have to go back online to finish the installation.


The easiest way to verify that offline mode is enabled — and, in fact, the most foolproof way to use the feature — is to switch to it manually while you're online. Apparently, doing this at least once is also a necessary step in configuring your account for offline play.

Contrary to popular myth, however, this is not the only way to use offline mode. Once everything is set up, you should be able to go straight into offline mode upon launching Steam if your internet connection is down, but I'll get into that later.

To restart in offline mode manually, click "Steam" at the top of the window and then click "Go Offline..."

Steam go offline

Then click "Restart in Offline Mode" when the option appears.

Steam switch to offline mode

Note that this requires account credentials to be saved locally, so you'll have to enable offline mode by giving Steam this permission. If you don't, you'll receive the error message below.

Steam requires you to have your account credentials cached locally to enter Offline Mode.

Fortunately, it's a helpful error message; you can just click "Enable Saving Account Credentials" and it will change the setting for you.

Switching to offline mode while online isn't just foolproof. It's arguably more useful, as well, mostly because Steam will remember your preference. If you switch to offline mode manually and then close Steam, you'll be given the option to start in offline mode again next time you launch the application, regardless of whether an internet connection is present.

Steam is currently set to be in Offline Mode. Many features, such as Friends and the Server Browser, will not be available while offline.

Under any other circumstances, Steam only offers to start in offline mode if it can't connect to Steam servers. If you prefer offline mode (e.g., because you don't want Steam to track how many hours you play), and you don't want to unplug your computer from the internet completely, then switching manually to offline mode is the way to go.


If we want to get out of offline mode, we can click "Steam" and then "Go Online..."

Steam go online

Then click "Restart and Go Online" when the option appears.

Steam go online

Once Steam restarts, you should be able to log in normally.


After you've checked your settings and downloaded your games — and, in fact, every time you finish using Steam online — you should fully exit the program before shutting down your computer. Failing to do so might cause problems with offline mode.
Note: Valve claimed to have fixed this issue in an August 2012 update. However, as of November 2013, the official Offline Mode How-To still warns that Steam should be closed manually. Failing to follow this step might still cause issues, so I'm leaving this section intact.
To properly close the Steam client, click on "Steam" in the upper-left corner of the window, and then click on "Exit." It's that easy.

Exit Steam

Do not simply press the little "X" in the upper-right corner of the window. This only closes the window, while the program itself continues to run in the background.

I always close Steam before shutting my computer down, but I recently tried doing it the wrong way, just to see what would happen. After disabling my internet connection and launching Steam, I tried to get into offline mode, and instead I got these two nonsensical error messages:

Could not connect to Steam network. This could be due to a problem with your Internet connection, or with the Steam network. Please visit www.steampowered.com for more info.
The operation cannot be completed when Steam is in Offline Mode.

Fortunately, this is very easily avoided unless your computer is the victim of a power outage. If you're receiving the error messages above, you should close Steam properly next time you're done using it.


Offline mode is enabled, your games are downloaded, you've switched to offline mode at least once, and you've shut down the Steam client. Now, if no internet connection is available next time you try to launch the program, you should be given the option of using offline mode.

Could not connect to the Steam network

When the "Connection Error" dialog box appears, just click "Start in Offline Mode" and Steam will open normally, except that online features like the store and the friends list will (obviously) not work.

Steam offline mode

Once you're in offline mode, you should be able to run any of your games, provided these games are fully downloaded, installed and updated. (For this example, I've used Portal, which is already installed and ready to play.)

Portal offline mode

Multiplayer games will run too, but good luck finding any servers.


So what happens if you suddenly lose your internet connection while you're playing? Do you need to enable offline mode in order to prepare for this? Well, not really. Losing your internet connection will not interrupt a single-player game even if offline mode isn't being used. If your connection is okay when you log in, then it doesn't really matter what happens after that.

To demonstrate, I started up Portal while using Steam online, and then disabled my wireless connection. Note the words "No Connection" on the bottom of the Steam window. Steam's online features stopped working but I didn't get kicked out of the game.

Portal no connection

There is, therefore, no need to switch to offline mode just because you expect connection interruptions.


So how well does offline mode work? It's not perfect — there are some bugs — but, as far as I can tell at this point, it performs well enough when used correctly.

I've heard plenty of stories of offline mode failing to work for various reasons, most of which are probably related to a firewall-induced failure to update the Steam client, or some other kind of weird scenario which I've been unable to test here.

Specifically, though, I've been told that the locally saved account credentials can expire — in other words, if you haven't logged into Steam in a long time, offline mode might not work anymore — but I won't be able to test for that unless I go some undetermined amount of time without playing any of my multiplayer Steam games, and I don't really feel like doing that. Since most people who play video games have constant internet connections, or at least the ability to log into Steam occasionally, the expiration of saved account credentials should not be a major problem.

I hope this helps.

Wednesday, July 11, 2012

The Moving Portal Paradox

Time for a thought experiment.

Many times, while browsing a certain anonymous imageboard, I've come across the following picture. It's been circulating for a while now, and it still starts a violent debate every time it's posted.

(I hope the artist will forgive me for using it here without permission, but the artist is unknown and probably posted this anonymously. You can't seriously expect me to track down the creator of an image which likely originated on the aforementioned imageboard where almost everyone is nameless and every post is deleted within hours. Besides, I'm claiming fair use, for all the obvious reasons.)

If you've ever played Portal, you probably have some idea of what's going on here. (If you haven't played Portal, you messed up, because it's fun and was given away for free on at least two occasions.) The basic question represented by the image is this: If you have a moving portal (orange) and a stationary portal (blue), and the moving portal engulfs a stationary cube, how does the cube behave when it emerges from the stationary portal? In scenario A, the cube essentially remains stationary as it was before the ordeal. In scenario B, the cube flies out of the blue portal, presumably at the same speed with which the orange portal was moving.

The Official Answer

Which scenario is correct? Neither. It obviously can't happen in real life, and it never actually happens in the game. In fact, portals are not typically allowed to exist on moving surfaces, and the only in-game exceptions are scripted events. (This is most likely because moving portals would cause a lot of weird behavior which the game isn't programmed to handle, the above being just one example.) So if you place a portal on a surface in the game, and then that surface moves, the portal vanishes immediately. But what if we simply lifted the seemingly trivial ban on moving portals and conducted a test within the game? Fortunately for us, some guy with a YouTube account created his own test chamber in Portal 2 to find out:


Technical difficulties! It seems that the rule against moving portals isn't the only thing preventing us from doing an experiment. Here it goes again with a faster moving portal:


Clearly, the very game on which this paradox is based just isn't built to handle such a conundrum. However, this is merely a result of the way the game is programmed. It's not an indication of how hypothetical portals might behave, since there's no apparent reason that the portal surface should actually become "solid" as it does in the video above. In short, we've learned nothing. So let's disregard this unfruitful experiment and move on.

An Attempt to Apply the Laws of Physics

The topic has been discussed a few hundred times with no consensus, but I might as well weigh in. I might even be specially qualified to offer some insight, since I do have... um, well... a degree in physics. Okay, okay, so this doesn't make me an expert in the fictional physics of a video game which regularly breaks the actual laws of physics in hilarious ways, nor does it make me an expert in weird scenarios which break the laws of this game, nor does it mean you'll actually think I'm smart (since I've left out, for the sake of privacy, the name of the university which I attended). But at least, unlike most people on the internet, I actually know what momentum is. (Hint: It's not a synonym for inertia.)

So let's take a look at this mess. Initially, the orange portal is moving with respect to the cube. Equivalently, since motion is relative, we can say that the cube is initially moving with respect to the orange portal. However, the cube is initially stationary with respect to the blue portal and, hence, to the room itself. Got it?

Many people look at this scenario and immediately conclude that, if the cube is initially stationary with respect to the room, it should still be stationary with respect to the room afterwards. You know, conservation of energy and conservation of momentum, right? And no apparent forces are acting on the cube, so if it's stationary then it should remain so, right? So option A must be correct... right?

Is this explanation elegantly simple or just crudely simplistic?

This argument in favor of option A is easy to follow, but what bothers me is the assumption that the laws of physics work, and that they work in this particular way.

The Laws of Physics and Why They Fail

First of all, how should conservation of momentum work when we're dealing with moving portals, or any portals at all? Even when considering "normal" portal scenarios, in which our two portals are stationary with respect to each other and with respect to the room, this fundamental law of physics seems to fail spectacularly. GLaDOS explicitly tells us that "momentum, a function of mass and velocity, is conserved between portals." I wish I could believe her but, in a strict sense, the law of conservation of linear momentum is already broken in Portal for a very simple reason.

It's important to keep in mind that momentum is a vector; it has both magnitude and direction. We know that direction matters because of the way colliding objects behave. A simple example: Imagine two objects of equal mass, each moving at the same speed, but in opposite directions along the same line. When they collide, the sum of their momenta (initially zero due to the rules of vector addition) must remain unchanged. In an elastic collision, for example, they will bounce off each other and move again in opposite directions at the same speed (and the sum of their momenta will again be zero). In an inelastic collision, they will both stop (in which case it's even easier to see why, together, they have zero momentum). Anyone who paid attention in high school physics, however, will know that they cannot just shoot off in random directions independent of each other, even if their speeds remain the same. If the directions are not right, total linear momentum has not been conserved.

When an object passes through stationary portals in the video game, the magnitude of this object's momentum always remains the same (i.e., the speed is unchanged) with respect to its surroundings. That's good. Unfortunately, the direction of the object's momentum always changes, unless the portals lie on parallel planes and face opposite directions (a very special case). This change in direction is, in fact, a change in momentum, and there is no apparent collision which causes the momentum of another object to change in a reciprocal manner, so conservation is violated. It should be clear now that we cannot blindly apply this particular law of physics to any portal-related problem... at least, not in the most intuitive way. (At least GLaDOS got one thing right: "In layman's terms: speedy thing goes in, speedy thing comes out.")

So the law of conservation of linear momentum is out. But can we at least assume that some of Newton's laws are satisfied? Going back to our original thought experiment, there doesn't seem to be any external force acting on the cube, and therefore its velocity should remain zero, right? After all, according to Newton's first law, an object at rest should remain at rest in the absence of any force.

But Newton also said that an object in motion should keep moving in a straight line until acted upon by some force. We've already seen that an object passing from one portal to another will often see a change in direction, so unless we can identify the force responsible for this, Newton's first law appears to be broken. We encounter a similar problem if we look at the "F=ma" form of Newton's second law. The equation tells us that, if the net force is zero and the cube's mass is nonzero, the cube's acceleration should be zero. However, it appears that the acceleration of a cube passing through portals is never zero unless we've been restricted to that special case of two portals on parallel planes facing opposite directions.

Acceleration is a change in velocity, and velocity (like momentum) is a vector with both magnitude and direction. If a moving object changes its direction, this counts as acceleration, even if the magnitude of the velocity (i.e., the speed) in a given reference frame remains unchanged. Therefore, an object changing direction as a result of passing through portals must have accelerated. According to Newton's second law, this acceleration would suggest the presence of some force. So should we assume that portals can exert a force on objects passing through them and that this force always accelerates an object such that its direction is changed but its speed remains constant? We could, but it's not a very satisfying answer. Since we don't know anything about this made-up force aside from the fact that one interpretation of our thought experiment suggests that such a force might be convenient, it doesn't really help us solve the problem in a meaningful way. Rather than making more assumptions to justify things that don't quite fit, we should be throwing out the dubious assumption that Newton's first and second laws are applicable to any problem involving portals in the first place.

Finally, what of conservation of energy? Does this law really apply in such a totally nonsensical and impossible scenario? You'd have a hard time arguing that it does because, once again, the law doesn't seem to apply to portals in general (let alone our weird moving portal problem). Any two portals at differing heights will essentially cause a change in the gravitational potential energy of a transported object without a corresponding change in kinetic energy (or any other energy we can see). Furthermore, if you place one portal directly above another, an object falling out of one and into the other will gain greater and greater kinetic energy with each pass, and the only thing that will stop this never-ending increase in kinetic energy is air resistance. Energy comes from nowhere, and this isn't something that happens when energy is being conserved.

Again, you could always assume that the portals are allowed to add or subtract exactly the appropriate amount of energy to account for this, perhaps drawing from a near-infinite and invisible source, but to allow such an assumption would be to throw all systematic and logical approaches to the problem out the window. It's a cop out, and it doesn't provide us with a means by which to proceed with this thought experiment. We might as well assume that portals are made of cheese and that they're powered by the souls of orphans. Instead of resorting to magical explanations, it's a lot easier to make no assumptions at all and simply concede that conservation of energy is a concept better left in the real world.

To make a long story short, the commonly cited laws of physics don't seem to be applicable to portals, regardless of whether the portals are moving or stationary. If they do apply, they don't seem to work in the most obvious way. So how do we even begin to make any sense out of the weird moving-portal example in question? Well, I have my own idea; you don't have to agree with it.

A New Frame of Reference

What I want to point out first is that a change in direction as seen by an outside observer is not actually a change in direction as experienced by the object which moves through a pair of portals. After all that fuss about how changes in direction are so important, it probably looks like I'm contradicting myself a little bit, but hear me out. First consider the regular portal scenario with two stationary portals.

Think about what you see if you look directly into a portal as an object passes through it. Since light passes through portals the same way as everything else does, you can easily see that the object appears to move in a straight line! Anyone who played the game should be familiar with this. Furthermore, if you jump into one of the portals yourself, there's no immediate indication, in this first-person perspective, that a change in direction has occurred, even though a third-person observer would disagree. To the portal traveler, it's just like going through a doorway. A person passing through portals would probably not "feel" a change in direction, or any kind of acceleration, even though acceleration due to a directional change technically has occurred.

So perhaps we can say that the direction of an object's velocity remains constant with respect to the portal system reference frame. To make this claim, we have to take the portal concept seriously and invent a new frame of reference and coordinate system in which both portals occupy the same space at all times. It's goofy, but it seems to work... and by "seems to work" I mean it's the only way our portal system can truly conserve momentum, magnitude and direction included. We can see clearly in the game that if an object enters one portal at a certain angle, it actually emerges from the other portal at the same angle, but only if each angle is measured relative to each respective portal.

In other words, if you go straight into one portal, you come straight out of the other; if you hit one portal at a 73° angle, you come out of the other portal at a 73° angle. Your journey through the portal system might have changed your course from, say, west to north, but if we stop trying to measure all of our angles relative to some universal coordinate system (e.g., the room) and just measure from the surface of the nearest portal, the troublesome change in direction is suddenly less troublesome. Mathematically, it's no longer there. So maybe GLaDOS was right after all; maybe we just need to ignore the outside observer and trust the portal traveler instead.

Now let's go back to the moving portal example. Things make a bit more sense when we use this new frame of reference and measure everything with respect to the nearest portal. If the direction of a moving object with respect to this "portal system reference frame" remains unchanged as the object passes through (and we can see that this is the case), it's not so crazy to say that the speed of the object, with respect to the nearest portal, might remain the same as well. Maybe both the direction and magnitude of an object's velocity should remain constant, but only with respect to the "portal system reference frame" and not with respect to anything else.

In other words, it's like this: Before the object enters portal one, your frame of reference is portal one; after the object exits portal two, your frame of reference is portal two. If you take measurements this way, the "before" and "after" measurements should match up. This model is, in fact, consistent with everything that occurs in the game, so it seems natural to extend it to this though experiment as well. If we accept that two portals at different locations can be used to change the location of an object, and if we accept that two portals facing different directions can be used to change the direction of a moving object, it's not such a huge leap to conclude that two portals at different speeds might be used to change change the speed of an object — all of these changes being relative to the room, of course. With respect to the "portal system reference frame" there would be no changes at all; an object's momentum would be conserved, in both magnitude and direction, in any scenario.

In the moving portal thought experiment, we know that the cube is initially moving at great speed with respect to the orange portal as it enters that same portal, so it should be moving at the same great speed with respect to the blue portal as it emerges. If that's the case, option B is correct. This is the best solution I can find, since considering the entire problem from the reference frame of the room just doesn't work properly regardless of whether one portal is moving or not, as explained at length in the previous section.

A Comparison of Both Solutions

It's difficult, however, to come up with a "right" answer, since both solutions are both physically impossible and yet rather consistent with the very limited examples shown in the game. This is because, outside of some scripted situations, the portals in the game never move. Everywhere in Portal and Portal 2, we observe the following:
  1. An object passing through portals maintains the magnitude (but not direction) of its momentum with respect to the surroundings (consistent with option A).
  2. An object passing through portals maintains the magnitude and direction of its momentum with respect to the "portal system reference frame" as defined in the previous section (consistent with option B).
If we demand that an outside observer witness no acceleration of the cube, we might conclude that option A is correct (i.e., that the cube remains stationary with respect to its surroundings). This solution is pretty straight-forward, and there's not much else to be said. It seems to work. However, if we disregard the outside observer (as we must do when strictly applying conservation of momentum to the regular "stationary portal" scenario) and instead demand that the cube itself not "feel" any change in velocity — or if we simply take measurements relative to our so-called "portal system reference fame" — things are much different, and option B looks more attractive.

Let's look at the process one step at a time. Initially, the orange portal is moving with respect to the cube; equivalently, the cube is moving with respect to the orange portal. Let's first use the reference frame in which the orange portal is stationary. Now we have the cube entering the orange portal at a certain speed and at a certain angle. In other words, it has some velocity. If the cube is to experience no change in velocity, it should maintain its speed and direction... but with respect to what frame of reference? In real physics, we must stay in one reference frame throughout the problem, so we would say that the cube maintains its velocity with respect to the moving "orange portal" frame; equivalently, we would say that it remains stationary with respect to the room. Option A seems correct here.

Admittedly, in order to get option B to work — so that the cube first moves with some velocity relative to orange portal and then moves with that same velocity relative to the blue portal upon emerging — we technically need to switch reference frames at the moment the cube passes through. This is because, in the moving portal scenario, the orange and blue portals are not in the same frame of reference... at least, not according to the traditional idea of what a "frame of reference" is. The "portal system reference frame" solution described in the previous section bends the rules, ignores the outside observer, and pretends these two portals are in the same reference frame and coordinate system anyway. Is that really okay? That's a matter of opinion. I say yes, since the portals should, at all times, connect two points in space as if they were the same point, regardless of the relative speed and direction of the two portals.

Of course, this is all just an attempt to extend the fictional rules for mutually stationary portals in order to come up with some more fictional rules for two portals moving with respect to each other. It's not real physics; an outside observer with knowledge of physics would immediately say we broke the actual rules by switching reference frames and rotating our coordinate system in mid-solution, all while keeping the velocity constant, but such an absurd move seems necessary in any portal scenario... at least, the coordinate system rotation certainly is, as I've already explained.

Other Approaches

A popular rebuttal to any argument in favor of option B uses a rather troublesome analogy. "If you drop a hula hoop on a cube, the cube will not fly up in the air," they say. "It will remain stationary." The reasoning here is that passing through the portals, as they connect two points in space, is kind of like passing through a hula hoop (or some other hole, like a doorway or a window). Unfortunately, the hula hoop analogy as applied to this special scenario is completely fallacious. The two portals are moving at a high velocity with respect to each other, while the "entrance" and "exit" sides of the hula hoop are always stationary with respect to each other. The hula hoop is a neat analogy for stationary portals, but as applied here it fails to account for the very thing that defines this whole thought experiment. Even after carefully considering the hula hoop solution, I think B makes a lot more sense.

More generally, most arguments in favor of option A appeal to logic that just doesn't work here. (This isn't a high school physics class and you can't just parrot some rule and assume it applies to every scenario, real or fictional, without thinking.) If two portals connect two points in space and make them one, then this moving-portal scenario has a single point in space moving at two speeds simultaneously, and the implications are pretty wacky. On one hand, the cube is initially stationary with respect to the blue portal. On the other hand, it's initially moving with respect to the orange portal, and the orange portal occupies the same space as the blue portal, so the cube is initially moving with respect to the blue portal. Which fact do we trust? Since the cube is going through the portal system, we have to measure things through the portals and not across the room.

If you don't trust any of this, or if I've lost you completely, there are some other ways of looking at this problem. Imagine that you're looking straight into the blue portal as the orange portal falls on the cube. Remember that the portal is like a window. What do you see? Obviously, you should see the cube (and the platform on which it rests) rapidly approaching from the other side of this window. When the plate with the orange portal slams into the cube's platform, what you see is the platform coming abruptly to a stop as it reaches the window. Which solution you choose now depends on whether you think this cube was actually coming at you from the other side of the window. If it was, the cube fits through the portal window and should keep going, since it's not glued to the platform and there's no force to slow it down. Therefore, choice B should be correct. If you think the motion you saw was an illusion, you should pick A.

But that motion really can't be an illusion if the cube does ultimately emerge from the blue portal, and this brings me to my next point. The following argument is probably simpler and more elegant than anything above, so if you're not convinced, you will be. Consider the fact that the cube is not being teleported instantaneously from the front of one portal to the front of the other. It enters the orange portal and emerges from the blue portal, and it must do so gradually — that is, one "layer" at a time, but not necessarily slowly. For some amount of time, however brief, the cube will be partially on the orange side and partially on the blue side. When the cube comes out of the blue portal, the top of the cube comes out first, and then the middle, and then the bottom. Super obvious, right?

Well, this means the cube must be moving, with respect to the blue portal, as it emerges. (This is a fact which is not up for debate because we know that it does, in fact, emerge.) More specifically, at this time, the cube is emerging from the blue portal at the same relative speed with which it entered the orange portal. That is, the cube is moving with respect to the blue portal at the very same speed at which the orange portal moves with respect to the cube. In other words, the cube must emerge from the blue portal at exactly the orange portal's falling speed. Consider the implications. If it's moving as it emerges from the blue portal, what could possibly cause it to stop once it has completely emerged? Unless some force acts on it, the cube should continue at the same speed. Therefore, choice B should be correct.

From this perspective, things get weird when you consider what would happen if the orange portal falls just far enough that half of the cube has passed through, and then abruptly stops. Then, relative to its surroundings, half of the cube is still stationary on the orange side (no momentum) while the half of the cube on the blue side must have some momentum because it was just moving out of the blue portal. I suppose that, depending on the strength of the cube, it might either emerge at half the expected speed or simply break in half. But I won't get into that. The scenario in question has been explained; by the time the orange portal slams into the platform and stops moving, the cube should have already passed completely through the portal, and a healthy dose of logical thinking will tell us that it should keep moving... that is, until gravity brings it back down to the floor.

Wednesday, June 27, 2012

Retrospective: Ten Years of Insanity

There's a general consensus that Eternal Darkness: Sanity's Requiem was, in some way, underrated. So many people say it, however, that I'm not sure if it could possibly be true. On top of that, the game's Metacritic score is fantastic. It seems to me that this Lovecraft-inspired GameCube-exclusive title was good enough to attract considerable praise, but wasn't quite popular enough to provoke a significant backlash of the hipster variety, the type that causes people to claim a record-breaking commercial success like Halo: Combat Evolved is the worst game ever made. In any case, the ratings themselves are above average, to say the least. If Eternal Darkness hasn't gotten what it deserves, it's not that it was underrated, but rather, I think, that it was underplayed. Maybe the game, though loved by critics, went underappreciated by the average player because it was too different. Or perhaps there was simply insufficient hype at the game's release. Indeed, when I found the game, some time later, it was by chance. Prior to playing it, I had never actually heard of it.

One night, I borrowed the game from a local movie rental outlet. Remember those? It seems they've long since become a relic of the past, replaced almost entirely by digital distribution and existing now only in the form of automated kiosks at supermarkets. My future children will never believe me when I tell them that entire buildings dedicated to renting out movies on physical media were once commonplace, and that the decent ones even had a section for video games. (On discs! With no DRM or DLC! Amazing!) Could Eternal Darkness really be so old?

Actually, yes. In fact, it came out in North America ten years ago this month. A full decade has passed since the release of what many would consider to be a masterpiece... and still no sequel. (The developer, Silicon Knights, instead spent too many years working on Too Human, a planned trilogy that ended up being a single game with mediocre reception.) There are currently some rumors of a sequel being developed for Wii U (along with some more rumors that the sequel, though never officially announced, has already been cancelled), but sequel-related rumors have been floating around at least since 2006, when Silicon Knights president Dennis Dyack claimed that a sequel to Eternal Darkness was a sure thing. That was six years ago, and none of the "news" since then has been concrete enough to get my hopes up. Nintendo did renew the trademark back in 2010, but U.S. trademarks need to be renewed every ten years anyway, so this might have been routine procedure. Until an official source hands out some official information, any speculation is misinformation and I refuse to participate.

In any case, I'm glad those rental stores were still around at the time, because otherwise I would have missed out on some neat games. I had no idea what to expect from Eternal Darkness, in particular, and I guess that was part of the fun. I only hoped it would be worth my time, and if it wasn't, wasting a few dollars on a bad rental would be worth the money I saved by not buying the damn thing. It was kind of a win-win situation, so I went with it.

As usual, I read through the instruction booklet before playing. I was a bit overwhelmed when I saw profiles for half a dozen characters, all from different historical eras, in the first few pages. (For some reason, only half of the playable characters were actually listed here, as if to let the player know the story is going to span two millennia while still withholding some nice surprises.) When I got to the page about sanity, I was intrigued, and cautiously optimistic; already, the whole concept of a sanity meter, alongside the ubiquitous health meter and the familiar (though oddly spelled) "magick" meter, seemed like a very original gimmick, but still a gimmick. I guess I still feel that way, to a certain extent.

The sanity meter is the game's defining feature, and you can't really describe the game without bringing it up. It hadn't been done before, and it hasn't been done the same way since, probably because Nintendo has a patent on it. The basic idea, as implemented in the game (though the patent makes it sound slightly cooler), was that a character's sanity would decrease when he or she encountered a monster — or, more specifically (and counter-intuitively), when the monster saw the character. (Shouldn't it be the other way around?) The character could then regain sanity by performing a finishing attack on a defeated monster. The most amusing aspect of the sanity system, in my opinion, is that your character would suffer a catastrophic loss of sanity if you went and killed an innocent bystander; in this case, delivering a finishing blow simply wouldn't do you any good.

When a character's sanity was low enough, things got weird. The camera would tilt, the walls would bleed, and you would start to hear crazy voices. Occasionally, full-blown hallucinations occurred, and while most of them involved the protagonists unexpectedly dying in hilarious ways, some of these hallucinations were an attempt to break the fourth wall, or to trick the player into thinking the game had malfunctioned. It was a clever way of making the player feel how the character felt — that he or she was going a bit mad. Throughout my first play-through, even when the game wasn't pretending that my television had just turned itself off, I had to wonder what was "real" and what was simply the result of the protagonist's deteriorating mental health. Few of these effects were likely to actually scare the player, but I'd never seen a more ambitious attempt at player immersion.

But the full-blown hallucinations usually ended with the character screaming, "this can't be happening!" — after which everything went back to normal, often returning the player to the previous room. (The game just isn't cruel enough to have these hallucinations actually affect your ability to win.) Strictly as a gameplay mechanic, the sanity meter was only a minor annoyance. You wouldn't lose for running out of "sanity," per se, but if the character would lose sanity while the sanity meter was empty, health was subtracted instead. Of course, this would rarely happen to a careful player. Impatient players, on the other hand, might tire of finishing off every defeated monster. This was, actually, a rather tedious task, since each finishing move would take a couple of seconds. And if you weren't quick enough, dead monsters would disintegrate on their own before you reached them, and you'd get none of that precious sanity back. At some point in the game, I did get tired of hitting the "Finish Him!" button; I was tempted to ignore it entirely, and instead rely exclusively on a spell which restored sanity in exchange for magick.

The game's magick system was almost as innovative as the sanity feature. At the very least, the potential was there, even though the execution was questionable. Different combinations of magickal runes, collected throughout the game, were combined to create different spells. With five "target" runes, five "effect" runes, four "alignment" runes, and an optional "power" rune to beef up any type of magick, the developers could have provided us with a fairly extensive list of spells. To be precise, assuming each target/effect combination were used, there could have been 25 distinct spell types. Instead, only 10 combinations were used, and while you could technically count 117 different spells if you were to separately consider each alignment rune and each acceptable number of power runes per spell, the complete spell list was still, in retrospect, a bit underwhelming. The player was even encouraged to try new rune combinations to discover spells, rather waiting for the game to reveal the correct recipes, but with only 10 acceptable target/effect combinations — and with many of the spells being revealed to the player as soon as the necessary runes were available — this wasn't quite as exciting as it sounds. The new spell feature was used mostly to create more powerful versions of spells you had already learned. [Spoilers in the video below.]


But perhaps, as a guy who has already beaten this game a dozen times, I'm being too demanding. Most of the spells that did exist in the game were pretty bad-ass, and they offered better ways to handle situations which might otherwise, to the unimaginative player, seem difficult. Playing the ninth chapter, arguably the scariest level in the game, I found myself facing a bunch of bonethieves — freakish, agile monsters that hide inside of human hosts and, if left without a host, try to crawl right down your throat. To defend myself, I had only guns (which are terrible for fighting bonethieves) and a photographer's flash pan (meant to temporarily blind enemies). Instead of fighting them myself, with my limited ammunition, I got rid of them by repeatedly summoning trappers — little crawly dudes that can teleport enemies to another dimension. It was the easy way out, but it was more fun stunning them with the flash pan and running like a coward until I found a proper weapon, which is probably what the developers intended.

The best you could ask for, in a linear game, is the ability to handle a given situation in a few different ways. That's why the plasmids in BioShock were so nice, and why the gravity gun in Half-Life 2 added some extra mileage to what otherwise would have been a straight-forward sci-fi shooter. Of course, I'd be lying if I told you that Eternal Darkness provided more than a couple of opportunities to diverge from its linear chain of puzzles, or that the combat — relatively open-ended though it might have been — was very good. But Eternal Darkness was, first and foremost, a psychological horror-themed puzzle game, not the type of game in which the combat itself was very important. Fortunately, it wasn't a big obstacle, either. In fact, most of the combat was so easy that brute force worked just fine — enchant your sword and start swinging, and you'd rarely go wrong — and if you ever did run into trouble, you just had to come up with another strategy, try different spells, and be more careful. The fighting itself was a bit clunky, and the ability to selectively target the limbs and heads of your enemies wasn't entirely as cool as it sounds, but it worked.

The way I see it, Eternal Darkness could have been a good supernatural horror even without the sanity features, since the magick system alone would have been enough to set it apart from the Resident Evil titles to which Eternal Darkness was so frequently and so unfairly compared. Perhaps it even could have been a decent puzzle-based survival horror without the magick, as well. Playing as a dozen different characters, with a variety of different weapons (from swords to fully automatic firearms), in a 2000-year struggle against the minions of ancient and all-powerful beings that transcend the physical realm and could squash the entire planet without breaking a sweat... well, that's a pretty good foundation for a psychological horror already. Add the spell creation system and sanity effects, and you have something truly special. The fact that the game is innovative in multiple ways makes it worth remembering, and worth replaying.

I ended up buying the game, twice — once because I loved it, and again because my first disc was scratched, which caused some skipping during the cutscenes. But that's what I get for buying a used copy. (Used games! Another soon-to-be relic of days gone by. The industry has almost succeeded in killing the used game market and I expect them to finish the job in the next couple of years. Apparently a used-game-buyer like me is just as bad as pirates or shoplifters in terms of "taking money away" from the developers. I doubt the poor condition of the disc was due to bad karma, though, since my second copy was also pre-owned, but in much better condition.)

Eternal Darkness is a very immersion- and story-driven game, and nothing more rudely breaks this immersion than dialogue that skips and stutters like a broken record, so having a scratched disc just drove me crazy. If you plan on getting your hands on a copy of this game, try to find one that's undamaged. It seems the game is already prone to occasional skipping in good condition, as it tends to drive the console somewhat bonkers, with the little motor in the disc drive pushing the laser back and forth rapidly during cutscenes and loading screens. At least, this is the case with both of my discs, and I've tried them on more than one GameCube as well as a Wii. I've heard similar complaints from other people, all of whom claim that Eternal Darkness is the only game that does this. Perhaps the game itself is possessed by some angry spirits.

None of this will matter to you if you plan on skipping all the cutscenes, but if you're playing a game like Eternal Darkness without paying any attention to the story, you're probably not enjoying it. Gameplay is always the most important aspect of a game, but the plot here is really a crucial part of what makes the game enjoyable. Even some of the vocal performances are pretty well done. [Spoilers in the video below.]


But there are also some rough spots, usually with the characters who don't have many lines. A particular conversation, between primary protagonist Alexandra Roivas and an unimportant supporting character, Inspector Legrasse of the Rhode Island State Police, is so far from believable that it's hard not to laugh, or cringe, or both. It's really a shame that this dialogue occurs right in the opening cinematic.


The fact that I wrote this much probably makes it a bit too obvious that Eternal Darkness is one of my favorite games despite its few shortcomings. I'm even a bit disappointed when people tell me they've never heard of it, but I wouldn't call it underrated. Underappreciated, maybe. But "underrated" is a worthless term, either way, since it conveys nothing but the fact that whoever uses the word is in disagreement with the critics; to say a game can actually be underrated (or overrated) implies that each game has an objective amount of goodness, some sort of inherent rating, that must be compared to the critical reception it receives. In other words, it's a way of saying that everyone else is wrong. And in this case, considering all the positive reviews, I think it's simply untrue that the game was underrated in the slightest. Although it might have deserved a bit more popularity in its own time, it's remembered as one of the best GameCube titles a decade later, and that's something.