Wednesday, February 24, 2010

GNU / Linux Games. Current affairs.

So I want to do a research study on helping students to read using a role playing video game. The idea is to find a game engaging enough that the students want to play, but hard enough that they will need to refer to a text-based walkthrough to finish a lot of the tasks. The problem with this study, is that I don't have any money to do it. I know, imagine that, a PhD student without extra cash.
I would absolutely *LOVE* to use an open source game. I am familiar with open source games, and I can compile just about anything given enough time. I thought, "There has to be at least ONE decent RPG in the FOSS world I can use." Apparently I was completely wrong. Which got me thinking. Why are there no really good RPG's in the FOSS community? Are RPG games that complex that people cannot write one without massive corporate support?
I don't think this is the reason. I think that open source itself is part of the problem in developing a good RPG. When you start playing an RPG, the modern view is that you play the levels in order to learn the interface and mechanics well enough to go online. Some RPG's are purely online, allowing you to develop your character and learn the interface in an online environment. This is where the problem arises.
If you are developing a game for the open source community, you are probably concerned with a few things. First, you want the game to have a good plot. Second, you want the game to have a good interface and learning curve. Third, you want the game to have some kind of decent graphics. Finally, you want your game online.
Unfortunately, this last part is the issue. If you want your game online, you build a server, then you let the client-side programs connect to that server and voila! Blizzard Entertainment will tell you a different story. They have been working on their Battle.net system for as long as they have allowed online games to exist. Battle.net is a sophisticated server that validates the client program to ensure that no hacks or mods have been applied. Granted, they have gotten a little over zealous in the past (banning all wine-based play for World of Warcraft, for example).
If you don't think this is a problem, log into BZFlag for a few hours and you will come across a tank that is completely indestructible. I love this game, but I have found it to be unplayable on many occasions because it seems that captain unbeatable gets really annoying really fast.
Now, back to the developers. If I am developing a game that will most likely end up having an online component, I want to figure out how to ensure that players will have a fair and enjoyable experience. Since the developers will logically be focused on the local gameplay, the online gameplay will become an issue once the server structure has been developed.
Here is my call to arms for FOSS game developers. Get together a group and develop a bit of code that can be used to meaningfully validate the client software.
I don't know how to do this. I would imagine that Blizzard Entertainment can rely on knowing exactly under which conditions their software was compiled. This allows them, at the most basic level, to rely of MD5 hash codes or the like. But I also believe that there are more sophisticated methodologies that allow for checking of a modified source code. I obviously have no idea what that would look like.
So here is my call, please GNU community, develop a client verification engine that developers can use to verify their code. I know you can do it, and I'm reasonably certain that game developers in the FOSS community have enough to worry about with the player-side interactions.

3 comments:

brlcad said...

The main problem is that the game clients CANNOT be trusted. A client verification engine for open source games is fundamentally not feasible without at least a portion of the game being closed source. Even then, extreme care is needed to prevent whatever fancy super-secret challenge/verification system from being thwarted with a simple proxy client.

With access to the source code, a person wanting to cheat can simply intercept all communication with the client, passing any verification challenge (or all game chatter for that matter) on to the real "trusted" client to get the "trusted" response, then continue about with their meddlesome abuse. You cannot trust the game client and by being open source, we only make things easier. All hope isn't lost, though.

This is a topic that has been considered and discussed and debated in depth within the BZFlag community for the obvious problematic reasons you note. BZFlag is a bit of a special case in that it was originally designed as a LAN game where if someone was cheating, you'd walk across the room or down the hall and smack your buddy over the head with a book.

As a modern worldwide Internet game, that assumption obviously falls flat, but it's still a well known problem with relatively straightforward solutions (don't trust the client, verify state on server, etc). In the case of BZFlag, it's more a matter of completely reworking the game state to be server side, add exhaustive verification of client behavior, and verifying all network communication in depth. Not a "hard" task, but definitely not a quick task either.

You obviously weren't just talking about BZFlag, though. To break out the classic car analogy, consider trying to verify that someone isn't driving a car with a modified engine. I ask you to show me the car's engine, so you show me the good car's engine (you added a second engine). I ask you turn the car on and drive it and exceed the speed limit, so you respectfully do so but know better to not drive over the limit while being watched. There is nothing I can ask you to do with that car that will fail validation because at worst, you have the original car and can make it do what I asked to get the right response.

The only real way would be to physically take possession of the car myself to inspect it before watching you get into the car to let you drive it, and that's just not realistic with software unless you're physically sitting there with the cheater .. at which point whacking them over the head is much more simple and effective.

Cheers!
Sean

Jonathan said...

Do you think it would be possible to allow for a situation where only pre-compiled versions of a game are allowed on servers? So, only trusted compiles work, such as those from a Fedora or Ubuntu repository?

brlcad said...

How would you prevent unauthorized clients from connecting to a given server? How do you know that the client is the one that you pre-compiled? There is no authentication exchange that could not be spoofed with a proxy client that runs the real binary to get the answer to whatever validation you want to throw at it.

The problem is exactly the same as the car analogy I mentioned. How could someone verify it's not a modified car?

You could have the client download a closed-source binary core when they connect, but even that could still be thwarted fairly easily and there are all sorts of security implications with downloading a binary core on the fly.

The problem is fundamentally insecure. The client cannot be trusted.