Posts Tagged video games

Rambling Review: Braid

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

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

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

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

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

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

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

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

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

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

Final Score: Yes

Leave a Comment

Gaming in Linux – my adventures with wine

I like playing games. My 1600-word review of Portal 2 should have been at least some indication of that. I enjoy console and PC video games, tabletop roleplaying games, and board games. But today, I’m talking about playing PC video games in Linux.

wine is not an emulator

Let’s start with the basics (then probably skip the middle ground and jump straight to the advanced stuff). Programs written for Windows or Mac OS can’t be run natively in Linux. By ‘natively’, I mean you can’t just click on a Windows application, or type its name on your terminal, and expect it to work. You’ll get an error like this:

bash: ./windowsprogram.exe: cannot execute binary file

There are a number of reasons this doesn’t work. The first and most fundamental is that Windows and Linux use different binary file formats; that is, the actual program code is structured in an entirely different way.

So why not just create a tool that can take one binary format and convert it to another? Well, to begin with, that would be pretty complicated, and probably fraught with problems; these binary formats are actually pretty complex, and include things like how to dynamically access libraries. Libraries are big chunks of code that are written separately from the program, then used by the program so that software developers don’t have to repeatedly write the same code to accomplish common tasks.

And that leads us to the real problem – Linux and Windows have fundamentally different sets of libraries available. Each OS has a large collection of system libraries that developers can use to interact with the Operating System in different ways. And there is very, very little overlap between these libraries. A prominent example of a library that exists only in Windows is Direct3D, which is used by a lot of game developers; it contains code that makes it easier to do a lot of complicated things with the graphics card, thus making it easier to make pretty, visually involved games.

So, if you want to run a Windows program in Linux, you would have to create a tool that could take a Windows program, make it “think” it is running in a Windows environment, and then take its library calls and somehow convert them into a set of library calls that Linux can understand. Direct3D calls, for instance, might be converted into equivalent OpenGL calls in Linux. This is exactly what the wine project does.

Wine has been around for a long time, and it has aged well (these are the jokes, folks). The latest wine codebase does a great job handling a ton of Windows applications, including a great many games. This article is an overview of my experience using wine to play games on Fedora.

blizzards and steam valves

My journey begins with wine-1.3.18, the version packaged with fedora 13. Wanting to play Starcraft 2, I ran the installer, which executed without a problem. The game itself also ran great, without having to make any tweaks at all to wine’s configuration. So, Starcraft 2 was an easy win. Blizzard’s games, in general, work great under wine. I’m not sure if Blizzard just avoids strange API calls, or if wine has a lot of developers interested in making certain Blizzard’s games work. Either way, this one was phenomenally easy.

The next thing I tried was Valve’s Steam client. If you’re somehow reading this from the past, or Steam no longer exists in the future (or you have recently emerged from a coma), Steam is a game distribution platform. You can buy electronic copies of games, install them in steam, and play them. Many games also support achievements and server-side syncing of your game data. This makes gaming on multiple computers really nice (as long as you’re the only one using Steam, that is). It also has community features; you can see what your friends are playing, join them in multiplayer games, etc.

So, I have quite a few games on Steam, and before I can try to run the games under wine, I have to get Steam to run. This was a little bit trickier than running Starcraft 2. First, the Steam installer is a .msi file, which requires the msiexec tool to run. Luckily, recent versions of wine come equipped with an open-source clone of the msiexec tool. So, all I had to do was:

msiexec SteamInstall.msi

Once this was done, Steam launched, but I ran into a new problem: every time I move my mouse over the Steam windows, they would flicker, making it hard to see what I was doing. This was solved by using winecfg to set the ‘Windows Version’ to Windows 7. Problem solved.

The next problem I encountered with Steam was that, when I drag a Steam window, it continues to move around after I release the mouse button, as if I’m still holding it. I have to click on another Steam window to make it stop. This problem remains unsolved in the latest version of wine (1.3.21 as of this writing).

Having Steam running, though, I was able to try a few games. The first thing I discovered was that every game I tried had major problems until I unchecked ‘Enable Steam community in-game’. Once I had done this, Plants vs Zombies and Darkstar One both worked great ‘out of the box’, with no tweaking required.

