Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ulogix]

lately Im interpreting that we play on the server and my client only projects what happens in the server, ... ok, I would understand that, but how we play in the server. that's working already? can be made today?

To play on the server, each client needs to send it's player inputs to the server. That is what the new EventOnInput sync functionality is for.

[loop]

AAAAAAAHHHHHHHH!!!!!!
all right!!

now I got it.
I think both features should be together because one without the other I guess is not really good for anything.

thanks for the patience helping me understand the whole thing , ulogix

[ulogix]

AAAAAAAHHHHHHHH!!!!!!
all right!!

now I got it.
I think both features should be together because one without the other I guess is not really good for anything.

thanks for the patience helping me understand the whole thing , ulogix

You're welcome! Don't worry, it took me a while to work this through in my head too when the feature was first proposed a while ago.

I agree, the two items should reference each other via links so that people can clearly see that BOTH are required to make this work.

Fernando, please can you modify the opening description so that it references the EventOnInput sync features, since these two features are very closely related in terms of implementing network games!

Or maybe even merge them into a single new donation, describing both features together?

[3D Rad Developer - Fernando]

Fernando, please can you modify the opening description so that it references the EventOnInput sync features, since these two features are very closely related in terms of implementing network games!

I would prefer to present these features as independent. You don't need multiplayer features of other objects to use this SkinMesh multiplayer option. Actually you can use the existing network script functions to read user input on remote clients for example.

And when similar network features will be listed on the donation board, there will be no way to point out how to use this object with the others because there will be just to many ways to do so.

I'm also confident that whoever understands how these network features work will also see very clearly that they are related to other objects' network features.

1) what happens when you have more than 2 players connected... and player 2 quits... will the id numbers shift down to accomodated the missing player, or will they remain the same... (this was the biggest issue i had in coding my multiplayer stuff)...

The player number will not be the same player number that the 3impact engine provides. There will be some sort of 'abstraction' to prevent, for example, an EventOnInput associated to a machine from switching to another when a player leaves.

2) how will new players be handled once the simulation has begun running...

This will be up to the game developer. Current script functions allow you to 'monitor' the state of connected machines and take actions based on that.

I'm aware that existing script functions may not suffice, but please keep in mind that, due to the complexity of what we are developing here with these no-coding network functions, there will certainly be issues to solve after they become apparent after the first version of this functionality is released.

4) will skinmesh imposters be included in this implementation...

No they will not. Initially we need to keep things as simple as possible. What will be synched is SkinMesh orientaton/location only.

getting back to the this new feature... since this can already be done in 3Impact, i'm assuming that the funding will be for implementing the required stuff in rad to support what is already part of the 3Impact engine...  i must wonder (and please forgive me if i'm missing something) why this isn't something that can be done in a few lines of code... (maybe half the proposed funding), and in a shorter timeframe...

What you can do in 3Impact isn't exactly the same thing we need for 3D Rad no-coding-multiplayer features. The job will involve many hours (coding, testing, writing documentation etc). The cost is indeed well below the real cost. I'm happy with this though as I see no-coding-network support as extremely important to keep 3drad above competition.

[Mike_Hense]

i dunno Fernando... i've looked at this from all directions, and it seems as if we're approaching this in an a$$ backwards manner...

here's a new proposal... one which would require less development time and resource, will maintain a similar workflow to the one that RAD users are currently comfortable with, and will allow for seamless future additions to the object pallete with multiplayer in mind...

                                         the proposal

what about starting with 1- a generic net-connect object...  one that would:

1) take care of establishing the initial server or client connections... maintain the communication during the simulation... and if on the client would notify the server when the it was about to disconnect... and if on the server, would notify the entire simulation that the server has left...



next we'd need    2- a generic net-sync object... this would:

1) only read key strokes, mouse movements, and mouse button events from the connected clients... sorta like the current event on input object... 

2) if on the client this object would read its assigned id and use it to send these keystroke/mouse/ events up to the server... 

3) if on the server this object would be set by its associated client (set in the id property) as the data was read from the network...  or if the client id is 0,  the object reads the input just like the event on input object we now have...

4) enable and show each object linked to it on connection... disable and hide each object linked to it on disconnection

5) you would only need one of these for the client side project (you would need one each for each client expected to play, along with a copy of each object linked to it)


finally... you'd need (4) an object that would serve as a net global variables object that would act like a script VAR_xx repository... on the server, one each for each possible connected client... on the client, only one per client...  you could link different objects (skinmeshes for example) and use a designated group for location and orientation, animation state etc...

