I'm glad you like it, if I created a cloased game mode I'll upload a demo of it.
It won't be compressed so everyone who wants to can take a look into the code.


@Damocles
I'm using ONLY Skills for the communication.

Arrays just don't work for mp games, or you'd have to have an array for each player... *urgs*
Otherwise the data destroys itself and messes everything up.

Only for a few global things I'm using vars like for server logout or current level ID.

Skills are the key for mp programming, they give you the dynamic freedom you MUST have.


@msl_manni

Sure, I hope I can tell you clearly.

The main control skills I use:
1. _ActReq_ID - Clients send Requests to the server, those numbers stand for actions like move, attack, cast a spell ect., the server can create this IDs, too.
2. _ActReq_handle - A handle to an entity (if necessary) for example the actor I want to attack.
3. _Action_ID - The Server waits until an actor has finished his action, takes the _ActReq_ID, stores it into _Action_ID and sends it to everyone.
4. _Action_handle - The server takes or generates this handle (if necessary, depenting on the _Action_ID) and sends it to the clients together with the _Action_ID
5. _Action_target_X, _Action_target_Y, _Action_target_Z - This vector (if needed) can be created by the server (when attacking the server calculates where the actor has to move to, to attack) or the client (if he wants to move to a certain position), it is only send when needed and only used when the _Action_ID is an ID that needs it.

