Open Standard Protocol for Realtime Network Games

Started by
27 comments, last by Frank Taylor 12 years, 8 months ago

maybe its a matter advertising, SDKs, Documentation?


In my opinion, it's a matter of market requirements.

There exist many game networking libraries that makes writing networked games simpler (although, as with any distributed simulation, it's never "simple.") Most indie gamers just pick one, and run with it. Interoperability is not a concern or requirement, hence whatever you happen to pick (Unreal? Source? ENet? RakNet? Xbox Live!? ...) is good enough.
enum Bool { True, False, FileNotFound };
Advertisement

[quote name='T e c h l o r d' timestamp='1310666758' post='4835355']
maybe its a matter advertising, SDKs, Documentation?


In my opinion, it's a matter of market requirements.

There exist many game networking libraries that makes writing networked games simpler (although, as with any distributed simulation, it's never "simple.") Most indie gamers just pick one, and run with it. Interoperability is not a concern or requirement, hence whatever you happen to pick (Unreal? Source? ENet? RakNet? Xbox Live!? ...) is good enough.
[/quote]

I agree that Interoperability is not a concern or requirement, at least not yet. However, I predict future network games will demand it. The glorious paradigm shift will be marked by the date Dragon Age 2022 and Halo XIII converge into a new experience known as Day of the Dragon Halo. That's right, two separate game clients fused together in cyberspace to create a new game experience, sharing players and resources in realtime.

I'm interested in learning more about LESS and will be studying the spec later tonight. Perhaps, if more indies use it, maybe it will become popular enough to be adopted as a global standard.
I don't get the idea. Is the idea to be able to query a server for information? I'd look into an XML based solution and just define some basic output formats that a game could use. Then if anyone wanted they could query and obtain this XML document with the information and parse it. However this would be game dependent information obviously since you can't support every game type feasibly.

If the goal was just to display information then I'd suggest the server return an HTML or custom XML based layout page that a program could interpret and render. I've read the whole site now and I'm still confused what this is trying to achieve or what problem it's solving.

I agree that Interoperability is not a concern or requirement, at least not yet. However, I predict future network games will demand it. The glorious paradigm shift will be marked by the date Dragon Age 2022 and Halo XIII converge into a new experience known as Day of the Dragon Halo. That's right, two separate game clients fused together in cyberspace to create a new game experience, sharing players and resources in realtime.


I really can't tell if you're being serious here.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


... I predict future network games will demand it. The glorious paradigm shift will be marked by the date Dragon Age 2022 and Halo XIII converge into a new experience known as Day of the Dragon Halo. That's right, two separate game clients fused together in cyberspace to create a new game experience, sharing players and resources in realtime. ...


So basically you know full well that you are presenting a solution to a problem that doesn't exist.

You are hoping that a decade from now, your incomplete idea will be a solid solution for a non-existent problem that you hope will get adopted as standard, coming from a nobody hoping to transform a longstanding networking engine that already works and doesn't need the change, replacing a comprehensive and decades-large collection of tools and documentation and corporate knowledge that were developed by experienced and tenured engineers that have no compelling business need for the change.

That in itself is just amazing. Not in a good way.


Yes, there are disruptive technologies. There are always new concepts that emerge as must-haves that all the big systems feel they must adopt if they want to continue growing. There have been a lot of them, moving away from direct dial multiplayer to LAN and later to IP-based games, adding VoIP, cross-title integration for friends and communications, social media integration, cloud storage of save data, and more.

But this is not one of those. This is an incomplete solution to a problem that has been completely solved in many different ways for decades. This is something the market has no need for; and if there ever becomes a need they will immediately turn to existing complete solutions or develop their own with relatively minuscule cost.


...

Your biggest hurdle will not be the technical one. Any reasonably experienced network programmer can put together the protocols as described. That's not hard. In fact, it is so easy that there is no need for the solution in the first place.

No, the biggest hurdle will be trying to convince the owners of multiple successful multi-million-dollar franchises and directors in multi-billion-dollar publishers that they should throw out their current successful networking engines and game clients and server farms and expansive data centers that have evolved over many years --- existing systems that work well and have a long track record and are filling their bank accounts --- that they should throw it out and invest a fortune to adopt your system instead.


Good luck on that.

[quote name='T e c h l o r d' timestamp='1310676365' post='4835429']
... I predict future network games will demand it. The glorious paradigm shift will be marked by the date Dragon Age 2022 and Halo XIII converge into a new experience known as Day of the Dragon Halo. That's right, two separate game clients fused together in cyberspace to create a new game experience, sharing players and resources in realtime. ...


So basically you know full well that you are presenting a solution to a problem that doesn't exist.

You are hoping that a decade from now, your incomplete idea will be a solid solution for a non-existent problem that you hope will get adopted as standard, coming from a nobody hoping to transform a longstanding networking engine that already works and doesn't need the change, replacing a comprehensive and decades-large collection of tools and documentation and corporate knowledge that were developed by experienced and tenured engineers that have no compelling business need for the change.

That in itself is just amazing. Not in a good way.
[/quote]
Don't shoot the messenger! LOL

I'm not trying to solve a problem, I'm trying to create possibilities. I have no expectations. Of course its an incomplete idea, that's why I'm here to discuss it, develop it. I'm a small independent game developer ...a nobody, but, at least I have my freedom. Unlike some, *rolls eyes* I'm not confined to any particular paradigm, methodology, process, procedure or idea.

I'm not trying to solve a problem, I'm trying to create possibilities.

Create possibilities for what? In your eyes what are the possibilities for such a protocol? Also you call them possibilities, but really you're talking about future problems. What are some use cases you foresee where this could be used? I'm not gonna lie solving problem for hypothetical future scenarios ends up running into the realm of "uber flexible" solution since it lacks requirements. Without requirements your design is flawed usually. There's a reason people have procedures such as software design for analyzing and solving problems. It ends up not wasting time. :unsure:

[quote name='T e c h l o r d' timestamp='1310676365' post='4835429']
I agree that Interoperability is not a concern or requirement, at least not yet. However, I predict future network games will demand it. The glorious paradigm shift will be marked by the date Dragon Age 2022 and Halo XIII converge into a new experience known as Day of the Dragon Halo. That's right, two separate game clients fused together in cyberspace to create a new game experience, sharing players and resources in realtime.


I really can't tell if you're being serious here.
[/quote]

The troll is peæking here =]

[quote name='T e c h l o r d' timestamp='1310676365' post='4835429']
... I predict future network games will demand it. The glorious paradigm shift will be marked by the date Dragon Age 2022 and Halo XIII converge into a new experience known as Day of the Dragon Halo. That's right, two separate game clients fused together in cyberspace to create a new game experience, sharing players and resources in realtime. ...


So basically you know full well that you are presenting a solution to a problem that doesn't exist.

[/quote]

Well, the HLA standard is intended to tackle that specific problem. And it is a actually already a common scenario in the serious gaming industry. I think it's possible to imagine a game (or more like a game world) that you can connect to using different clients. I don't know about Dragon Age and Halo, but say something like WWII online, you could have different specialized clients for different weapon types (infantry, tanks, planes etc), or different levels (tactical, operational, strategic).

Back to the original question, I think you should take a look at HLA. As jon said above, it does not standardize the protocol, only the API signatures and some rules governing the federates in a simulation. Maybe one way to approach this is to fill in the gaps (specifying an actual communication protocol, or implementing a library). There are also efforts to "standardize" the object model used in HLA that might be worth checking out (http://www.boms.info/).

openwar - the real-time tactical war-game platform

Well, the HLA standard is intended to tackle that specific problem. And it is a actually already a common scenario in the serious gaming industry. I think it's possible to imagine a game (or more like a game world) that you can connect to using different clients. I don't know about Dragon Age and Halo, but say something like WWII online, you could have different specialized clients for different weapon types (infantry, tanks, planes etc), or different levels (tactical, operational, strategic).

Back to the original question, I think you should take a look at HLA. As jon said above, it does not standardize the protocol, only the API signatures and some rules governing the federates in a simulation. Maybe one way to approach this is to fill in the gaps (specifying an actual communication protocol, or implementing a library). There are also efforts to "standardize" the object model used in HLA that might be worth checking out (http://www.boms.info/).[/quote]
[size="4"]
Kudos to you blutzeit!!!

Although, my terms are completely off (as I suspected from the beginning of this thread), HLA is what I'm pursuing. The High Level Architecture (HLA) is a general purpose architecture for distributed computer simulation systems. Using HLA, computer simulations can interact (that is, to communicate data, and to synchronize actions) to other computer simulations regardless of the computing platforms. The interaction between simulations is managed by a Run-Time Infrastructure (RTI).

Amazing...

This topic is closed to new replies.

Advertisement