Archive | October, 2006

Battlefield Nerf

30 Oct

Yes, Electronics Arts is evil, but having checked out the Battlefield 2142 demo, I caved in and bought the full game. If you’re not aware of the controversy, here’s a partial list of bugaboos:

  1. The game contains a mild form of targeted in-game advertising via billboards seen in the game world. So far, these billboards show a generic message, but they supposedly will soon start showing players advertisements targeted at their country of residence (determined via the player’s IP–not an exact science, really, but probably good enough for this purpose).
  2. Playing the game online requires making an account with EA and logging in every time. Not only is this a potential invasion of privacy, the authentication process is often buggy and not infrequently prevents a player from loading and playing the game. Last night, for instance, when testing the mod I was writing [discussed later in this post], every time I loaded the client, the game would seemingly hang for ten minutes at the log in screen before finally either succeeding or giving an error message. Other players have more serious problems involving authentication keys (a disturbingly common problem with many PC games these days).
  3. The “unlocks” system–wherein players gain better equipment as they earn points on “ranked” servers (servers registered with EA)–makes what is an otherwise purely skill-based game into a bit of a timesink in the vain of World of Warcraft and other MMORPG’s. Effectively, players with more skill (or at least a lot of time to play the game) get quite significant advantages over other players. This is totally backwards: better players, if anything, should get handicaps, not special advantages. Supposedly, in 2142, advancing through the unlocks is much faster than it was in Battlefield 2 (the previous installment in the series), so it should only take a month or two of regular play to get all the stuff. Still, inclusion of the unlock system is rather dumb as it simply frustrates any player coming to the game late: when a newb starts playing, most of the other players will have all the fancy unlocks already while the newb is stuck with the ineffectual and highly inaccurate starting weapons.
  4. This last problem aggravates the game’s already steep learning curve. Players must learn to master: four infantry classes, each with different weapons and several pieces of equipment; half a dozen land vehicles (including hover tanks, bipedal mechs, APC’s, and jeeps), each of which has multiple seating positions with different functions; four air vehicles; drop-pods; titans (giant airships on which players can walk and man various gunning positions); the team communication systems, which includes voice com and a targeting-based canned message system.
  5. Many hardcore fans are angry that EA has long refused to fix serious bugs in previous games, such as an infamous bug in Battlefield 2 that makes your teammates appear as enemy players at random intervals. This list of bugs is quite long.
  6. The game does not support widescreen resolutions. Supposedly this is to prevent players with widescreens from having a greater field-of-view compared to players with 4:3 screens, but this is a silly argument because field-of-view can easily be set independently of resolution. The game seems to compromise by using a field-of-view that is narrower than should be normal for widescreens but which is wider than should be normal for 4:3 screens: on a widescreen, things seem a bit stretched horizontally, while on a 4:3 screen, things seem a bit scrunched horizontally.

