Teen Programmers Unite  
 

 

Return to forum top

MMORPG system

Posted by Mike_L [send private reply] at March 31, 2003, 06:51:22 PM

I feel that the basis of a Massively Multiplayer Online Role Playing Game is the "items" that one may accumulate. Everything in such a game could be expressed as a item: experience points, weapons, spells, skills and abilities, alliegances, and relationships with non-player-characters.

A system involving items needs to support several capabilities:
* Creation of items
* Verify item authenticity
* Transfer of items from one owner to another
* Destruction of items

I propose a system provides these capabilities through the use of public key cryptography.

In this system, an item consists of a block of text that stores information about the item, possibly in XML. Items are created by an issuing server (Issuer). This Issuer has a cryptographic key-pair: a public key and a private key. The Issuer generates an item for a game server and signs the item with its private-key. The Issuer also keeps a record of every item it creates. This database contains the item's unique identifier, and a hash of the item text.

Each player in this game system will have a self-generated public key pair. Each item's text contains the hash of the item's owner's public key. This allows a game server or player to query the Issuer and verify that the person really does own the item.

When a player goes to a game server and obtains an item, the game server signs a "transfer of ownership" file with its private key, and sends it to the player. The player can then sign this Transfer and send it to the original Issuer of the item. The Issuer checks that the Transfer is legit, rewrites the item to include the player's ID, sends the item to the player, and updates the database with the new owner. The item now contains the player's cryptographic ID and is thus "owned" by the player.

The player can then log off of the game server and go to another game. The player can submit the item to the new game server, requesting to use it in the game. The game server then queries the Issuer to check if the item is legit. If it checks out, then the user is allowed to carry the item into the game.

In order to prevent people from issuing their own stuff, game servers would have lists of trusted issuers. This would allow game operators to build worlds with varying levels of cohesiveness. A group of server operators would set up an organization that had one Issuer. They would then build a set of zones that use items from the Issuer. You could call such a system a game Universe. One could make his own game zone that would allow players from his favorite Universes to play.

Players should be able to user their items in a game zone, but the zone should also be able to destroy those items or take them away. To facilitate this, players would be required to transfer the ownership of their items to the game server when they sign in. This would allow the game server to destroy the item if it was used (like a potion being drunk). Also it would allow the game server to give the item to another player if the original owner dropped it or was robbed.

Trading would need to be done on a server that both players trusted. Safe exchange of items between two non-trusting parties is a classic cryptographic problem. It is related to voting systems and mutual disclosure problems. Thus, a special protocol would need to be supported by the Issuer to allow two players to trade items directly.

The defining characteristic in my system is the centralized Issuer. Obviously if the Issuer goes offline, then all of the items that it has issued are put in limbo. The items would be impossible to sell or use until the Issuer came back online. Also, if you were signed into a game, you would not be able to sign out of that game and get your items back until the Issuer came back online.

Identity theft would be a mathematical impossibility with this system. Each player would generate his/her own key pair. Nicknames and race characteristics could be assigned as items from certain Universe Issuers.

What I have described here is a kind of electronic currency system.

Another nice thing about this system is that it does not define the kind of game that is played. You could go to one server and play tic-tac-toe for gold coins. Then you could log on to your RPG game and spend the money. You could race sports cars to win swords or spells. Each game could have an entirely different client program, or a client program could be written that uses a virtual machine to safely run any game's front-end. This is what my Sebae project is intended to be.

Now what we need is a good concrete specification for this kind of system.

-Mike_L
Mar 31, 2003

Posted by regretfuldaydreamer [send private reply] at April 01, 2003, 10:57:14 AM

And you want us to either find a specification or write one?

Posted by CViper [send private reply] at April 01, 2003, 12:09:03 PM

What exactly is the goal of that system? Usually MMORPG's have a few centralized and trusted servers, which will handle all stuff with items/money/etc locally. As long as the client dosen't have direct access to those subsystems there isn't much he can do - except play by the rules.

As soon as something is stored on the client's systems, in his RAM for instance, he can go around and mess with it (the EQ guys learned that the hard way, as an example, movement speed was stored on the clients and not validated by the servers, making it possible to move under lag, but also allowing people to change their movementrates...)

So, I'd think, the key is store all important data on the (trusted) servers, or at least have a good way of validating it (for instance NWN can [to some extent] validate player characters ingame).

Also, as rdd said, this is all very interesting, but why did you post that? :D

Posted by mop [send private reply] at April 01, 2003, 05:17:37 PM

actually, a peer to peer system to do this would be an amazing and more economical way to host an MMORPG, you would have to store check sums to make sure that no one was messing with their clients.

But of course, assuming any sort of client side program will keep files stored on the same machine safely is absolutely stupid.

Posted by CViper [send private reply] at April 01, 2003, 11:59:39 PM

