The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Interchangeable Video Game Parts

The notion of reusable gaming worlds.

Often when I do play video games it will be on servers that use custom maps/worlds. These vary greatly in quality, from top notch to bottom of the barrel, but mostly the people loyal to the server do their own quality control and the better the server, the better the average quality is.

But the experience is still limited. Most of the maps are not open source. The assets generally cannot be migrated from game to game, particularly if the gaming engine is separate.

There’s a great opportunity for assets to be reused, improved, and evolved over time, to the point where whole, seamless worlds of assets could be constructed and used by many games.

I’m not talking about having a consistent world across multiple games, though that’s a possibility as well, but just sharing the world.

This already happens on a limited basis. As said, custom maps are used on a variety of servers, some of which have their own custom game modes. Other maps have been released by their authors for multiple games or multiple versions of the same game. Or multiple versions of the map, with variations.

High quality maps don’t come easy, they require a lot of exacting work. And then testing. Reworking. But the idea that there should be an equal number of high quality maps as there should be high quality games, to me doesn’t add up. My understanding is that the act of creating the game world is one of the most laborious parts of producing a game. Even dud games may have beautifully architected levels.

It just seems like a big shame to waste these levels, by having them used once or twice and never again.

Sound effects for films have been reused as long as they’ve existed. There are some famous ones, and others that are not famous but still recognizable if you listen. Point being that reuse doesn’t necessarily detract from the entertainment.

There are tangible benefits to reuse beyond the fun of the games. They help level the playing field for game design a bit, where at least some of the code for handling the maps is free and open. They give more designers an opportunity, as they can market themselves to a wide, inclusive gaming community at once, rather than one small niche of a particular game at a time.

It may also help to keep old environments alive. I’ve not played the likes of Quake or Doom in years, but I still recall bits of their levels. While I doubt any risk of these games being lost forever, I also doubt they will be often adapted to new games except through a down-in-the-dirt recreation from the skybox in (or maybe from the spawn entities out?). It just seems like being able to pull up one of those worlds and stroll through could and should be as easy as something like Google Earth.

NatSAg to Unveil Webapp for Putting Your Phone in a Global Context

A look at the issues surrounding the recent revelations regarding domestic spying.

Framing Debates

When we debate an issue, we do it within defined bounds. The bounds, or terms of the debate, act like the field in a sport. Those seeking a biased outcome will seek a biased definition, and we usually see the corporate media do their debates with poorly defined bounds. Like children learning to dance by watching drunkards and strippers, our own debates come out confused.

This pattern, it repeats. The corporate media only occasionally goes to the debate narrative, but often for the opposite reason you would think. You might think debate kicks off when someone wants a change. In our society debate does not allow for change.

Debate in the USA comes out like a drunk dancing. Stripper if you throw the practiced media narrative debates in the mix. Television time slots artificially limit the debate time. Guest bookings and sponsors and the like keep the advocacy from being too risque.

Debate comes as a consolation prize. Society saying no in a softer, gentler fashion. But with some issues, gay marriage for example, the debate actually moves the world.

Because you can’t really frame the debate. They tried. Civil unions. Everything except for the name of marriage. And that erodes pretty quickly once civil unions exist.

The other debates have moved some places. Gun control has moved a lot of places. Universal health care. Education.

The Cannabis debate slowly moves the world away from drug prohibition (rather, away from prohibiting certain drugs, where others have been available all along).

But the media does not follow along. They come along like some know-it-all cousin: “never happen.” It happens: “toldya so.” They do not provide the forum for change. The change comes, and they talk about it.

Big Brother from an Authoritarian Mother is Watching

Anyway. The National Security Agency (NatSAg for short) brings the latest debate. They accidentally asked the courts for all of our phone records. And those nuts at the court said, “okay.” Well after they bought enough hard drives to copy all the data in perpetuity, they have finally come to ask us what we think they should do.

Boy oh boy. They have themselves one of those old-fashioned dilemmas, don’t they. They can spy on us, gathering all information on our whereabouts, whatabouts, and whoabouts, our whyabouts, howabouts, and whenabouts. Or they can go fuckthemselves. It’s really quite a pickle.

The media seems a bit untorn about the whole thing. As do the overseers in the Congress.

One of the prevailing debate lines reads, “if you are not doing anything wrong, you have nothing to worry about.” But my mother always told me that, “two wrongs don’t make a right,” so it looks like that one doesn’t pass the mom-said-the-opposite test.

Others say, “oh, but what if the threat is really bad,” like those scenarios they try to justify torture with. The same childish game of would you eat shit for a dollar? A million? To be able to fly? Again, a framing error. We have options besides sacrificing our babies to idols.