Now you know all skills that are necessary to control the game.
The _ActReq_ID and _ActReq_handle are only send to the server if a client makes a input (every 3 to 5 seconds or something like that.

So in normal case only the _Action_ID is send to the clients, sometimes the _Action_handle, too, and some cases the _Action_target_X skill-vector, too.

Movement target for attacks are being calculated by the server, the clients only tell they want to attack and which actor they want to attack.
Thus everyone recieves the movement-target position that is being calculated by the server and moves to this position.

- This is the key, why I do not need position updates! -


The server starts a function with proc_local() for each actor (player or enemy do not make any difference, everyone uses the same function), this function recognizes when _Action_ID is set and acts depending on the ID, from this point on, there is no multiplayer stuff needed any more, everything is done locally.

The function can turn the actor, calculate his speed, do his animation, start spell effects and all the other nice stuff.

Only the server calculates damage, evasion rate, critical hits and stuff and sends the damage numbers or text-IDs for text like "Miss!" or "Counter!", but this is only for visual purpose and has nothing to do with controling the game.


The big key that I found while creating this game is, that even in a multiplayer game, you do not have to do much multiplayer stuff.
-> You still can do most/ nearly everything locally! (and it works even better and is easier to program than sharing every single detail)


So let me tell you the data flow in simple steps:

- Clients send action requests to the server, or the server creates them by himself.
- The Server sends the action ID (which is equal to the action request value) to the clients.
- The clients act depending on the action IDs through a function started with proc_local().

Note: Every actor on each client does this, not only the player's actor!
Every enemy, every actor of other players and the own player actor, all use the same system.

The good thing about the GSTNet dll is, that you can send only a part! of an array.
This is very useful, since every player can fill its data into an array, and only send
the fraction of the array he is allowed to.
Also the server can send a specific part of an array to a specific client.

So you can make a 2 way communication with just two big arrays, with as many players/clients as you wish.
Only the indicated part (startindex-endindex) will be overwritten.

Also you dont have to rely on entities beeing "syncronized" on client and server,
with the known problems. The client just extracts all needed data out of the "gamestate" array.

I'm using the plain GS MP communication.
(A6.31.4 can only include 1 dll file I think, I tried to use mp3.dll and a shader thing and it was not possible to access both functions -> errors)

I often used bigDLL with sylex,populace and co.. never gotten a problem... mp3.dll is older than the bigDLL right? maybe use the newer one

We use arrays too, though in a different way: we have several arrays that sends up entity information with the first element being which entity the update is for and the rest being the information (position, emotes, etc) we wish to send. In a sense, we use the arrays as "channels" and have several channels for different lengths of information... so we have several n-element arrays that we use to communicate with the client and by choosing the right one, we don't seen more inoformation than we need. So using arrays, even clumsy "all or nothing" 3DGS arrays, can be done quite successfully.

I'm curious if you are using the mashed up client/server code or if you separated them so client only has client and server only has server?

(PS: Very original workaround to not having to send position updates by having your characters be still!!! LOL Very cool!)

But don't you have to have 1 array for one entity or at least let's say 20 elements for one entity and you define a 200 elements array it'll beenough for 10 entities?

Nevertheless it is a one-way-path, since the clients would overwrite data that was sent by other clients or created by the server, even if he already sent the date and both data packs run through the net at the same time (which happens quite often).

However I don't see that big advantage of arrays.
Skills belong to the entities and thus I can create as much actors as I want since the skills are created with them and I only have to care for one single actor because every other actor is treated the same way.
I don't have do differ between data blocks/ packeges as skills can't get messed up.

In my western shooter I used variables for some stuff, too, but I recognized it was quite difficult to handle and there were the problems when some access the same value and in the end it wouldn't have been necessary often since I could have done more stuff local. *lol*

I think skills are more handy.. =/


To the other question, I'm using Sever/ Client hybrid and clients that connect to it.

The GS multiplayer system is not buggy, everything works just as it should.

You should nevertheless have a look at the GSTNet.dll:

You can create much cleaner code, without all these workarounds required in 3dgs.

After you estableish the connection (and there is not commerial version limit, and
no requirement to start the client with a bat file in com...)
you can very cleanly control your communication.

You dont have to worry about proc_local function,
there is no need to create serverentities, and the required waiting period
for using the handle to them them. (I dont use servercontrolled entities anyhow)
You can adress clients simply by their ID number, or send the data to all clients.
(no entity pointer needet, just the pure number)
You can send information from the same "array-name" from the clients to the server,
without collisions. (since you can specify the part of the array to send).

You just need the name of the array, string or variable. There is no need to have the same
"order" on Client and Server code.

Fastlane uses a pool of arrays (of different size) for example, to put the data into it, according to the
amount of data to send with this update. With GSTNet you can use the same array, and just
transfer a smaller part of it.

No freaky control of having the same level loaded on client and server.
(A client might for example first want to load a menu level)

Free setting of ports (as far as I know)

It so much cleaner to develop with that dll. So you guys should have a serious look at it.

(and nfs42 is actively working on this multiplayer part, not like Conitec)

It really sounds nice I have to admit.

But does it work with A6.31.4, too?


At the moment I don't have any need for it, the communication of this game was quite easy anyway and I think it'll take some time until I start a new one.

well, just do some tests with the plugin. after a short while.. you can't stop
because it's so easy, so fast, I mean hell, even to start a server with A6 takes more than 5 seconds.
you said to me, you don't like to make network games, because it's time expensive to start a server, client, get the data to another PC etc.
but you will see that with the plugin, everything will be faster and easier.
there is a reason why a noob like me totally screwed up in A6 network but got a nice little bomberman online game working with populace. and the best is: GSTNet is way better than populace

At the moment I open 2 WEDs one with server settings and one with client settings to start.
It works well to test it on one computer, and I'm so experienced in the GS MP system that I don't have to do much mp testing anyway.

I wrote nearly the whole game before I did the frist testing.
Of course I had to make some minor changes to get it to work after I started with the testing, but it was no problem.

Nevertheless I don't have any plans for MP games at the moment.
The new Dragonrise Demo has to be finished and my browsergame needs time, too.

I think I'm just too lazy to get into those dlls now that I know how MP works.
I put so much time into it that I wanna use those gained skills..
At least.. I like to know what happens. =/

But I'm glad that there is such an easy way to do mp now, it saves me a lot of time since I had so many people on my feet wanting to train them....