Scott Richmond

I disagree. The only reason most games don't do it is quite simply because it not economically viable - It often has very little value-add. Its totally doable, someone just needs to sit down and really nut it out.

Well there are ways to hide everything, but I'd like to think our goal here is to create a robust networking component. It is possible, Josh just needs to do the research and development. Which he is already in the middle of.

There will be noticable lag. Aren't you forgetting that there will be lag between you pushing the forward down when up against the barrel, and it actually moving. Between those two event the client has to ask the server what to do. The barrel will 'feel' really heavy because for a split second it'll have little to no movement. Not really acceptable. Sure it does. If you pick up a barrel with a grav gun or just your avatars hands, for example, then you'll be moving it around and expecting it to be interacting with the environment. RE: The two players acting on one object issue - Is it really that big an issue? Think about it. Physics isn't really a constant force in computer science - It is applied at every update. So say for example you have 2 players pushing a barrel into each other. In my mind I'd say the two players taking and giving back ownership in quick succession every time they update and realise they're colliding with the barrel. What a macro level this would cause and back and forth motion between the players. But in a live environment I'd expect you to see nothing as the forces match and nullify. If they were really big forces I'd probably expect to see some back and forth jitter as the forces over-coming each other. Does that make sense? Am I wrong?

With your method, one still experiences client<->server lag because the client has to wait on the server to tell it where the barrel is going. Thats not good enough. To answer your first question - The client throws the barrel and then relinquishes control back to the server as it no longer is interacting with it. Then the server gives control to client2 when it catches and stops it. Again, I didn't really think too much about this, so there are no doubt flaws. (eg, who applies the gravity?)

Thats why I suggest being able to transfer ownership of those drums to the client that is interacting with them for the duration of the interaction. That way there is no lag for the client and everyone else (server, other clients) see a seemlessly working interaction, albeit delayed by the server delay, which is fine because that won't appear to them as delay.

Too complex. The client should be performing physics on its own. The server should only ever be acting as the communication conduit, performing basic sanity checks, and owning the location of all the public objects.

It just needs to be architected better. For example: All objects have one parent owner, which can be actively swapped in and out. Eg, player controllers are almost exclusively owned by the client that spawned it. This client tells the server, and by extension everyone else, where it is. Similarly, objects such as barrels are most often owned by the server. Exceptions to this may be things like when collision occurs, the client temporarily takes control. Or maybe when a grav gun grabs an object. This allows instantaneous feedback at the client machine and removes perceivable lag to areas where it isn't really noticeable (watching other players move). Thats it on the most basic level. On top of that I guess you'd want the server to be running basic anti-cheating checks such as playerx.prevLoc - playerx.currentLoc != >10;. Or of course much more advanced stuff. And some simple animation smoothing on the client side to remove any correction jitter from server corrections. Note: This was just off the top of my head, I've no doubt there are problems I've not thought of yet.

There was a constant jitter for me and my 300 odd ping. I think what needs ot change is that the client should be assuming it got the physics right. In other words, don't ask the server that player x is moving here then update the client - Let the client tell the server where its going and wait for no one. Just have the server monitor the client movements and if they're outside of some magic tolerance level, pull the client back.

Well I guess that's cool. One less reason not to buy Macs I guess. Drivers will continue to be an issue for awhile yet I think.

URL is fixed.

Ah, so not a very good way to do things eh? I've actually started reading up a little on C++ + LUA. It seems LUABind does fairly well at creating an interface between the two languages and passing function pointers between the two. Leadwerks currently does the same thing doesn't it?

Give it a crack now.

Thats awesome Rick. Great work. I hope to use this tutorial soon.

Started a 3D server.

Not sure how up to date it is, but here is a good start: http://leadwerks.com/wiki/index.php?title=LEO_Class_Wrappers

I see I see. Since you have a master server, I wonder if it'd be a good idea to implement Reverse NAT. As it is key to any network implementation and I cry with rage every time I see a game that requires ports to be opened.

Josh - How is the port allocated? uPnP? And the server list - How is that generated? Are you actually running a master server serving that info?

Thanks for taking the time to clear this stuff up Lumooja, but a couple more things: If one uses LEO, does it still use the depreciated 'Framewerk' or the newer integrated 'Framework'?...or both?

Actually since Josh as fully integrated Framework now, shouldn't it be: UpdateFramework(); RenderFramework();

mmm, I think I just get a bit confused on whats best practice. I think that's where I find LeadWerks lacking at the moment - There are all these different modules and most of the tutorials use a mix of them. Doesn't seem to be a set standard. I mean surely LEO is preferred, so why not make them the only headers? More simple and less maintainance.

Some really good points Niosp, one thing though: The $200 license is for one seat only. So $200 per person on the development team.

How come there is no LEO? Is LEO officially supported?I'm beginning to get confused as to how all these different modules fit in.

Actually everything else matters. The majority of games are DX-based and therefore Win7 is better over-all. A quick Google found that D3 did indeed take quite a huge dive in FPS when run under Win7. Interesting. Ah well. Personally I've found any small problems like that are far outweighed by the advantages Win7 provides.

I'd take all these comments with a gain of salt, as Rick has suggested previously. A couple of things to take into consideration above and beyond what has already been said: Documentation - Leadwerk used to have awesome doco, but due to recent developments (v2.3) a lot of it is out of date. Still definitely workable and by no means a show stopper, but its still a problem. Though I understand the developer (Josh) is actively working on it. Industry Experience - You might find jumping into UDK will give you a better entry into the industry. UDK has some amazing tools Leadwerks doesn't come close to having. There is also a much larger community and therefore more support and examples to run with. Cost - Sure the engine is damn cheap. But you can go grab the full UDK right now for free and create to your hearts content. Only catch there is that if/when you go commercial, Unreal take a slice of the pie. Lumooja - I have to pull you up on the Win7 comment - The OS isn't slower at all, in fact by almost all accounts it is faster. This is based on personal experience and a number of benchmarks I've seen.

Not sure if its here in WerkSpace yet but it was quite popular back in the old forum: http://leadwerks.com/forum/viewtopic.php?f=32&t=1370&hilit=cut+wood