Author Topic: TNManager.Create Asynchronous call  (Read 13852 times)

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: TNManager.Create Asynchronous call
« Reply #15 on: March 01, 2013, 02:30:48 PM »
No, that's not how most games work. Those that do send input are generally laggy and unplayable. Name one game that you think does it. :)

broknecho

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 33
    • View Profile
Re: TNManager.Create Asynchronous call
« Reply #16 on: March 01, 2013, 03:20:27 PM »
@Suvu Well it's not that Sending input is a bad thing....it is though if that's ALL you were doing.  But clearly in your first point you say you are setting it locally as well (which eliminates any chance of a lattency really affecting it).

@ArenMook I think he's more referencing that it's not out of the question that a server would take INPUT versus property Syncs.  I see it as a server that is hosting the simulation wants to validate the user input would receive the control input and then apply that to it's current simulation instead of simulation updates.  This would then allow it to validate if the new state is verified to be safe to do (check for cheating).  One of 80 ways to skin this cat.

Looking at: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking, that document refers to client input being sent over and then either interpolation or extrapolation being calculated for prediction purposes.  But that could also mean validating for cheating and weird changes in the game state.

Anyways I think your way should work fine.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: TNManager.Create Asynchronous call
« Reply #17 on: March 01, 2013, 06:08:06 PM »
Yeah it's used for determining where the player should be (anti-cheating measure). It's not used to actually move the player, unless the player is determined to be too far from where he should be based on the values extrapolated from input.

broknecho

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 33
    • View Profile
Re: TNManager.Create Asynchronous call
« Reply #18 on: March 02, 2013, 04:15:01 PM »
@Arenmook

Well you'll either get sick of this topic or me.....or both  :)  So I got some time to work on my game again and dove into the solution we discussed earlier.  I have a solution working right now but I don't think it's a really good pattern and there has got to be something I'm really missing about game design that is confusing me with the new TNet pattern (which btw has cleaned up an incredible amount of my project so far!  Thanks for that!).

Attached is an "Example 4" that extends the TNet samples illustrating exactly the problem I have been discussing.  When you get a chance Arenmook, can you import the attached package onto a fresh TNet project and look at the Example 4 Scene?  The UnityPackage contains:

  • Example Menu - Only change I made was to add the "Example 4" scene into the Examples collection on the main ExampleMenu script so the button shows up when running.
  • ExampleSpawner.cs - This is the script that is handling the OnClick for the new Spawner objects in the Example 4 scene.  It is pretty much a duplicate of the ExampleCreate.cs script but with an added field called objectColor.  This is the color I would like to pass to the created "objectToCreate" objects.
  • Example 4.unity - The actual example scene with the new spawners.

What I'm looking for is is a way to click any of the spawners and have that color set on the cubes that are spawned above it.  This illustrates how the "Created Cube" prefab doesn't know about what color it should be but should be set from the spawner.

Please let me know if you have any questions.  We can chat over skype too if this thread is driving you nuts  :)

Thanks a lot,
Scott