Outrage

A lot of the fallout from the NatSAg revelations comes in the form of people mad at Obama, or worrying that the American people will take this lump. They fail to recognize that outrage does not necessarily spark outcry. That it takes time to manifest a reformation.

In Turkey they have recently seen major calls for renewal of their government. Like much of the Middle East, the protests did not come from a carefully thought out plan, or some major revelation akin to the NatSAg story here. Instead, the initial protests road on a smaller protest of a less visible issue.

The people hold the outrage, looking for somewhere to put it. Eventually they find that place, for good or ill.

But no, the American people may seem apathetic about spying, drones, inferior health care, inferior education, inadequate and overcomplicated tax codes, etc. They just want reform. They will rise up in protest in time, on some unknown H-hour, D-day. It may be a very different issue that brings them out initially. But like Turkey, once out, they will call for their rightful reforms.

Cleaning $HOME: XDG Base Directory

An overview of my experience cleaning out my home directory to improve its compliance with the Freedesktop.org XDG Base Directory Specification.

Freedesktop.org: Standards: XDG Base Directory Specification is the main document at hand here.

Every now and again the folks that work on free software decide to rearrange a specified or de facto standard directory/file structure with an eye on improving the state of the platform. XDG-basedir is one such attempt, but there have been others like the advent of /run.

The XDG-basedir basically stipulates three locations:

  • $HOME/.config or $XDG_CONFIG_HOME
  • $HOME/.local/share or $XDG_DATA_HOME
  • $HOME/.cache or $XDG_CACHE_HOME

These are meant for your configuration files, data, and caches. These locations provide for some flexibility and improved organization over throwing everything in your $HOME. For example, your caches may be kept in a virtual path that points to RAM or on a SSD that is faster than your regular storage. Or your configurations may be on some networked disk.

Lots of applications support this specification in some way, though some more than others. To take advantage of this specification requires first looking to see what dot folders and dot files (ie, those named like .foo) exist in your $HOME. While you’re at it you may look in the above-mentioned folders to see what applications have already set up shop in their new locations.

Some applications will have moved their baggage themselves. Other applications implement the standard to whatever degree, but give precedent to the old location, the old dot files. They do this out of pragmatism. They don’t have to write a migration scheme, and they don’t confuse their long-term users who may not know or want to know about these new locations.

For these applications, moving the files yourself (or if the data/configuration/cache does not matter, simply deleting the existing file(s)) works fine.

For others, those that do not support the specification, you can often still move them if you define their environment to point to the proper location(s).

An example of the latter is Mercurial, the distributed source control system. It does not support XDG-basedir, but it does support the environment variable HGRCPATH. By properly setting it, export HGRCPATH=${XDG_CONFIG_HOME}/hg/hgrc (or the full path if you do not have XDG_CONFIG_HOME defined), you get the benefit of the specification without Mercurial actually supporting it.

In cleaning my own $HOME I found this sort of fix was useful for about six applications including vim and gnupg.

Still other applications do not support an environment variable to specify where their files live. Some of these will accept configuration file locations from the command line. For these, setting shell aliases or functions may help. I found this useful for only one or two applications.

Some applications have support for it in versions newer than I have installed. I let these wait, glad to know of the effort.

And quite a few applications have open (or closed) bugs for supporting XDG-basedir. In most cases this is less about the technical work for the specification and more about deciding if and how to support it. At least a handful of the applications I looked at were reticent to support it at all. Others said support would be welcomed given enough background to show what would/not break and with a patch available.

But several argued about how far they would support it. This mostly came down to applications willing to move their lot into $HOME/.config (or wherever $XDG_CONFIG_HOME), but not split out cache and/or data. It seemed this was more often argued against for portability reasons (ie, they support Microsoft Windows operating systems and want to allow their users to move their files between them or have them on one common drive without issue).

And in rare cases files are hard to nail down. They sort of configure, but they’re sort of data. Or they’re sort of data, but they’re sort of cache. (Hopefully never all three in one.)

On the whole I was able to reduce my number of dot files by about 15, and the number of dot directories by about 60.

At least a full half of the files and folders I lost were obsolete entries from applications that I no longer use. Another chunk were applications that wrote their configurations even though I used all default options. The rest were from applications that now support XDG-basedir or had other acceptable workarounds for moving their files.

I find this an interesting topic to look at given that the change to applications is not overly complex, but it affects a wide variety of applications. I also like having a cleaner $HOME as it makes finding things easier.

Maybe my next step will be to audit my XDG directories as I’m sure they contain some files from applications I no longer use.