On MapTap – digging up an old piece of software

One of the features that is scheduled for the next version of MapTap (2.3) is the ability to play Opposing Force maps. This is a feature that we thought it was already working, until tests for 2.0 conducted with members from the Steam community pointed out that it wasn’t.

Phillip did a bit of research, called a guy (who knows a guy – just kidding; the person contacted by Phillip was the expert) who knows a bit more about this game, and it seems that Opposing Force is launched basically as a mod for Half-Life. This spells bad news for us, since MapTap would try to launch the proper game with the “-game” parameter, to specify the folder where we unpack the archives installed.

That expert however provided a solution: create .pak files with our contents!

That posed however some challenges. You see, I wanted to delegate this functionality to an external tool – we do this to extract the .7z archives, by the way. Something like calling an exe and specify the folder and the path to the .pak file to be created as command line parameters.

And that’s how the search started for .PAK file tools. It didn’t end well though: most of them were Windows applications, with no support for command line parameters. Don’t get me wrong, they are probably great tools, it’s just none was easy to interface with from MapTap.

Things turned for the better when finding the dirpack utility; apparently it was part of the QUtils package and then integrated with qcc. I already tried my hand with qcc and failed to convince it to produce a .pak file, so I took the bite, got the code for dirpack and started my attempts to compile it.

Let me tell you one thing: changing compiler specifications is bad. I bet that the code could produce executables, if you compiled it with an old enough compiler. But after an hour of hopelessly trying to put together a decent distribution of djgpp to compile it, I gave up on that approach and went on a different route: adapt the code to the current compilers.

My plan was to build it using CodeBlocks (it runs on MinGW), so the changes in the code went for that direction.

After fixing the obvious (renaming functions already available, finding the right headers to substitute some includes), I faced the first issue: ScanDir.

ScanDir is a function that returns the contents of a directory. You can even specify function pointers to do a bit of filtering and ordering. And it’s not provided for MinGW.

A look at the dirpack code however tells that these features were not used: the function was called with NULL for both function pointer parameters. This meant that even a crippled version of ScanDir would do the job, as long as it returns the complete list of files.

So, roll up the sleeves and start coding.

With that done, I was able to get the dirpack.exe compiled. Next step? Start testing. And see it failed.

Indeed, the .PAK file would not be created. Debugging the code, I found that file reading failed: the number of bytes returned by the read() call was not matching the size of the file. After horribly hacking the code, I finally got my first .PAK file. And surprise – surprise, when unpacking it the files were unusable.

Where could this error come from?

It turned out it was caused by the open() call. You see, a good time ago, all files were opened the same, regardless of their contents. There was no distinction made between text files and binary files. But then, as the open() function was ported to various platforms with their compilers, new rules were added to opening a file. Mainly, the O_BINARY flag, that specifies that for the file to be opened, all bytes from 0 to 255 are fair game.

With that flag in place, file operations ran fine. The .PAK files created could be extracted and the extracted content be used. Dirpack.exe rose from it’s ashes. MapTap support for Opposing Force is now possible.

I will release the code changes done for dirpack: who knows, somebody else might want to integrate it in their app.

Portal 2’s Perpetual Testing Initiative versus map sites

One question Shawn (the chief of modinformer.net) asked during the interview he conducted with Phillip and I (available here) was in the line of: “How do you think the Portal 2’s Perpetual Testing Initiative will affect map sites like PlanetPhillip.com?

I was caught off-guard. I didn’t have a proper look at what P2PI (short for Portal 2’s Perpetual Testing Initiative) means. My answer was more on the line of “not too worried, people looking for quality and for a well reviewed map will end up on PlanetPhillip.com eventually”.

Thing is, there is a threat element, low at the moment, but still, present.

You see, P2PPI is the name for the toolkit that Valve released for Portal 2. It makes it very easy to make maps (a good thing) and it makes it very easy to publish them through Steam Workshop.

And it is the Steam Workshop that is the threat, not the toolkit itself. So I opened up the browser, and looked at the list of maps available for Portal 2, looking for well articulate descriptions and, if any, reviews. Guess what: in my quick search (about 10 maps from the top favorites), none had a description longer than 200 words. As for reviews, let’s be serious, the community is more interested in playing rather than reviewing.

To me this is weird. I mean the tools for writing reviews (a darned editor to post a comment) is there, but nobody bothers writing them. This places PlanetPhillip.com in a privileged position, of still being top dog in terms of reviewing custom maps. For people who like to read a review first then decide to play the map, PlanetPhillip.com is still the place to go.

However, there is still a good number of people who just download maps based on just the rating it has, and they will favor the workshop.

Here’s the thing though: I think that those people would have downloaded maps from filefront ot whatever other file sharing site rather than from PlanetPhillip.com

So the threat, as I see it, does not consist in the Steam Workshop stealing visitors from PlanetPhillip.com, but rather in making it more difficult for Phillip to gain more users. There is always the danger that Steam will hire a couple of people to do reviews for those maps, and publish them alongside the original description of the map. Now THAT would spell bad news for Phillip.

Alien Swarm’s SDK – a weak response to UDK

Oh my, first this article, and now this new one. One could say that I am holding a grudge against Valve.

In the article I mentioned before, I was complaining that Valve had no reaction to both Unity and UDK taking by storm the indie development market. Then, I was thrilled to read the following article:

Apparently, Valve is finally giving an answer to Epic’s UDK.

