Topic: Not being a game itself, but a tech demo... AGS networking!

[void]

I did not intend to make the testing something exclusive, so I put up the sources and binaries of the demo game above. While the second one contains the actual plugin, the first can be used for reference. I'm doing this plugin in my spare time and unfortunately I'm currently quite busy with other things going on.

However, the plugin is in a usable alpha state, it only seems that people aren't very interested about it and therefore not much testing appears to be done.

But I will inspect your suggestion about setMultitaskingMode(), thank you very much for that idea.

[Construed]

Ah, Well no problem.
I'll surely play around with a bit and perhaps extend upon it, I need a break from GrimQuest every once and awhile.

[deee]

I know it's a bit late to post in a 4 months old thread, but hopefully this is still being worked on.
First of all, I have to say that this is a fantastic thing and you did a great job, void.
Having multiplayer features in AGS games would be so wonderful.

After copying some *.dlls to the project folder, everything but the chat function (GlobalScript.asc(104): Error (line 104): undefined symbol 'PopArgInt'
) worked for me.
I would really love to work with this in my game project, but I have no c++ programming skills. Is there a way to access the plugin or to make a module out of it?
It would be great to synchronize custom events, like NPCs entering the room and walking around when a specific action is used, but I don't know if there is a way to do stuff like that in the normal script files without having to access the plugin directly.

[deee]

At least, if there was a way to send any variable's value from one instance of the game to the other.
Imagine Action-RPG-Adventures with Coop-Mode and Duels
Void, maybe you could make the user of the plugin decide what actions will be synchronized and when ?

[subspark]

Hey this sounds incredibly awesome. It's been a long time since I mucked about with coop in AGS!

Btw, I tried to download the demo game, but:
English Translation: "This file was deleted by the user or by an abuse message."

Could you re-upload a compiled binary for folks currently short of an AGS installation?
Thankies. 

[void]

Well, first of that you very much for your positive comments :-)

The sad news is that I accidentially lost the sources of this plugin. I basically did this in about 24 hours for a compo, so I didn't pay too much attention in making sure nothing gets lost. Sorry bout that :-(

Now over to the not so bad news: While this happened to be a research project, I began to put some more effort in it a few months ago and eventually started a new project from scratch. Reading your posts made me want to reconsider taking on this project again. At all there's not much interest in having some sort of cooperative gameplay style in an adventure game, but I still kind of like the idea.

The new approach at this is to make the network interface more open for customizations, while still doing the 'hard work' in keeping track of the game world. First of all I started out with a global caching and advanced event system that aims a bit beyond the native plugin API. You can, for instance, control objects that are far away and not only those in your current room.

As for networking, I'm thinking about a dedicated server. I did not like the fact that the host needs to start the game as well and players are only allowed to join as long as this game is open. It is needless to say that the technical gameplay and the style of playing an adventure game is much more slow and careful than a more common multiplayer game and I don't wan't to invent some Monkey Island Tournament here. So I guess the idea of having a dedicated server gives the game more time and therefore hopefully retains the spirit that we do love when playing adventure games.

Following your advice in terms of synchronization, I came up with a pretty flexible event system that allows components to be linked to certain actions if the user (better:game developer) decides so. I think that should do the trick. What do you think of that idea? Is it still something or am just totally wasting my time?

[Baron]

    Interesting project!  I think your disappointment at lack of enthusiasm may be due to this thread's location -you'd get much more exposure starting a GIP thread (since you are building an AGS game, after all). 
    I have nothing to contribute programming wise, but as an AGS developer I think it'd be great if you could communicate in real time between an AGS game on multiple computers through a server.  I know this has been partially done (i.e. the Awards Ceremony) but that only had more-or-less real time chat and coordinated movements.  If you could have chat, movement, multiple rooms (so players could be in separate locations), common inventory, variables and saved states even though no one is currently playing, that would be something worth building a game around.  But to popularize it you must make sure that it comes with some thorough documentation, or not many people are going to be able to figure out its true potential.

[void]

Just an update of the current progress. I tried to consider as many of the suggestions made in this thread as possible. I spent most of the time working on a plugin interface that allows me to make more advanced implementations to the engine (through many custom native and scripting events). Recently I started working on the network code. It really isn't that much of a problem since the basics have been set up and as time goes by I'm glad to see everythings slowly taking shape. I'm planning to install a git repository, but the code is not polished enough yet.