Portal, on the other hand, was not as great. Every few seconds of game play (not exactly precise, and it happens more when portals are open) the game will stutter for a moment. I spent a lot of time tweaking wine to try to fix this, but the problem remains in the latest version of wine. In addition, in wine 1.3.20, an even worse problem appeared – instead of stuttering, the game would act as if the mouse had been moved a random distance in a random direction periodically.

The last game I tried out was Team Fortress 2. It refused to start until I added an override for hl2.exe (in winecfg) disabling gameoverlayrenderer.dll and changing the Windows version to NT 4.0 (who knew Windows NT was a good gaming platform?). After this, the game worked with a stuttering problem similar to Portal’s, but more dependent on how much action was happening on screen. This was probably my most disappointing experience with wine, and 1 problematic game out of 5 isn’t bad.

So far, I have a (let’s say) 80% success rate with running Windows games under Linux using wine, with comparatively little effort required on my part. This is a fantastic result compared to even 2 years ago, and I look forward to watching the wine project enable ever more games under Linux.

tips, tricks, caveats

If you’re using Fedora, you may run into problems with pulseaudio. I recommend disabling it completely, via the following:

yum remove alsa-plugins-pulseaudio
echo > ~/.pulse/client.conf << EOF
autospawn = no
daemon-binary = /bin/true
EOF

Then, reboot your machine (or make sure you kill all running pulseaudio processes). Wine works a lot better this way. You’ll probably also want to run:

setsebool wine_mmap_zero_ignore 1

To make SELinux play well with games in wine.

Something I wanted to do but was unable to achieve was run native Linux games directly from Steam, and have Steam keep track of them. After asking on the wine-users mailing list, I learned that the way wine emulates Windows process handling makes this impossible. So, instead, I created steamstub, a Windows program written specifically for Steam under wine. To use it, add it as a non-steam game to Steam, then edit the game’s properties and change the name to a native Linux game of your choice. Now, before you go play your Linux game, click ‘Play’ on this game in Steam. Steamstub will deliver a small popup, and to your Steam friends, it will look like you are playing a non-steam game until you click ‘OK’. This lets you advertise what game you are playing, even when Steam can’t launch it.

One more thing you may find interesting is a tool I developed called wino. It lets you keep track of multiple wine prefixes (virtual Windows environments), so you can keep your programs separated. This makes it easier to recover if something in your drive_c directory gets broken; you only have to worry about reinstalling at most one program. If you make heavy use of steam’s ‘non-Steam game’ functionality, like I do, then this is not as useful for you. However, wino also does a lot of other useful things, like allow you to have a default command assigned to a wineprefix (so you could just run ‘wino steam’ to launch Steam.exe). It can also run winecfg (and a lot of other tools) on a prefix via ‘wino prefixname –config’.

Leave a Comment

Rambling Review: Portal 2

The Rambling Review is a new series where I review games, books, movies, and TV series, both new and old, in a rambling, disorganized style. It will contain scores, but they are absolutely and utterly meaningless. It is nominally inspired by Phil Sandifer’s Nintendo Project, but it is orders of magnitude less ambitious by design.

This post contains spoilers for Portal and Portal 2. Please do not read if you have not played these games and intend to.

Read the rest of this entry »

Comments (1)

Vendetta Online

I’ve recently discovered a game called Vendetta Online. This may be the MMORPG I have been waiting for: real-time skill-based combat, space flight, trading and mining, space flight, an interesting back story, space flight, and extensive moddability through custom skins, binds, and plugins. Oh, and it’s a space flight game.

I love space shooters. Put me in a cockpit and give me 3 dimensions of unfettered movement, and I may as well be in Valhalla. Combat is secondary; fighting in space is fun, but just the feeling of (pretending to) pilot through the stars, skirting around asteroids, and maneuvering into docking bays is intoxicating to me. The chance to do so with other people in a persistent world is something I can’t pass up.

