Modify message

Subject:
Message icon:

Attach:
(Clear Attachment)
(more attachments)
Restrictions: 4 per post, maximum total size 1024KB, maximum individual size 1024KB
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
Type ot the full word: TUR**:
Finish the word: Turok 2: Seeds of ****:
Finish the word: Turok Dinosaur ******:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: PNill
« on: May 09, 2016, 03:22:08 AM »

Thanks for the input,
I probably don't have much more experience then you do with multiplayer networking and I feel as if protobuf would just make things easier in terms of transferring data I use it in another of my projects and from what I've read on gamedev.net it's actually kind of preferred as its fast and you can store data how ever you'd like.

The other project I'm working on (halo2) does use bitpacking and it's own custom read/write serialization, I've just never gotten too deeply into processing data like that in C/C++.

I've got stinkee on Skype feel free to add me, tddeadlydata
...

Yes, protocol buffers are fast, but I don't feel like they're quite fast enough for an action based game like a FPS. I'm not sure if the networking protocol is already defined for Turok or if you're just rolling your own in the mod, but if you're rolling your own you probably want to send player inputs at no less than 40 times a second to the server and state updates at least 30 times a second. Protocol buffers work pretty well toward serialization of data for use in things such as a small scale rpg MMO where state updates are less frequent but latency doesn't matter so much. Even at 30 state updates a second you're probably going to ultimately have at least 100ms latency for a client to see other player actions just from state interpolation(extrapolation is different but also not a good idea for an fps game) buffering before you even add in player ping.

I know of some great articles for network data serialization, you don't even have to create separate read/write serialization functions just a single "Serialize" function that reads or writes data from/to a bitpacker depending on an IsReading flag, that eliminates hard to track unaligned serialization function bugs, and it doesn't take much time to get running. I can provide you some easy to use classes to use if you like, that way you don't have to spend time setting up protocol buffers or learning a new library.

With this method your data layouts and definition would be represented via a regular ol' struct in your code, no crazy file generation or huge library to deal with.

Google protobuf isn't very hard to implement but I do understand what you're saying,
From the research I've done there's two goals whether it be FPS or MMO.

1) Deliver the data as fast as possible.
2) Deliver as small of chunks of data as possible.

That being said the idea is to calculate only the values which may have changed since the last send before sending the next packet in order to make sure the size of the packet is as small as possible which is why I agree with you on the bit packing, I'm not sure how efficient protobuf is in terms of 'compression' of the data, I just figured it'd be a decent choice considering I'm already familiar with it.

And I'd have to argue that even MMOs tend to send a shit ton of data, sometimes even more then action fps games do.


Also,
Turok itself does not have any networking capabilities this is being done completely from scratch based on data gathered about the players the obvious solution would be finding places in code where events are triggered (animation update, movement update, view angle changes) then build an event handler around those storing the data and sending it periodically based on available data if it's different from the last send.
Posted by: djdduty
« on: May 07, 2016, 10:04:46 PM »

Thanks for the input,
I probably don't have much more experience then you do with multiplayer networking and I feel as if protobuf would just make things easier in terms of transferring data I use it in another of my projects and from what I've read on gamedev.net it's actually kind of preferred as its fast and you can store data how ever you'd like.

The other project I'm working on (halo2) does use bitpacking and it's own custom read/write serialization, I've just never gotten too deeply into processing data like that in C/C++.

I've got stinkee on Skype feel free to add me, tddeadlydata
...

Yes, protocol buffers are fast, but I don't feel like they're quite fast enough for an action based game like a FPS. I'm not sure if the networking protocol is already defined for Turok or if you're just rolling your own in the mod, but if you're rolling your own you probably want to send player inputs at no less than 40 times a second to the server and state updates at least 30 times a second. Protocol buffers work pretty well toward serialization of data for use in things such as a small scale rpg MMO where state updates are less frequent but latency doesn't matter so much. Even at 30 state updates a second you're probably going to ultimately have at least 100ms latency for a client to see other player actions just from state interpolation(extrapolation is different but also not a good idea for an fps game) buffering before you even add in player ping.

I know of some great articles for network data serialization, you don't even have to create separate read/write serialization functions just a single "Serialize" function that reads or writes data from/to a bitpacker depending on an IsReading flag, that eliminates hard to track unaligned serialization function bugs, and it doesn't take much time to get running. I can provide you some easy to use classes to use if you like, that way you don't have to spend time setting up protocol buffers or learning a new library.

With this method your data layouts and definition would be represented via a regular ol' struct in your code, no crazy file generation or huge library to deal with.
Posted by: PNill
« on: May 07, 2016, 06:31:55 PM »

