Posts Tagged ‘video games’

Vendetta Online

Thursday, October 15th, 2009

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.

Nintendo and the Homebrew Arms Race

Wednesday, November 19th, 2008

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.

Decentralizing Second Life

Thursday, November 9th, 2006

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.