The space flight in VO is a very solid balance of realism vs playability. Contrast Vega Strike, which focuses on realism to a fault. In Vega Strike, it often takes upwards of 15 seconds to maneuver your craft into position for each attack run on an enemy. Also, to disengage your engines you have to throttle all the way down, and to turn without having your engines engaged you have to press a special key.

Vendetta Online, on the other hand, operates in a more enjoyable way; you only apply thrust for as long as you keep pressing one of your thrusters. When you stop thrusting, you maintain your current velocity until you thrust again. This lets you reorient your ship without changing your vector, which is very useful for targeting objects, getting a visual on enemy craft, etc. It also feels very intuitive and realistic (whether it really is realistic or not is irrelevant, see below). Moreover, you can apply thrust in 6 directions; forward or backward along the 3 primary axes (relative to your ship’s current orientation). The game controls refer to left (+y), right (-y), up (+z), and down (-z) as strafing, while forward (+x) is accelerate and backward (-x) is decelerate.

Having the ability to thrust in any direction is useful and fun, but it isn’t very realistic (well, not with the ships looking the way they do; a ship that could do that would need thrusters all over the place). This is where the fun > realism design mentality comes into play, and frankly it makes for a very fun game. Another unrealistic design decision is the existence of a maximum velocity. Sure, you could make some sci-fi sounding arguments for it, but honestly it’s a balancing mechanic, plain and simple. And in my opinion, there’s nothing wrong with that.

The game world is vast; 30 systems with 64 sectors in each system (a system is a 16×16 grid of sectors). Each sector is “theoretically infinite” in size, although all of the interesting stuff is centered about the sector’s origin; after a few kilometers you find a whole lot of nothing that goes on forever. To get between sectors you can set a destination and ‘jump’ there. Likewise, to get between systems you go to special sectors that have wormhole areas, and you ‘jump’ while in one of these.

The game’s main RPG element (and I mean RPG-esque mechanics, not actual roleplaying) comes in the form of licenses. These are like a combination of level and skills in most MMOs. There are 5 licenses: combat, light & heavy weapons, trading, and mining. As you perform the eponymous activities, the skills increase. When they level up, you gain access to new ships, weapons, and missions. But the game remains primarily skill-based; in the hands of an incompetent pilot, the better ships aren’t that much better. I am afraid that I’m a testament to this fact.

The game isn’t perfect, though, and as long as I’m writing something like a review I’ll have to point out a few flaws. I hate to have to do this to you, Vendetta, but it’s for your own good. This will hurt me more than it hurts you.

The game world is big, like I said before. However, the player base is small. VO runs entirely in one instance, and you could easily fly across the galaxy and not meet another player. There are, on average, only 30 – 40 players online. This is alleviated a little by the fact that there is a cohesive world-wide chat, so communicating with the other players is easy.

I don’t know if there are more people on at other times of the day (I tend to play any time between 22:00 and 06:00 UTC) or if this is a low point for the year (more players during the summer?). Maybe the game is just old, and has lost most of its player base to attrition. At any rate, it feels like a ghost galaxy sometimes. I want to populate this world, to convince everyone I know to play and invade the VO universe en masse.

The other flaws in the game are fairly minor. You can only take one mission at a time, and many missions are automatically aborted (and thus failed) if you log out mid-mission. A network hiccup can destroy an hour of work (or more for mission trees that require you to start all the way over if you fail any mission in them).

In-system jumps and wormholes look the same. A more spectacular graphic for wormholes would be really cool, but on the other hand, the in-universe explanation for wormholes makes the modest special effects make enough sense.

There is also a stat called “grid” that weapons have but don’t explain. It refers to the total amount of power connected devices on your ship can use (i.e. the “power grid”). It’s kind of like a maximum voltage, and you can only use 20 grid per ship, although this is not explained anywhere. It’s not important until you get access to some pretty hefty ships, but it would be good to know about it, at least.

Other than these and similar minor nitpicks, the game is tons of fun and I foresee myself playing it for a long time. There is a free 8-hours-of-play-time trial available. My character’s name is Gjalfr. See you there.

Leave a Comment

Nintendo and the Homebrew Arms Race

