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 onBloodRayne.
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:
an adaptation of a novel or short story,
an adaptation of a graphic novel or comic book,
an adaptation of a TV show or cartoon,
an adaptation of a video game,
an adaptation of a theatrical play or musical,
a sequel or "prequel" to a previous movie,
a remake or "reimagining" of a previous movie,
borderline plagiarism, or
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.
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.
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:
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."
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."
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).
There's a total progress bar on the bottom of the Steam window as well.
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:
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..."
Then click "Restart in Offline Mode" when the option appears.
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.
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.
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.
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.
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:
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.
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.
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.)
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.
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.
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:
An object passing through portals maintains the magnitude (but not direction) of its momentum with respect to the surroundings (consistent with option A).
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.