...
One of my next moves will be integrating Google Protocol buffers in order to handle the data exchanges...
With that I should be able to create deltas of the information per player and handle everything in much smaller packets reducing latency overall and increasing the ability to play even if it's in a 'ghetto' state of syncing at the moment

...

Hey, sorry to just pop in unannounced! I have been amassing a lot of curiosity and knowledge toward multiplayer game networking, even going so far as to reverse engineering some client/server games to create my own servers for education. Unfortunately I DON'T have a lot of knowledge reverse-engineering binary files or generally trying to figure out what the game is doing. However, if I could get in contact with you to explain things to me about how the dll works and modifies the game's behavior, I could probably help / contribute to this project in some way, if you're open to that.

Personally I don't see how protocol buffers would give you much benefit, especially not for a first person action game like turok. Protocol buffers might be a little too much luggage for something like this, I feel like a well built udp protocol with standardized read/write serialization through bitpacking seems like it would serve you better, but I don't have much experience with protobuf and you're probably more experienced than I am in this area.

Thanks for the input,
I probably don't have much more experience then you do with multiplayer networking and I feel as if protobuf would just make things easier in terms of transferring data I use it in another of my projects and from what I've read on gamedev.net it's actually kind of preferred as its fast and you can store data how ever you'd like.

The other project I'm working on (halo2) does use bitpacking and it's own custom read/write serialization, I've just never gotten too deeply into processing data like that in C/C++.

I've got stinkee on Skype feel free to add me, tddeadlydata

-----------------

In other news regarding this project specifically I've got some good news about the player spawning I managed to get ahold of my old friend who was working on this project with me and while he was missing the source to the side of the project which would've handled most of the hooks and stuff since he had wrote it in MASM back then.... (I have the C side but it's not really relevant with that version as it just calls the MASM dll).

He still had the DLL is what I'm getting at so, this is awesome because I can reverse engineer this and figure out how the players were spawned in our previous attempt and add it into my new project so I'll actually start making major progress on this again I feel.
Posted by: djdduty
« on: May 06, 2016, 08:02:20 PM »

...
One of my next moves will be integrating Google Protocol buffers in order to handle the data exchanges...
With that I should be able to create deltas of the information per player and handle everything in much smaller packets reducing latency overall and increasing the ability to play even if it's in a 'ghetto' state of syncing at the moment

...

Hey, sorry to just pop in unannounced! I have been amassing a lot of curiosity and knowledge toward multiplayer game networking, even going so far as to reverse engineering some client/server games to create my own servers for education. Unfortunately I DON'T have a lot of knowledge reverse-engineering binary files or generally trying to figure out what the game is doing. However, if I could get in contact with you to explain things to me about how the dll works and modifies the game's behavior, I could probably help / contribute to this project in some way, if you're open to that.

Personally I don't see how protocol buffers would give you much benefit, especially not for a first person action game like turok. Protocol buffers might be a little too much luggage for something like this, I feel like a well built udp protocol with standardized read/write serialization through bitpacking seems like it would serve you better, but I don't have much experience with protobuf and you're probably more experienced than I am in this area.
Posted by: Jay Doomed
« on: May 03, 2016, 04:36:51 PM »

I wouldn't mind split screen either. Awesome work so far hope that you will return in work for this soon :) Anothrr thing I want to say is it was really cool to see some of the beta things and creatures come to life. Seriously thats really cool and im surprised not many commented to it. To bad Adon is not around and im just struggling lately :/
Posted by: Duke64
« on: May 02, 2016, 04:26:02 PM »

Hopefully things get clear for you again really looking forward to this here and I got the source now thanks very much for that.
Posted by: PNill
« on: May 02, 2016, 11:47:29 AM »

Just wanted to let you guys know for now on I'll be committing my code that makes this happen to GitHub,
https://github.com/PermaNulled/T4MP

One of my next moves will be integrating Google Protocol buffers in order to handle the data exchanges...
With that I should be able to create deltas of the information per player and handle everything in much smaller packets reducing latency overall and increasing the ability to play even if it's in a 'ghetto' state of syncing at the moment.

After implementing protocol buffers is when I'll start looking into event handlers to sync player actions, movements, weapon pickups and etc.

In theory I could have most of the data I need synced in a matter of days but I am currently taking a break from this project as I was pretty upset/disappointed with myself when I couldn't spawn another player without producing their screen I'm hoping that when I come back to this I have more of a drive to look at that again and figure out what I was doing wrong, in the mean time this will kinda just hang out for a while and I'll work on other projects and deal with real life until I find the time and motivation to come back to it.

If anyone else would like to experiment with it the source is there for now, and I'll try updating things at minimum to state where we can sync two players in a PoC (Proof of Concept) fashion via the split-screen mode that's currently in-tact.
Posted by: Rok
« on: April 29, 2016, 09:53:46 PM »


That is simply awesome. Would love to see the ghetto turok :)
Posted by: PNill
« on: April 29, 2016, 05:43:24 PM »