When I purchase a piece of hardware, it is mine to do with as I wish.  This is a long-held understanding.  If I buy a piece of clothing, I can have it altered.  If I buy a car, I can change the tires.  If I buy a television, I can kill myself trying to screw with its insides.

It might void the warranty, it might put my life at risk or potentially damage the thing I’ve purchased, but it is my right as a consumer.

Nintendo takes a different view on the issue.  Owners of the Wii have long been able to employ a simple buffer overflow exploit in Twilight Princess to run custom code.  This exploit, called the Twilight Hack, allows a user to install, among other things, an application called the Homebrew Channel, which looks like any other Wii channel and lets you run other custom code without using the Twilight Hack again.  It’s the gaming console equivalent of installing a new stereo in your car.

Since the hack was made public, Nintendo has been trying to thwart it.  They have, to date, released three firmware updates that included code targeted to stop the Twilight Hack.  The most recent update succeeded at stopping it completely – it appears to detect the hacked save files and delete them, both on boot and whenever you insert an SD card.

So, all of this is standard fare.  Whenever a console launches, homebrewers will make it run custom code.  The console manufacturer will release an update to prevent this.  The homebrewers will work around it.  This process will continue in an escalating cycle.

However, Nintendo has delivered a low blow here.  Along with the System Menu 3.4 update, they changed their terms of service.


We may without notifying you, download updates, patches, upgrades and similar software to your Wii Console and may disable unauthorized or illegal software placed on your Wii Console…

Now, that’s pretty cold – deleting our custom software?  Come on Nintendo, all I want to do is play videos on my Wii!  Also, the first time a fully automated background firmware update breaks something, the angry calls are going to pour like rain.  Power outage in the middle of a night-time firmware update?  Too bad!  But it gets worse…

If we detect unauthorized software, services, or devices, your access to the Wii Network Service may be disabled and/or the Wii Console or games may be unplayable.

Okay, at this point I feel it is crucial to point out a couple of things.  First, these quotes come from two documents, the Wii Network Service Privacy Policy and the Wii Network Service EULA.  Both of these documents are required, not to use the Wii in general, but to use the Wiiconnect24 services (the Shop channel, Nintendo channel, and Nintendo’s other online content channels).  So, to use their network, you agree that they may disable your system completely.  This means two things:

1. You can perfectly legally run hacked code on a Wii that does not use Wiiconnect24.

2. You grant Nintendo the right to break the law (destruction of private property) if you choose to use the Wiiconnect24 service.

Now, according to a lawyer I know, a contract cannot override criminal law, even if signed in full knowledge as opposed to clicked-through (the enforceability of click-through EULAs is still up for debate in the US).  So this clause is, by necessity, unenforceable.

So why is it there?  Nintendo has a juggernaut legal team, famed for its ruthlessness.  They can bankrupt any individual consumer with the legal proceedings necessary to challenge them, and it is unlikely that this will raise enough stink to get a class-action suit started.

I used to have some respect for Nintendo.

Leave a Comment

Decentralizing Second Life

So, I’ve been thinking about Second Life, and it occured to me that it’s being done entirely the wrong way. Don’t get me wrong; I enjoy SL, and have no qualms with the experience itself. It’s the underlying scheme it’s built on that bothers me: one company controlling all the servers, one company responsible for keeping everything running smoothly. It seems to me that all technologies built on that model eventually fail on the Internet, while distributed technologies (Web, email, usenet) thrive.

To that end, I’ve been thinking about how Second Life could be successfully decentralized, without adversely affecting the experience that everyone has come to know and love. I’ve identified key elements of the user experience that would be difficult to decentralize, and possible ways to handle them. First, though, we’ll talk about the basics; how could decentralization even work.

First, LL releases the code for the Second Life server. Now, anyone who wants to can host a Second Life sim/sims of their own on a server. A central repository would keep track of the existing sims, in a vaguely similar fashion to DNS (see The Grid, below). This would allow Second Life to grow without bound, with sims run by a multitude of companies and even home users.

So, how do we keep that Second Life experience without the centralized monolith of Linden Labs?