Unfortunately, the answer is weak. Read ahead to find out why.

They’re almost the same.

Now, I can understand why a lot of people got excited by the fact that both the game and the SDK were released for free. If you look at the broad picture, this is what you get:

  • the Source Engine runtime, for free
  • a set of tools, to allow the creation of user content for that said runtime
  • code related to the mentioned runtime, to implement other changes in the mentioned runtime

That’s not very different from the Unity package, right? I mean in Unity you also get an editor, a free to use runtime and some code samples. Same for UDK, right?

Except for one thing: distribution rights

After downloading both the game and SDK, I looked for an EULA. Something like this, for Unity, or like this, for UDK. I was hoping to find something, an official document that would tell me “you can make games on this and sell them”.

Unfortunately, the only thing I came across is the Steam’s subscriber agreement. And points (C) and (E) say it loud and clear: “You may use, reproduce and modify the SDK on a non-commercial basis solely to develop a modified game (a “Mod”) for Half-Life 2 or other Valve products compatible with and using the Source Engine”

This means no stand alone game. And definitely not being able to sell it.

That’s why UDK and Unity still win.

Because without the rights to redistribute the runtime along with the newly created contents, you can’t really say you’re making stand alone games. You’re still making mods, albeit for a (so far) free game. And for HL2 modders, the Alien Swarm and its SDK mean absolutely nothing. Because the market the HL2 modders are targeting already own HL2.

To DRM or not to DRM

The first DRM scandal was related to SECUROM. There were two things people complained:

  1. the fact that SECUROM uses root-kit technology, thus making uninstalling it a matter of formatting the hard disk.
  2. the fact that games installed it without at least notifying the users.

The second DRM scandal was related to Ubisoft’s Internet connection based DRM. There were a good number of arguments brought against it, I’ll just list some:

  1. the servers themselves are a single point of failure. They might not always be online, or they might be attacked. There is no immediate failsafe measure.
  2. internet connections are not 100% reliable. If you have a wireless connection, things are even worse. Kicking the player out of the game if the connection drops is too harsh. Again, no failsafe measure.

So, naturally, everybody asked themselves the same question: to DRM, or not to DRM.

And my answer to this is, without any trace of doubt in my mind, a rock-solid, unpleasant and hard to avoid … “depends”.

If you feel cheated from a YES/NO type of answer, put your heart and emotions in the freezer and read more.

Let’s start by splitting the question into:

  • What types of games should be DRM-ed?The initial proposal is to DRM everything. But you see, once the code arrives at the player, there’s absolutely no guarantee that the game will not be cracked. Or to put it the other way around, once somebody else besides you has acces to the binary code, it will be cracked.

    You may say that “well, still, it’ll take them a while to devise a good crack”. But eventually they do. And since tough DRMs WILL (not might, WILL) hurt customers, that’s not the way to go anyway.

    What does that mean in terms of what games should be DRM-ed? Well, what I’m trying to say is that DRM and Single Player games don’t make sense. All of the game’s components are in somebody else’s hands. So, I dare say, don’t bother adding DRM to Single Player only titles. Later on I’ll mention some exceptions to this, but the main idea is “SP = No DRM”.

    If you think that this “SP = No DRM” approach will lose you money, there are plenty of examples that say you’re wrong, and that “SP = No DRM” actually works:

    humble indie bundleThe Humble Indie Bundle event made over 1.2 million USDNow that we narrowed down our range of games, we can properly address the next question:

  • How should DRM be implemented?Let’s try to negate the complaints I listed above, in a weird attempt to obtain some key features of a good DRM system:
    • do not use root-kit technology. Make it easy for the player to ditch the game from their computer.
    • have failsafes. If the DRM mechanism relies on components that can fail, have failsafes.
    • avoid the single point of failure. Strike that one out, since this kind of philosophy should be applied everywhere.

    And since we narrowed down our search to games that have an online component, here is one example of well implemented DRM:


  • GAME = DRMThe DRM system IS ALSO THE GAME. No root-kit used. No need for a failsafe, since a downed server doesn’t mean that the DRM denied you of an otherwise functional game, but it rather means no game.

    This obviously works best for MMOs. In MMOs, by the nature of the game, all customers share an important component of the game, the servers.

  • Keep a database of your customers (Steam approach)This is how Steam and the other digital distribution platforms work. They know if you bought the game or not.

    The way it works for MP game is as follow:

    • the customer enters his credentials in the Steam client
    • the customer then starts the game
    • when connecting to a game server, the game server sends the customer’s credentials to the Steam server. If they check out ok (in terms that the customer does own the game), then the customer is allowed to join.

Both approaches share some similarities:

  • the game developer/publisher has some control over a part of the game. In the case of MMOs, the game server. In case of (b), you own the master server, that ultimately decides if a player can join a game server or not.
  • the DRM mechanism is implemented using those pieces of the game. No root-kits on your PC. No hardware scan that then limits the number of instals; heck with Steam, you can install the game on an unlimited number of machines. The key here is that you are not allowed to play simultaneously on more than one.

That’s the deal. Use a server-side DRM mechanism for the multiplayer components of a game. Don’t bother do add DRM to single player games, since all the software components needed to play the game will ultimately reside on the customer’s machine.

I mentioned an exception for DRM in single player games. That exception is: add DRM (1) if you already have it developed for other games and (2) it is a trivial effort to incorporate it and (3) it is light in terms of checks (think Steam, not SECUROM).