[DrunkenCoder]

Building a RPC mechanism ontop of a message based system really isn't that hard if you're already building a threaded app, basicly what you want todo is to move networking to its own thread.

That way you can get both the asynchronous updates you probable want anyhow from the server (updated world coords for example) and still use the same networking architecture for RPC calls. To implement the blocking RPC calls all you really need is semaphores.

Your application would look quite much like any serious gui application, one thread handling messages and additional worker threads.

I really don't se why one would execlude the other in this case, but maybe Im missing the problem.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Hajo]

@DrunkenCoder

I just don't have enough experience in this area, so I only have a very blurry idea in my head. So if I wrote something silly, it's just my missing understaning of the problem.

You're right RPCs can be build on top of message queuing. I forgot about that, I learned it some day, but never used the knowledge. Thank you for reminding me :)

One problem that I can solve with message queueing but not RPC is a broadcast action. Given a player says something. Then this must be tranferred to all clients who can hear (see) it. In an RPC system, the client must poll for such things regualrly. In a message queuing system the server can actively send an update request to the clients who need to be updated.

ATM I'm tempted to see message queueing as the more general and more powerful approach.

@LordGalbalan

"Array on server" - my plans are quite similer. I want the whole world to be stored on the server, all actions be executed there. The clients are just terminals to display the state of the world, handle UI for the player and collect player input. I'll use the clients to transform the input to an abstract representation (not sending a kepress or mouse event to the server, but something with a semantic like "pick up item" or "move north").

The basic data structure of my world is very array-like, it's a collection of objects that can be indexed by coordinates.

The 'only' question to solve is the communicatioon between clients and server.

[Hajo]

Björn, how far is the Mana World project actually?

I have H-World which is quite far in terms of data structures, scriptability and expandability.

I face the decision if I should rather join another MMORPG project and (maybe) create a variant of it that suits my needs, or expand H-World with the neccesary components.

Currently I don't really care about the open source/closed source thingy. This means I'm going to make H-World open source if this is needed, e.g. to implant an exitsing but GPLed networking system.

I'm completely unsure which route to go.

Can any of you help me, give me pointers of a sneisble direction? Existing H-World can be seens here
http://h-world.simugraph.com/

and downloaded here:
http://www.simugraph.com/forum/viewtopic.php?id=11&t_id=37

I wouldn't want to step back, I mean use a game system that provides less than H-World does. But I don't want to invent the wheel again. If there is a suitable wheel, I want to use it.

My dream:

Create an online gaming world, which basically just is a stage for players to act on. Several zones with different background (medieval, futuristic, steampunk ...) so that players can choose where to play. Allow players to expand the game (online) as some MUDs allow to. No story forced by the system on the player, but player-made sections well can have a story. Allow 'persona play' first of all - make a character, explore the world, meet players and use the stage to play.

[tcaudilllg]

I suggest, Hajo, uniting a part of H-world with someone else's work. So you have three options. :) In my experience, the cooperative option is usually the most effective. :)

[Bjorn]

Hajo:

Yeah if you would choose the GPL as your license you'd be free to look into our approach to message-based communication which we are currently building up and share our code.

Before you can make H-World a MMORPG game, I think it's pretty obvious you'd need to change it into a real time game first. I've heard you mention turn based / real time was basically a simple switch in your engine, but you'd still need to turn that switch and make sure the game still plays fine.

With TMW, work on the client has been going for about 1 year, the last near 4 months including me. There has been very little work on the server, because until now we've used eAthena. Last week I have made some progress with the network layer of the server, but it'll still be a long while before the client can actually connect to it.

Well I can't decide for you what to do, but I think the most interesting thing would be to try making H-World into a MMORPG the way you imagine it, while learning from other projects and sharing code where possible.

[DrunkenCoder]

[Hajo]

[Hajo]

[DrunkenCoder]

[Hajo]

Actually this is a theoretical excercise for me right now. I ahve no timeframe for this project. I might not even start.

I stopped all my projects, in so far that I retired from one completely (other people continue to work on it) and put the other on halt because I just can't go on.

I'm here to learn how such things usually are done, or how such things usually should be done. I'm intersted in the topic without feeling urge to code something.

If you have real experience with this, I'm bound to believe you. I have no experience. But I'll ask or question things that seem wrong to me.

My application (design) will transfer messages and objects, so unreliable transport (UDP) is only acceptable if the lower layers of the architecture provide retransmits and offer reliable transport to the higher level layers. I know "exactly once" is an unrealistic wish for real applications, but I need something fairly close to it - OTOH it's a game not a online banking application, so some flaws can be accpeted I think.

IIRC TCP will do that for me, at least to some extend. If the connection is gone, it's gone, and the client wil have to reconnect to the server. It's not a problem, becuase the server keeps the full state of the game and the client can be resynced after a reconnect.

Actually that why I spoke of a library. I hope (and belive) that such things can be encapsulated on the network layer and the application itself does not need to take care or even handle such things.

If I'm wrong, please let me know.

[DrunkenCoder]

It basicly depends on how synched your game world needs to be. For anything fast paced unrelaible transport is probably the only option to keep updates flowing fast enough to make it playable TCP while great at its thing simply isn't fast enough and you don't need the relaiblilty in something like quake.

But sure idially the network layer should be encapsultaed enough to provide theese services without the whole application being aware of the issues involved it would just be another message route or source.

If the game is fairly slow paced just using TCP and leave it at that certinaly is an option and will get things done it works wonderfully for muds and similar applications. I wouldn't try to create a realtime game with it though.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Hajo]

I didn't know that TCP is too slow for realtime games. This lead me to false assumptions.

How realtime would you consider Diablo 2?

It's fairly fast paced, yet seems to send only little data to the server.

Do you think it would work as a testbed if I make a simple echo TCP service and see how many clients I can run against it and track the message roundtrip times?

Maybe it could give me an idea of the thing. Yet I have no server outside my LAN so I don't know if that kind of test makes any sense?

[DrunkenCoder]

In a LAN enviorment you can get away with almost anything the problem with TCP traffic is that if it builds up it simply wont get dropped it will just build up and eventually trickle through UDP pacekts since they're unrelaible and really don't guarantee much since packet can not arraive, arrive out of order or you can get the same packet twice so you have to handle those situations but for just small updates that's really not a problem.

I would say that D2 uses UDP for most updates that simple takes the form of movement and uses TCP for anything that must be correct or doesn't require the higher bandwidth like chat messages potions spells attacks and resynching every couple of ms.

That's just an educated guess though.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Verious]

[Hajo]

I have about 20.000 lines of C++ code, so I can't easily switch to 'modern' OO languages that have inbuild object serialization. I wrote my own serialization support, but it only writes to files.

I'll have to write another subclass of the data output API to serialize into memory buffers. Not much of work, but a bit boring.

But the real problem is that I don't want to transfer full player/monster body data between client and server. This would allow the players to cheat by sending fake data back to the server. So serialization doesn't help, I need to change the UI to work indirectly, not directly on the map/world data as it does now.

And this is a rather big change.

I code Java pretty much, so I know how serialization works there. But that doesn't relly help in this case.

H-World uses zlib already to compress savegame data.

I'm going to make H-World open source, so you can take a look by yourself, soon. Sourceforge told me they need upt to two workdays to review the project, so maybe next Monday you can get H-World from sourceforge. The licence will be GPL.

I assume it will help in helping if you can see the code, so you know what is there and how it works.