or if linked to a script, could read the VAR properties...


this would keep things in line with the way we do things now, and would be easy to understand for most of the non scripting developers while allowing the scripting capable developers the same freedom they enjoy now to use scripted logic across the wires...


--Mike

[3D Rad Developer - Fernando]

what about starting with 1- a generic net-connect object...  one that would:

1) take care of establishing the initial server or client connections... maintain the communication during the simulation... and if on the client would notify the server when the it was about to disconnect... and if on the server, would notify the entire simulation that the server has left...

Because 3D Rad, internally, is based on objects that exchange messages and these messages must be synchronized in a very elaborated way, letting a generic net-connect object share its stats with other objects would be extremely difficult and thus prone to bugs (that are a nightmare to fix in a multiplayer environment).
 
To perfectly fit 3D Rad design, each individual object must be able to deal with all network issues that are relevant to itself, and nothing else.

I have spent quite some time now on this matter and the above is the most cost-effective, flexible and stable design I could find.

next we'd need    2- a generic net-sync object... this would:

1) only read key strokes, mouse movements, and mouse button events from the connected clients... sorta like the current event on input object... 

2) if on the client this object would read its assigned id and use it to send these keystroke/mouse/ events up to the server... 

3) if on the server this object would be set by its associated client (set in the id property) as the data was read from the network...  or if the client id is 0,  the object reads the input just like the event on input object we now have...

4) enable and show each object linked to it on connection... disable and hide each object linked to it on disconnection

5) you would only need one of these for the client side project (you would need one each for each client expected to play, along with a copy of each object linked to it)

Apart from 4) I think this is very close to the planned EventOnInput ? If I understand you correctly, I believe the fourth option would be better achieved by adding network functonality to other event objects (which is planned).

finally... you'd need (4) an object that would serve as a net global variables object that would act like a script VAR_xx repository... on the server, one each for each possible connected client... on the client, only one per client...  you could link different objects (skinmeshes for example) and use a designated group for location and orientation, animation state etc...

This could certainly be useful. However the usage may not be easy for non-coders. How to specify what group of variables to use without scripting or without understanding vectors and quaternions?

Mike I understand that, as a coder, you aim to maximum flexibility (ability to join/leave in the middle of a game, enable/disable network connections at will etc), but the goal here is providing tools that truly let non-coders implement their own multiplayer games. We must keep things simple. We shall seek flexibility after we have solved the basics, I promise 

[Mike_Hense]

k... thx for taking a look at this.

i'm sure that i'm missing some points that would be better understood if i was privy to the internal workings of 3DRAD...

you wouldn't happen to have a spare one of those documents laying around anywhere... would ya...     


--Mike

[TinSoldier]

Im totally on Mike's side here.

When i proposed the idea of a no coding network resource, i thought what would happen is you guys would put out a pre programmed script object that would have all the functionality built in that would allows us to "drop in" the net resource and link it to other objects and then adjust some of the linked properties.

This seems to have been blown way up into to far more complex process than i thought it would be and time too.

With what iv read, it's looking like 6 months min to to start the network resource and maybe a year before completion and still more time to get the bugs worked out.

Wouldn't be a lot faster to just use the current scripting options and develop with that, maybe if needed adding additional script commands where needed....

PS From what mike has suggested it sounds alot like a new version of the the old 3dradv5.00 and early type of networking....

This i believe would be great, because the only problems with the old 3dradv5.xx were limitations like "peer 2 peer", too few variables, object limits ( as a whole project).

I was totally expecting a script based, no coding, drop in resource.

What im seeing sounds almost like a re-write of the 3drad engine to support non scripted networking option...   

[3D Rad Developer - Fernando]

Wouldn't be a lot faster to just use the current scripting options and develop with that, maybe if needed adding additional script commands where needed....

With the current script functions you can really do a lot. You have all the tools to achieve any sort of multiplayer game. But it is a task for an expert coder.

The idea here is instead providing tools that require no coding at all, without sacrificing flexibility.

Designing these no-coding tools isn't an easy task. But there's nothing easy in developing software truly works really.

The above is the best design I can imagine.

With what iv read, it's looking like 6 months min to to start the network resource and maybe a year before completion and still more time to get the bugs worked out.

Development time can be reasonably short. It all depends on funding and our ability to test the first 'network-enabled' objects proposed here and improve the design where needed.