Aside from all that, my own particular peeves with the game include:

  1. The Battlefield series has had traditionally horrible menu screens, and Battlefield 2142 continues that tradition. The layout and organization of the screens are generally dandy; the problem has always been they’re slow. Unlike the best game menus, the Battlefield menu is not a simple overlay that is accessible while playing. Rather, hitting the ESC key triggers a few moments pause before the full screen menu appears, complete with visual effect doodads that add to an already processing and memory hungry game. (In previous installments, the menu background was even an animated video! Thankfully, that misstep has been avoided this time, but the whole thing is still sluggish.)
  2. Speaking of performance, the Battlefield engines–both the one used for the original, Battlefield 1942, and Battlefield Vietnam, and the engine that succeeded it for Battlefield 2 and now 2142–have always featured degraded control responsiveness when running around as an infantryman, especially when the system gets overtaxed. Most other engines, including those from id, valve, and epic, don’t have this problem until the framerate gets noticeably bad; with Battlefield, the framerate can appear fine while the controls feel like crap. My suspicion has always been that this has to do with the way vehicles and infantry are physically simulated, and it may just be a necessary sacrifice to get a good vehicle control feel (something which Battlefield does well but other engines usually haven’t).
  3. And speaking of aggravating menus, you’ll probably be spending a lot of time in them every time you load the game to fiddle around with your control settings. The control selection is split between three control modes–common (for infantry), land vehicles, and air vehicles–and these modes seem to overlap in surprising and inconsistent ways, e.g. selecting a button for an air vehicle control may conflict with a control used in common mode even though that control isn’t used when flying air vehicles. Worst of all, the game has a way of forgetting your control settings or not accepting the changes you make. You’ll go back to the game and find things are not as you set them.
  4. EA and DICE both seem convinced that players should be forced to watch 30 seconds of unskippable intro video every time the game is loaded. This will piss you off immensely if you are reloading the game for the umpteenth time after a crash. (There is a simple hack to make the videos go away: rename or delete the video files. Still, it’s outrageous that users can’t bypass the videos or set a preference to make them go away.)
  5. Battlefield 2 introduced a HUD system in which markers indicating the position of team mates and squad mates are superimposed over your field of vision. While occasionally useful, it’s not useful enough to justify not including any way to disable this feature. Ideally, the position markers could be shown or hidden via a hot button.
  6. The Battlefield 2 engine exposes modding capabilities only really for adding/modifying weapons and vehicles. On the scripting side, while the engine features a built-in Python interpreter, the functionality exposed for it is extremely limited, gameplay-wise. For the most part, script mods are limited to doing administrative things like implementing auto-team balance and sending messages to players. Even simple things, like having the server hurt or kill a player can’t be scripted (at least in a satisfactory way).

Speaking of modding, I spent all Thursday making my own mod for 2142. The idea is to change the flow of the game by allowing only certain squad leaders to neutralized and capture flags. This is a rather crude way of addressing my longstanding annoyance in the Battlefield series, a lack of team coordination and a lack of strategic cohesion (if you can take any flag at any moment and the enemy can do the same, the game mostly degrades into a glorified deathmatch). Hopefully, this mod will force/encourage players to support their squad leaders rather than run off to capture flags on their own.

Is Google Reader the best syndication aggregator?

30 Oct

I’ve come very late to using webfeeds, having only started a few months ago, but I’ve bought in to syndication to the point of removing all the sites I syndicate from my bookmarks. No more aimlessly wandering through my bookmarks to see if my regular blogs have updates.

My first foray with feeds was using the WizzReader Firefox extension, but I found that buggy with a few interface quirks. Then I used a Java app called BlogBridge for a while, which had some feed display issues and some interface clunkiness. Then I switched to another Java app, RSSOwl, which was an improvement, but it comes stock with a glut of feeds that I felt obligated to sort through rather than delete summarily; my list of feeds in RSSOwl never recovered from its initial clutter and disorganization such that I was scared to open the application.

Finally I discovered Google Reader. Here’s a few reasons why I like Reader:

  1. Reader is web based, so I’m not locked to one machine.
  2. Firefox 2.0′s new syndication integration feature means I can add a subscription to Reader simply by clicking on a feed link. (Not all readers support this integration yet, but I’m sure they will soon.)
  3. The work I put into adding feeds and categorizing them is not trapped with Google because I can export the feeds in a standard format. Sure this is standard for client-apps, but it’s another thing for a web-based provider to not trap you to their service. (Now if only I had discovered the import feature before I did all that work to set up my feeds.)
  4. While Reader initially only grabs so far back in a feed’s history when you subscribe to it, scrolling down to the bottom will automatically bring in the older content. If the other readers I tried had a similar capability to retrieve old feed items, I couldn’t find it.
  5. Reader lets me tag a feed with multiple tags rather than having to organize feeds into discrete categories. Not that I ever use multiple tags, but I object to hierarchical categorization in principle.
  6. I can view all of my feeds, or all my feeds with a particular tag, as one big feed with the items of the many feeds in chronological order.

