As a proponent for open standards, I would like to open up discussion for a Open Standard Protocol for Real-time Network Games. I believe there could be a benefit to Game Developers for such a standard (if not already in existence). Lets discuss:

1. Using a standard like Open Game Protocol.
2. Using one or more existing protocols in the Internet Protocols Suite.
3. Developing an entirely new protocol.
4. Identifying Common techniques used in Network Games to consolidate into a single open standard.
5. Pros and Cons.
6. Whatever comes to mind.

What are the benefits? Seems inefficient and inflexible.

What are the benefits? Seems inefficient and inflexible.

I believe a Open Sandard Protocol for Realtime Network Games could provide the same benefits (1,2,3) that many other open standards promote:

• Interoperability (between different Game Clients)
• Vendor neutrality
• Efficient use of existing resources
• Greater use of automation
• Flexibility
• More options provide more opportunities to optimize
• Lower and manageable risk
• Robustness and durability
• Quality
• Increase available skills
• Better human communication

Of course efficiencies and flexibilities have to be incorporated into the standard. There are several techniques commonly employed in network games that could be rolled into a standard. Can you elaborate on what you feel would be inefficient or inflexible?

I thought this was an actual gameplay protocol. Looking through the spec, it's a protocol for communicating with a master server (providing a list of running game servers). It seems like this could be useful, particularly if you want to have a steam-like platform where players can launch different games/mods through a single open client.

Eh, master server lists are pretty trivial in most games. For the rest of us, we need very sophisticated handoff protocols that don't fit into a generalizable specification. I don't see much benefit here.

In fact, I see a lot of potential problems. Going over your list of supposed benefits:

• Interoperability. No way to control who accesses your server cleanly.
• Vendor neutrality. Screws with making a profit on games.
• Requires redeploying a lot of existing technology that is custom tailored for various games (e.g. the Guild Wars server handoff mechanism would never work under this kind of setup)
• Automation elides human control in critical details (again, look at Guild Wars; we couldn't use such a protocol because we have very specific requirements for how server handoffs work)
• Lack of flexibility. A standard defines what you can and cannot do; this inherently limits your ability to customize per game
• More options? This means more work. This isn't a benefit.
• Risk is higher because exploits in the protocol implementation are now widespread instead of localized to a single game infrastructure
• Robustness and durability are far from guaranteed until many years of iteration on both the standard spec itself and the widely-used implementations
• Quality is such an abstract notion that I don't even know how to go about addressing it. This claim is not even wrong.
• I don't know what you mean by "increase available skills."
• Improved communication is probably the only thing I can't find a problem with

Standards are like surgery. Not inherently good or bad, but misapplying them in situations where they are uncalled for can be deadly.

I believe a Open Sandard Protocol for Realtime Network Games could provide the same benefits (1,2,3) that many other open standards promote:

You are assuming there is market demand for interoperability here. I can assure you, there is not -- quite the opposite.


A few years ago, we tried to do that for a smaller subset of games -- persistent, interactive, virtual worlds. We even proposed a standard that would be comparatively simple to implement for most vendors, and that would keep user control server-side (important for commercial interests!) and that would achieve a useful but not perfect degree of interoperability, within the IETF. It went nowhere.
http://tools.ietf.or...ess-protocol-01

Interoperability can only be achieved when the subject matter is tightly coupled, and market forces require it. For example, the department of defense has used IEEE 1278 (DIS) for a long time, to great effect! Later standards to broaden and re-engineer this standard, such as IEEE 1516 (HLA) have not seen as good adoption, because it doesn't focus on solving the cases that actually need standardization.

Eh, master server lists are pretty trivial in most games. For the rest of us, we need very sophisticated handoff protocols that don't fit into a generalizable specification. I don't see much benefit here.

In fact, I see a lot of potential problems. Going over your list of supposed benefits:

• Interoperability. No way to control who accesses your server cleanly.
• Vendor neutrality. Screws with making a profit on games.
• Requires redeploying a lot of existing technology that is custom tailored for various games (e.g. the Guild Wars server handoff mechanism would never work under this kind of setup)
• Automation elides human control in critical details (again, look at Guild Wars; we couldn't use such a protocol because we have very specific requirements for how server handoffs work)
• Lack of flexibility. A standard defines what you can and cannot do; this inherently limits your ability to customize per game
• More options? This means more work. This isn't a benefit.
• Risk is higher because exploits in the protocol implementation are now widespread instead of localized to a single game infrastructure
• Robustness and durability are far from guaranteed until many years of iteration on both the standard spec itself and the widely-used implementations
• Quality is such an abstract notion that I don't even know how to go about addressing it. This claim is not even wrong.
• I don't know what you mean by "increase available skills."
• Improved communication is probably the only thing I can't find a problem with

Standards are like surgery. Not inherently good or bad, but misapplying them in situations where they are uncalled for can be deadly.


Very good counter points ApochPiQ, which also point out opportunities to develop solutions and incorporate them into the standard. I started seeking out such a protocol to help me deal with real-time network messaging in my game engine. I was surprised that none existed or I'm just not typing the right keywords in Google. I have investigated into many protocols on my quest.

In my opinion, an Open Standard Protocol for Real-time Network Games doesn't necessarily require developing a completely new protocol from the ground up. A High Level Meta-Application (for lack of a better term) Protocol could encapsulate one or more of existing Application/Transport Internet Protocols such as HTTP, SIP, RTSP, SDP over TCP/UDP. Its difficult for me to deny the possible value of a high-level open standard protocol in network games, when networking at its lowest levels is completely built on them.

[quote name='T e c h l o r d' timestamp='1310657431' post='4835295']
I believe a Open Sandard Protocol for Realtime Network Games could provide the same benefits (1,2,3) that many other open standards promote:

You are assuming there is market demand for interoperability here. I can assure you, there is not -- quite the opposite.


A few years ago, we tried to do that for a smaller subset of games -- persistent, interactive, virtual worlds. We even proposed a standard that would be comparatively simple to implement for most vendors, and that would keep user control server-side (important for commercial interests!) and that would achieve a useful but not perfect degree of interoperability, within the IETF. It went nowhere.
http://tools.ietf.or...ess-protocol-01

Interoperability can only be achieved when the subject matter is tightly coupled, and market forces require it. For example, the department of defense has used IEEE 1278 (DIS) for a long time, to great effect! Later standards to broaden and re-engineer this standard, such as IEEE 1516 (HLA) have not seen as good adoption, because it doesn't focus on solving the cases that actually need standardization.
[/quote]

hplus0603, I just read over LESS protocol...incredible! I can still see potential with LESS, maybe its a matter advertising, SDKs, Documentation? It may not be a big hit for Commercial Devs, but, I can definitely see Independent Game Developers adopting this standard into their games with support tools and docs in place. Do you implement LESS in your current games?

There already exists a widely adopted standard which accomplishes precisely the intersection of what you want to do and what is actually feasible in the real world.

TCP.