The issue has nothing to do with the method I will use to sync the data between players...

But to explain the way that it works is he's controlling the 2nd player on my screen where I am controlling the second on his.

It's not really mapping my local input to player 2 and controlling player 2 on him or anything like that.

On our local screens we are both player 1, and remotely we are both player 2.

Ahh I see that's got to be pretty confusing there dealing with that I hope you can figure it out though sounds crazy. I imagine that is ghetto :))

Video of the "Ghetto match" should be up soon.

I gotta see this hehe :) Turok ghetto wars.

It's not too confusing to be honest, but it shouldn't reflect the actual project at all in terms of how things will actually work once it's completed.

Though after I synchronized View angles I'm thinking of releasing the current progress so anyone here who is able to port forward can play with a friend of theirs just to screw around while I work to actually sync things properly.
Posted by: Duke64
« on: April 29, 2016, 01:53:52 AM »

The issue has nothing to do with the method I will use to sync the data between players...

But to explain the way that it works is he's controlling the 2nd player on my screen where I am controlling the second on his.

It's not really mapping my local input to player 2 and controlling player 2 on him or anything like that.

On our local screens we are both player 1, and remotely we are both player 2.

Ahh I see that's got to be pretty confusing there dealing with that I hope you can figure it out though sounds crazy. I imagine that is ghetto :))

Video of the "Ghetto match" should be up soon.

I gotta see this hehe :) Turok ghetto wars.
Posted by: Dinomite
« on: April 28, 2016, 12:33:57 PM »

Well it would be funny if you or Iggy smacked each other with the Warclub. I just keep feeling like it was going to happen in the video there lol. So who is who I mean who is top and bottom in that? But of course you want to send the least amount of data. So your saying that creating the way to actually send/render it correctly is the specific issue? I do wish I could help there but I don't think I will be much help on that myself. Its been interesting seeing this much so far though even know we took a trip to the ghetto it was fun hehe :P
Video of the "Ghetto match" should be up soon.
Posted by: PNill
« on: April 28, 2016, 09:50:53 AM »

Well it would be funny if you or Iggy smacked each other with the Warclub. I just keep feeling like it was going to happen in the video there lol. So who is who I mean who is top and bottom in that? But of course you want to send the least amount of data. So your saying that creating the way to actually send/render it correctly is the specific issue? I do wish I could help there but I don't think I will be much help on that myself. Its been interesting seeing this much so far though even know we took a trip to the ghetto it was fun hehe :P
The issue has nothing to do with the method I will use to sync the data between players...

But to explain the way that it works is he's controlling the 2nd player on my screen where I am controlling the second on his.

It's not really mapping my local input to player 2 and controlling player 2 on him or anything like that.

On our local screens we are both player 1, and remotely we are both player 2.
Posted by: Duke64
« on: April 28, 2016, 02:54:08 AM »

Well it would be funny if you or Iggy smacked each other with the Warclub. I just keep feeling like it was going to happen in the video there lol. So who is who I mean who is top and bottom in that? But of course you want to send the least amount of data. So your saying that creating the way to actually send/render it correctly is the specific issue? I do wish I could help there but I don't think I will be much help on that myself. Its been interesting seeing this much so far though even know we took a trip to the ghetto it was fun hehe :P
Posted by: PNill
« on: April 27, 2016, 09:06:47 PM »

That is good progress indeed. I actually wouldn't even care if it has split screen at least till the solution came up for it which I hope would eventually come. But I wouldn't mind it personally. If the co op mode worked 2 player split screen co op would be bad ass though. That is awesome there can the players hurt each other already to? xD

Yeah players could hurt each other and stuff, but the way I was syncing things was super ghetto just to mess around.

A real implementation would be to hook the areas where it updates positions and such and then use those as events to send data over the network, except the idea is that you want your packets to be as small as possible so you only send deltas rather then full data in every packet....

I need to consider how I'm going to do it..
Posted by: Duke64
« on: April 27, 2016, 07:14:29 PM »

That is good progress indeed. I actually wouldn't even care if it has split screen at least till the solution came up for it which I hope would eventually come. But I wouldn't mind it personally. If the co op mode worked 2 player split screen co op would be bad ass though. That is awesome there can the players hurt each other already to? xD
SimplePortal 2.3.6 © 2008-2014, SimplePortal