About your feature requests/suggestions:
- Chat is not implemented yet, but should be a piece of cake. I'm pretty sure that could be solved with a pure scripted implementation (based on the functionality provided by the plugin of course)
- Full synchronization of character and object movement will be there. The old plugin already had this feature and I'm currently on reimplementing it.
- Multiple rooms are also supported (due to caching the visited rooms in backround)
- Inventory will be synched. This is already implemented.
- Script variables are not synchronized. I clearly see no possibility of doing that without hacking the interpreter (which I'm not planning to do because of compatibility). But I could think of a couple of NetSet/NetGet functions allow the user to store primitive types (numbers and strings). However, this is absolute low priority right now.
- Save states might be synchronized. Didn't think about that too much right now, but I guess it's doable.

Although I'm planning to make this plugin as flexible as possible, there are certain things I'd like to automate. These things are most likely synchronization tasks. I guess this is the kind of hard work I'd like to take out of the game developers hands. If there is anything I forgot about, please let me know!

[DoorKnobHandle]

Since I've been working on something similar, I'd like to know about the more technical specifications, are you supporting TCP or UDP connections (or both?) How are you planning to do NAT punchthrough or does the plugin still require people to use a fake LAN environment such as Hamachi? Are you supporting blocking and/or non-blocking sockets? Oh and is it peer-to-peer or client-server?

[void]

Well, i think these questions are a little bit out of topic, because they're restricted only to the type of network connection and do not relate to anything regarding AGS. However:

- I'm using TCP. Adventure games do not need this kind of perfection in terms of timing. UDP would be overkill and needlessly complicated.
- I don't have any plans to implement such a thing like NAT punchthrough. This might be implemented later, but is not a big concern right now.
- It's a combination of both. The sockets are timed (blocked for a certain amount of time), but run in a seperate thread, so the game won't be affected at all.

[DoorKnobHandle]

So, this does mean that your plugin would be limited pretty much to adventure games made in AGS as far as I can tell. That's a shame, apart from that, it sounds like this is going to be very fun to play with (although I'm still not buying into the idea that true point'n'clicks can work in a multiplayer setting, but we'll see).

I disagree about NAT punchthrough though, I mean, to the average player it would make a HUGE difference if they could just hit the multiplayer button, find a game and play away just the way they're used to in any other game. Otherwise it's going to be kinda technical to set up games, you would have to share contact details with people before playing etc.

[void]

I disagree about NAT punchthrough though, I mean, to the average player it would make a HUGE difference if they could just hit the multiplayer button, find a game and play away just the way they're used to in any other game. Otherwise it's going to be kinda technical to set up games, you would have to share contact details with people before playing etc.

Well, honestly this barely has anything to do with hole punching. What you're describing is (in both cases) a server-client model. While your preferred choice also provides a static login server (that is a dedicated machine where players register through a static IP or DNS entry), the second model is a decentralized approach. In both cases, this has nothing to do with the IP-Layer or number of P2P internodes (such as a NAT), but with the network topology. You could do both without providing punch through. A login server is indeed a nice thing, but since it uses its own protocol and sits in a dedicated place it could be retrofitted anytime.

[DoorKnobHandle]

Well, I was asking about whether the plugin works peer-to-peer or server-client. If it was peer-to-peer then yes, you do need to NAT punchthrough assuming either player sits behind a router. But it sounds like you're going for the client-server model instead, would be really neat if you or anybody else was able to run a login server once your plugin comes out!

[Calin Leafshade]

You are misusing the term "NAT punchthrough"

NAT punchthrough is not strictly necessary for any networking model and very few games implement it because to do it right can be quite complicated and requires a central master server to do the matchmaking.

Most games simply rely on the user forwarding the correct ports to bypass the NAT or, alternatively, implementing uPnP which allows the application to do the same thing automatically.

[DoorKnobHandle]

I am sure that, for a peer-to-peer model (which is uncommon for games, admittedly), if either player is behind a router you will have to do your own NAT punchthrough to set up a connection peer-to-peer. In that special case it is absolutely necessary, I've done this before! I was asking about NAT punchthrough in the first place because I didn't know whether or not this plugin uses a peer-to-peer or client-server model.

[void]

Just for clarification: It doesn't matter what network model you choose to decide for or against NAT punchthrough. This is simply the step of readressing packets coming from a given subnet (i.e. www) into another most commonly local subnet (lan) using a bottle-neck node such as a router or modem. Since all connections made through this are addressed at the same IP, that is to say the public IP provided by the ISP, NAT routing is required in order to propagate the packet further over the "black box" subnet (LAN) to the correct receiver.

The reason I'd like to point this out is to make sure other readers of this topic won't be anxious about wheter the plugin uses a server-client structure with login functionality or not... just because - sorry to repeat myself, but I'd stick to the fact that this has absolutely nothing to do with NAT traversal.

[DoorKnobHandle]

I did indeed (wrongly) consider getting past PC and router firewalls to be a part of the NAT punchthrough process, sorry for the mess up on my part, that is what I was talking about!

But it really sounds like you'd rather keep the people here out of the technical innards of how your plugin works so as not to confuse them, so I'm going to shut up now! Sorry for the bother and good luck!

[void]

I'm sorry if I upset you. It is not that I don't want to expose technichal details on the implementation here, but the whole network thing got quite a bit beyond this topic, you know. I'd really like to discuss those details, but maybe this thread is just not a good place to do so. I hope you understand and do not feel offended by my response.

[DoorKnobHandle]

No offense taken, I literally got the feeling that it was in your interest to hide away a lot of technical mumbo jumbo from the average reader and, in the end, user of your plugin, which is understandable! I personally feel that, since this is the critic's lounge where, otherwise, art is examined and criticized in technical aspects, it's not out of place to talk about the technical innards here but it's your thread, I'm fine with, without or with a new thread!