Here are some mostly small things which could be improved:

  1. The name is a problem, as I had vaguely heard of Google Reader, but I assumed it had something to do with e-books. What it should be called is “Google FeedReader” (see the next section).
  2. The intro page makes no mention of RSS, Atom, feeds, or syndication. It just says you can “subscribe” to websites. Seems like a smart approach, but it doesn’t help users learn which sites they can subscribe to; if I weren’t in the know, I would think that I could subscribe only to sites that setup a special affiliation with Google. I guess Google’s expectation here is that users will find subscribable sites via Reader’s search feature (a bit confusingly, the search bar is labeled “add subscription” because if you put in a feed url (or a site name that returns just one result) it will ask you if you want to add that feed rather than showing a results page; perhaps this should be relabeled “Search for or add a subscription”.
  3. In the expanded view of an amalgamation of multiple feeds, the “from” line doesn’t stand out, so I find it hard to identify at a glance the origin of an item when scrolling by. Perhaps the “from” line should have some kind of highlighting. Better yet, the origin of the item should go on the same line as the title, much like it appears in the list view, or perhaps it can go to the right of the title, adjusted to the right edge of the page. Either way, the visual difference would have the side benefit of reminding users that they are viewing multiple feeds as one. I see why Google hasn’t done it this way though: there’s plenty of room for it on my widescreen display, but other users may not be able to afford the screen real estate.
  4. The tagging mechanism has discoverability issues, and once learned, it is clumsy for tagging many subscriptions. There should be a way to change the tags of a subscription when viewing the subscription rather than having to go to the subscription management page. My kludge around this problem is to create a tag I call “unassigned”. After adding a bunch of subscriptions, I can then go into the subscription manager, select all the unassigned with the “select unassigned” button, give them all en masse my “unassigned” tag, then filter for the unassigned tag so I can see just those subscriptions, then go through them individually to tag them all. A much simpler solution here is if Reader automatically put new subscriptions in a category called “Unassigned” or “Uncategorized”. (This would also solve the problem of untagged subscriptions in the subscription list looking too much like they’re part of the last tag group rather than on their own.)
  5. It would be nice if Reader allowed me to view a feed without subscribing to it. Sure, getting rid of a feed when viewing it is a simple click away, but I hate the idea of cluttering up my subscriptions with unwanted detritus. (The better solution here is probably to allow better ways of organizing and filtering through my subscriptions, such as being able to sort them by ‘date last read’, or ‘date last updated with new content’.)
  6. I’d like to bypass the screen that asks me whether I want the feed to go to my “Google Home” or to Reader. I’m sure some kind of Firefox extension could fix this, but a Reader setting would be the preferred, direct solution.
  7. The left sidebar width should be adjustable, like the height of the WordPress edit windows.
  8. The “feed settings…” pull down has only one button, so either add more buttons to it or just make it a button that says “unsubscribe”. Either way, move it down to be level with the line that says,X new items [show all] All items [show only new] Mark all as readRefresh”. While you’re at it, put the “expanded view” and “list view” tabs down there as well. I understand making them tabs is supposed to convey general applicability (switching between views affects all subscriptions you view until you switch back to the other view), but I think conveying that idea is less important than not introducing new kinds of unnecessary widgets and splitting up the buttons that affect the currently viewed subscription. (Besides, tabs are more appropriate for simplifying navigation: they allow the user to navigate between multiple screens without getting lost. Changing display styles is not really navigation.)
  9. The ‘settings’/’manage subscriptions’ screen should appear as a subscription does, with the subscription list bar on the left. A user would “return” from the settings screen simply by clicking on a feed.
  10. Make the manage subscriptions button stand out more or simply put it up top next to “settings”. If this is done, the settings and manage pages should not be the same page: one for tagging and such, the other for the miscellaneous stuff.

Beyond getting readers right, syndication has some problems in general:

  1. Name confusion: RSS, RSS1, RSS2, RSS1.0, RSS 2.0, Atom, XML, syndication, subscription, feed, webfeed. Which of these words should you use when explaining the concept to a non-initiate? RSS/Atom/XML are definitely out. My choice would be “feed” because it is friendly and still the most accurate. “Syndication” connotes backroom media deals for sitcom broadcast rights or printing a cartoon in newspapers. “Subscription” connotes signing up and paying money rather than something you can just “bookmark” and get for free. (It occurs to me now that perhaps the real problem is the lack of a term analogous to “bookmark”; come to think of it, we also need a term for a feed entry/item.)
  2. I personally prefer feeds that display the whole content, but many feeds provide just a blurb or excerpt. Some do this to save bandwidth, others out of inattention, and still others to encourage readers to visit their sites proper. I’m sure this is hotly debated among syndication users and developers, but it seems what is needed is putting greater formatting power in the hands of feed providers so they can give their feeds a unique look and include ads. (Drawing the line at embedded scripting at this point seems reasonable to me.) On the other hand, I as a user find the sparseness of feeds one of their greatest virtues. Hopefully, this design balance will get sorted out.

Learn how to use MediaWiki

25 Oct

For an example of the inadequate video quality I was talking about in the previous post, check out my 13 part tutorial on how to edit MediaWiki wikis. I made this tutorial to help others contribute to the project.

In all, this tutorial runs an hour and a half. Considering the tutorial moves quite fast, I don’t think this speaks well of MediaWiki’s learnability, though to be fair, I get into a few of the more advanced features.

p.s. For comparison of the video quality, download one of the videos here. (That’s the only unit I’ve made available so far, but I really should take it down because it’s an old revision which contains some rather embarrassing flubs and has some clarity issues.)

Screencasting with Google video and Youtube

23 Oct

With the H.264 codec, you get fantastic video compression for screen capture because it’s smart enough to recongnize an essentially unchanging screen. The image quality is near perfect with an under 1k bit rate for an umoving image.

So it’s quite annoying that both Google Video and Youtube (and in fact all the video hosting services) use a compression algorithm that is totally inappropriate for screencasting because it makes the text on the screen mostly indecipherable. Most annoying is that moving to something like H.264 would provide simulateously better quality and lower file size.

I don’t know what’s stopping them. I’ve seen plenty of high-quality flash video screencasts. Problem is, I can’t use this high-quality delivery without hosting the screencasts myself, and I’m not ready to push my $5-a-month hosting (though SiteGround claims I get 900GB a month! I haven’t asked if they really meant to capitalize that B or not; it’s possible they aren’t aware of the ‘b for bit’/’B for byte’ convention).

As it is, all my videos are uploaded to archive.org as h.264 avi files (in future, I’ll start posting them in matroska format as well, but I need to find the right tools for that conversion). This is not entirely satisfactory, as I have to direct users on where to find an h.264 codec, and they can’t get a quick preview before downloading the files. I personally find unnecessary downloading always a bit bothersome because I have to think of where to put the file; it just adds to the number of things I have to keep track of.

Speaking of Gootube, as far as I can figure, Google, whose interface I preferred using over Youtube’s clutter, could never catch up to Youtube because, as I found out myself, it takes days for Google to approve uploaded videos whereas Youtube takes less than an hour. That’s a perfectly rational reason to prefer Youtube. An alternative, more depressing explanation is that the masses are fetishists who cling sheepishly to what they already know. I hope this dynamic isn’t as strong as it seems, or else the collapse of MySpace will never come.

Net neutrality: the electricity analogy

21 Oct

The oblique threats to violate network neutrality coming from the telecom industry essentially come down to one thing: no one wants to be a commodity provider because there’s never an opportunity for turning a commodity into a golden goose. With a commodity, the seller pretty much gets back just what they put into it, never much more. This explains the greater part of the enthusiasm during the tech boom: startups and investors desperately searched for a position of control, where hard work, a good idea, and being in the right place at the right time once could mean that you won’t have to do any of those things ever again to still rake in the dough. Everyone wants their piece of a positive feedback loop, and the telecoms’ desire to make the network proprietary is just exhibit 3452327325 of this.

Currently, there’s a great difficulty in convincing the general public of the danger of this. What’s needed is a good analogy (via dburrows at One for the Morning Glory):

Imagine that your power company decides that it wanted to open a line of supermarkets. At the same time, it sends out an announcement that supermarkets (due to their refrigeration requirements) are particularly heavy users of the electrical system, and as a result, the power company will add a 15% surcharge to the power bills of any building that it deems to be a supermarket. Of course, the power company’s own supermarkets are exempt from this fee. When the existing supermarkets complain, the power company says that they’re asking for special treatment and trying to get electricity “for free” and that if they don’t like its terms, they should buy their power from someone else.

This anonymous response in the post’s comments makes a strange case:

What would be more accurate to say is that the power company has to continually add more infrastructure to keep up with the increasing electricity use by everyone (likened to Bandwidth in this case). Normally the power company increases the price of electricity across the board for every customer to pay for this but noticed that some customers are utilizing most of their infrastructure. Therefore, they decided to charge the heaviest users (beneficiaries in this case) rather than charging everyone.

First, the commentor is confusing flat-fee service (what most home users get these days) with metered service: in a flat-fee service, yes, the heavy users are subsidised by the casual users, but not so in a metered service, which is the kind of service under discussion in the neutrality debate. (It occurs to me, then, that another problem in making the case to the general public is that the general public tends to only see things in terms of home-use services.)

Second, the idea that heavy users can’t be reigned in is silly. If a customer is over-taxing your metered utility, you do a few things:

  1. Cap their usage.
  2. Cut them off.
  3. Charge a premium for going over a usage within a time period.
  4. If your customer base as a whole is communally taxing the network, you can charge a premium for peak-hour usage. With a bit of programming, you can have the per-hour use fluctuate dynamically along with demand.
  5. Expand your capacity so you can sell more and thereby make more money. (Despite what the commenter suggests, the consumer can’t force the provider to provide more capacity.)

In contrast, what the telecoms are threatening to do is to charge a premium for how the utility is used, not for how much of it is used. Of course, in a properly competitive market, the best solution for a provider is to use techniques 1-4 in the short term but focus on expanding capacity for the medium and long term. The telecoms don’t see their business this way. They want to do whatever it takes to capture a market and then sit back and watch their golden goose crap out the golden eggs.

Here’s Lawrence Lessig on net neutrality, yesterday.

Here’s a cute video: Net Neutrality Explained

More coding practices religion

21 Oct

Seven rants about successful programming give or take two.

What if this random guy on the Internet told you that you could be earning $60,000 – $100,000 dollars a year?

21 Oct

This obnoxious come-on actually gets it mostly right about programming myths:

Myth #1: Computer programming is for technology geeks.
The reality is that the Project Manager, Business Analyst, Tester, Manager, Sales Executive, Recruiter, Technical Writer, Web Developer, Web Designer and other roles in the programming industry require different personality types and there is no one personality that represents all these roles.

Myth #2: You have to be good at math to be a programmer.
The reality is that the majority of computer jobs do not require a math background. They however require logical, problem solving skills which can be learned by adults.

Myth #3: You have to study computer science in college to be a programmer.
The reality is that professionals with backgrounds in English, Arts, Music, Sales, Engineering, Mathematics, Psychology, Retailing, etc. are employed as computer programmers and there is no formal degree required for employment in computer programming.

Myth #4: There are too many programmers or the job market is saturated with programmers.
The reality is that if you have marketable computer programming skills with real world experience, recruiters will be calling you with job interviews and job offers.

Myth #5: Most of the computer programming jobs have been out-sourced. The reality is that there is such a high demand for computer programmers in the USA, that programming jobs go unfilled every day.

Myth #6: Computer programming takes years to learn.
The reality is that it only takes years to learn if you are not following a well thought out plan based on industry experience. If you get a copy of the “The Street Smart Guide to High Paying Computer Programming Careers“, you will learn how to become a professional computer programmer in months.

Myth #7: Computer programmers only work with computers, they don’t get to work with people.
The reality is that programmers need good people skills because they have to interact with both the users of their software and their team mates. So, people skills are highly valued in the programming industry.

The guy’s name is Kingsley Tagbo, which is apparently not made up.

New header image

21 Oct

Too much?

RMS is not a linguist

20 Oct

Tomorrow I’ll post an argument about whether or not the claims RMS (Richard “Not Milhous” Stallman) makes regarding freedom have justification, but today I want to talk about some things on which RMS is clearly wrong, and they all relate to terminology:

  1. “open source” is a perfectly good term for ethical software: RMS has admitted that “free software” is not a terribly satisfactory designation for ethical software, and in fact, there doesn’t seem to exist a particularly apt term in the English language. (Perhaps “freedom software”?) It’s true that the phrase “open source” was explicitly coined to play down the ethical and anti-monetary connotations of “free software”, but what about the words “open” and “source” are contrary to free software? The phrase is not sufficient to convey the ethical ideals, but it’s very clear by now that “free” is neither adequate nor sufficient to the job either. If Stallman wants to debate the primacy of ethical concerns over practical/technical concerns, I see no reason that can’t be done within the spacious confines of the term “open source”.
  2. castigating others for their use of terminology is rarely productive: First off, everyone in the FOSS community has heard Stallman’s claims already, and it’s not for lack of terminology discipline that many disagree with some of his positions. Meanwhile, those in the broader, non-technical audience have probably not heard these arguments; shaking this group’s confidence in its very vocabulary is not going to empower these people to enter a technical discussion. Second, terms like “intellectual property” and “digital rights management” may be somewhat biased, but they’re generally useful and established. If a term is really egregiously biased, fine, offer your alternative and support its use with argument, but by castigating your audience’s use of terms, you make it literally hard for them to agree with you.
  3. the operating system should not be called “gnu/linux”: In general, Stallman seems not to know how language works: “Linux” is a proper name, and there’s no good reason why it can’t refer to whatever the hell convention says it does. If “Linux” did just refer to a kernel, then we wouldn’t have need for ever saying “the Linux kernel” to distinguish it from “Linux”, yet we do need to make this distinction. Sure this naming is arguably just an historical accident, and of course the GNU project deserves credit for its work, but names are not about conveying correct origins. Names used to be about origins rather than convenience, and it wasn’t fun, e.g. people had names such as “Roger, son of William, son of James, son of Charles”. What good is freedom if it demands we spend all our time and cognition learning, saying, reading, writing, and typing the “proper” name for things? The only possibly good reason to insist on using the term “gnu/linux” is as a matter of advocacy–RMS suggests it might encourage people to inquire about the peculiar name and thereby learn about software freedom–but this won’t work for reasons mentioned in point #2.

I say all this generally supporting RMS’s ethical position. That position is not going to be advanced by being a dick stickler about terminology.

Sneak some cryptography in early

20 Oct

I’ve decided that the opening course, data representation, should sneak in the basic concepts of hash functions and cryptography:

  1. Number representation
    A discussion of bits and how they can be used to represent numbers.
  2. Text representation
    How bits can be used to represent text.
  3. Introduction to hash functions and cryptography
    How to create digital “fingerprints” and how to keep digital information secret.
  4. Data compression and integrity checks
    Using fewer bits and making sure you have the right bits.
  5. Image and audio representation
    How bits can be used to represent images and audio.

This makes sense because data compression relates to encryption, and hashing relates to integrity checks. In turn, lossless compression shows up in image and audio formats.

What I have in mind for this cryptography intro is something a lot like what Steve Gibson covered in several episodes of his podcast, Security Now. (The relevant episodes are numbers 30, 31, 33, 34, 35, and 37.) As for books, I haven’t looked too deeply into the offerings for intro crypto yet.

Only problem now is that I’m only really versed enough in these subjects to see that a broad overview of the theory should go here in the project, so I guess making this unit will have to be put off for quite a while until I can do some serious reading.