Peer to peer MMOPRG's? I see a few problems with that, for instance, lets say there are 100 persons in a specific area (zone or whatever you want to call it) - wouldn't that basicly mean that you'd be "directly connected" to all those poeple? So instead of sending your actions to one single server you'd have to send it to all those 100 people, which would be anything but bandwidth friendly (think of the poor guys/gals with 56k modems out there :p).

I though that peer to peer is mostly avoided in todays games, q3, nwn and all that stuff is also running over an centralized server...

Posted by DragonWolf [send private reply] at April 02, 2003, 05:29:30 AM

I've been looking at hybrid (P2P and C2S) MMOG networking systems and methods of getting around firewalls and proxies.

P2P by itself is more trouble than its worth in the case of MMOGs, but a mix of P2P and C2S would be very good. It can cut the running costs (mostly bandwidth) of the servers by a VERY significant amount and at the same time still provide valid and correct game data.

But there are many problems with P2P, such as if you choose to let a peer act as a server or report information about objects in the game world (such as the actions of the player character). Been looking at methods of validating P2P communications with minimum C2S communication.

I'm currently looking at the feasibility of a triad system, (3 P2P clients, whichever 2 give the same information use that data) but this increases network traffic and could be a hassle to program and sort disputes between servers (such as all 3 disagree)

Posted by Mike_L [send private reply] at April 02, 2003, 02:24:51 PM

The point of my system is that you could take objects from server to server, and the server's don't neccessarily have to be run by the same person or organization. Although the item files would be stored on the client computer, the checksum would be stored on the Issuing server. It is practically impossible for a client to change an item and have the same checksum. This means that any changes to the items will make them invalid. Also, each item file is signed with the Issuer's private key. It is practically impossible to modify a file and have its digital signature remain valid. This means that servers will be able to check the validity of each item. The server will need to query the Issuer only to determine that the object hasn't been sold, traded, or destroyed.

The system I am suggesting applies only to items. The actual game could be hosted on a single server, multiple servers (like EverQuest), or it could be a peer-to-peer system (like Age of Empires).

As for client-side cheating of movement and actions in game, I believe that is a lost cause. Because the client software runs on the user's computer, it will ALWAYS be possible to create a custom program that impersonates the client software. This is because any program that runs on your computer can be analyzed and modified. The server knows the client only by the data it receives over the network, so it is always possible to make a program that talks over the network just like the proper client program.

With that in mind, I think that it is safe to say that client-side cheats will always exist. The only real way to combat them is by checking the data from the client for inconsistencies. Laggy games make this practically impossible. I believe that in the future, as the networks get faster and faster, lag will become a non-issue.

The problem of items existing only on one server can be solved. I believe that a system like I described above will suffice. Essentially the system is for electronic currency (digital cash). If such a system were created, I forsee the creation of various large game universes, virtual banks, money exchanges, and economic systems developing on the Internet. Undoubtedly there will be someone willing to exchange government issued currency (like US dollars) for various digital currencies. This could facilitate micro-payment systems and easy subscription services.

These kinds of ideas make me ask myself why I'm studying electrical engineering and not computer science. =)

Posted by CViper [send private reply] at April 02, 2003, 02:58:48 PM

Project Entropia ( http://www.project-entropia.com/default.asp ) : I think you actually buy (virtual) items with real money (and if you sell 'em you get real money back). Otherwise the game is free of any costs, you can go ahead and download it. (I haven't tried it yet though)...

About the client side hack, some stuff can be thwarted by servers; players running scripts/bots instead of playing themself will be next impossible to catch.
But, take the speed hack in EQ for instance - it's pretty easy to check if the player moved more than some allowed distance during the last few ticks. As for cheating with items, the server should have a list of items the player has locally stored, so if the player tries to sell/... some item, the server would check if the player really owns that object (the player can tell the server to sell object X even though he dosen't own it - that would be cought by the server when checking the local copy of the players inventory). Obviously that would need an centralized server taking care of items etc.

Of course, there will always be some nasty "hacker" that's one step ahead of you...

Posted by Mike_L [send private reply] at April 02, 2003, 03:15:56 PM

Project Entropia looks interesting. But it also looks like a normal RPG game.

Can you make your own planet? Can people bring their stuff from the main planet to yours (and back)? Can you make your own server and client that uses items from the Project Entropia game? These are the kinds of things that an open item system would facilitate.

Posted by CViper [send private reply] at April 02, 2003, 11:36:48 PM

Mm, yeah, it's supposed to be a "normal RPG", except that you pay with real money :)

You must be logged in to post messages and see which you have already read.

Log on
Username:
Password:
Save for later automatic logon

Register as a new user
 
Copyright TPU 2002. See the Credits and About TPU for more information.