Economy
First and most importantly, the Second Life economy must be preserved. The economy has become the most crucial element to the experience; the ability to use real money, diluted down to a virtual quantum, to purchase other users’ custom created content. This breaks down into two sub-problems:

a) Managing the money. The most likely way to do this would be to set up a “bank”, wherein a single host (or several different hosts) manages all of the banking transactions. I’m thinking basically a system like paypal, where you buy L$ (“Linden Dollars”, Second Life’s currency) from the bank, or sell $L back to the bank for real currency. Each SL server would use this central bank system to check a user’s account balance, and make withdrawals/deposits, with proper confirmation on the part of the user, naturally. A public/private key system to ensure the user actually sent the confirmation could prevent abuse here, so no worries on that score. The SL bank could even be controlled by Linden Labs, as this would be a lot easier to handle than the entire grid, and still give them opportunity to have a strong stake in their creation.

b) Protecting Intellectual Property. This is a tricky problem, and the single hardest element to decentralizing SL. Since a huge portion of the money in SL is traded for users’ creations, there must be a way to prevent them from being stolen. Under a decentralized scheme, when a user rezzes an object on a sim, all the data for that object (textures, sounds, scripts) would necessarily be available to the owner of that sim. The most obvious solution I can find for this is to keep the object data elsewhere, and have a rezzed object be a pointer to that data. The advantage is that compiled scripts, raw texture data, and sound files stay on a secure server independent of their rezzed location. But where is this mystical server? I see two options here: either the data is on another sim, perhaps the user’s “home sim” (see User Accounts, below), or the data is in a central “asset server” (essentially the way SL works right now). Using the former approach, the client would have to make tons of connections to different servers to get all the data. Under the latter, the asset server would have to be extremely load-tolerant and robust, and all the data is stored by the same group of people, whose ethical integrity the SL user base would have to trust implicitly. Since both of these are flaws in the *existing* Second Life system, however, it is acceptable for the hypothetical exercise we’re attempting here. Also, under either system the sim owner’s creations could be stored on-sim for lower lag.

One other solution would be to create some DRM scheme that encrypts this data until it reaches the client. Of course, in all of these cases the client could be modified to steal the data. However, here we again reach the fact that these flaws are already inherent in SL, and there’s no easy way around them.

The Grid
The ability to bring up a map and scroll around, or teleport instantly to another part of the world, is an exciting part of SL, and another crucial part of the SL experience. Fortunately, the Internet already has a great system that we can build on – DNS and hyperlinking. We simply define 2 kinds of link: “landmarks” and “neighbors”. Each sim can have 4 neighbors, and neighbors must mutually agree to be neighbors (for a neighboring to work between sim A and B, A would have to set B as a neighbor and vice versa). The neighboring agreements would be stored in a central server system, modelled on DNS. A few recursive calls to this system and each sim can cache a portion of the overall grid map. Want a private island? Simply don’t neighbor your sim with any others. This creates user-level “peering agreements” that could create a more logical terrain (snowy areas linked together, etc) even if the landscape does shift from time to time.

The other kind of link would work just like landmarks in the current SL system. Pretty self-explanatory, except this system would make “click to teleport” objects a necessity, finally.

If a user searches for a sim on the map, the client can grab that sim’s cache of neighbors, and display more of the grid. The client could be configured to keep any amount of that information cached locally, for a more immersive experience.

User Accounts
There are two ways to handle user accounts: a centralized account server, or a sim-based account system. Under a centralized server, all accounts would be handled by, say, LL. This simplifies the system greatly, and aids in managing the asset server. With “home sims”, you’d have a system similar to Jabber, where user accounts are essentially user@home_sim. I believe the centralized system will work best, given that the asset server system seems to be the most logical way to do things.

Instant Messages
Well, LL is currently planning to re-implement the IM system in Jabber, so we’re pretty much covered there :P

So, in summary, we have a system that uses a centralized server for accounts and user-created assets, as well as a DNS-like neighboring system to create the world map, but grids are controlled by individuals, and hosted by companies just like web servers are now.

Comments (1)

Follow

Get every new post delivered to your Inbox.

Join 136 other followers