Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualAngus Hollands

Posted 05 February 2013 - 05:05 PM

After spending some time trying to find the optimal solution to a generically abstracted interface I decided that It wasn't worth it. Instead of trying to treat remote and local entities as the same (which, they're not) I have decided to follow the ideas from UDK's networking. After some thoughts it seems pretty logical. Some questions I have about UDK;

  • How are inputs sent to the server? It seems this is handled in the actor, not separate from it which is what i would like.
  • I assume that a single actor class exists for client and server, using roles to distinguish between the two. If so; How do certain aspects of the game loop differ between server and client? For example, assuming that actors have an update function, is it just separated into the server update and client update depending upon the role? Or is it the same and just the method it invokes are different.
  • Also, some implementation preliminary ideas: I'd like to use bitwise conditions for attribute replication. They'd be faster to compare than lambda functions, and I can't really see many cases I would need to have a lambda function. Would this be a bad idea at first glance? I can always add the option to provide a callable condition.

It seemed unusual that ROLE checks occurred in replication until I realised that in UE2 it was for function replication. So that's easier now. Here's my short progress if anyone is interested. It runs relatively fast, all considered. I still need to determine how to handle position and so on. http://bpaste.net/show/75355/


#4Angus Hollands

Posted 05 February 2013 - 04:22 PM

After spending some time trying to find the optimal solution to a generically abstracted interface I decided that It wasn't worth it. Instead of trying to treat remote and local entities as the same (which, they're not) I have decided to follow the ideas from UDK's networking. After some thoughts it seems pretty logical. Some questions I have about UDK;

  1. How are inputs sent to the server? It seems this is handled in the actor, not separate from it which is what i would like.
  2. I assume that a single actor class exists for client and server, using roles to distinguish between the two. If so; How do certain aspects of the game loop differ between server and client? For example, assuming that actors have an update function, is it just separated into the server update and client update depending upon the role? Or is it the same and just the method it invokes are different.
  3. Also, some implementation preliminary ideas: I'd like to use bitwise conditions for attribute replication. They'd be faster to compare than lambda functions, and I can't really see many cases I would need to have a lambda function. Would this be a bad idea at first glance? I can always add the option to provide a callable condition.

It seemed unusual that ROLE checks occurred in replication until I realised that in UE2 it was for function replication. So that's easier now. Here's my short progress if anyone is interested. It runs relatively fast, all considered. I still need to determine how to handle position and so on. http://bpaste.net/show/75341/


#3Angus Hollands

Posted 05 February 2013 - 04:20 PM

<p>After spending some time trying to find the optimal solution to a generically abstracted interface I decided that It wasn't worth it. Instead of trying to treat remote and local entities as the same (which, they're not) I have decided to follow the ideas from UDK's networking. After some thoughts it seems pretty logical. Some questions I have about UDK;</p>
<ol>
<li>How are inputs sent to the server? It seems this is handled in the actor, not separate from it which is what i would like.</li>
<li>I assume that a single actor class exists for client and server, using roles to distinguish between the two. If so; How do certain aspects of the&nbsp;game loop&nbsp;differ between server and client? For example, assuming that actors have an update function, is it just&nbsp;separated&nbsp;into the server update and client update depending upon the role? Or is it the same and just the method it invokes are different.</li>
</ol>
<p>Also, some implementation preliminary ideas:</p>
<ol>
<li>I'd like to use bitwise conditions for attribute replication. They'd be faster to compare than lambda functions, and I can't really see many cases I would need to have a lambda function. Would this be a bad idea at first glance? I can always add the option to provide a callable condition.</li>
</ol>
<p>It seemed unusual that ROLE checks occurred in replication until I realised that in UE2 it was for function replication. So that's easier now.&nbsp;</p>
<p>Here's my short progress if anyone is interested. It runs relatively fast, all considered. I still need to determine how to handle position and so on.</p>
<p>http://bpaste.net/show/75341/</p>

#2Angus Hollands

Posted 05 February 2013 - 01:48 PM

After spending some time trying to find the optimal solution to a generically abstracted interface I decided that It wasn't worth it. Instead of trying to treat remote and local entities as the same (which, they're not) I have decided to follow the ideas from UDK's networking. After some thoughts it seems pretty logical. Some questions I have about UDK;

  1. How are inputs sent to the server? It seems this is handled in the actor, not separate from it which is what i would like.
  2. I assume that a single actor class exists for client and server, using roles to distinguish between the two. If so; How do certain aspects of the game loop differ between server and client? For example, assuming that actors have an update function, is it just separated into the server update and client update depending upon the role? Or is it the same and just the method it invokes are different.

Also, some implementation preliminary ideas:

  1. I'd like to use bitwise conditions for attribute replication. They'd be faster to compare than lambda functions, and I can't really see many cases I would need to have a lambda function. Would this be a bad idea at first glance? I can always add the option to provide a callable condition.

#1Angus Hollands

Posted 05 February 2013 - 01:35 PM

After spending some time trying to find the optimal solution to a generically abstracted interface I decided that It wasn't worth it. Instead of trying to treat remote and local entities as the same (which, they're not) I have decided to follow the ideas from UDK's networking. After some thoughts it seems pretty logical.

Some questions I have about UDK;

How are inputs sent to the server?  It seems this is handled in the actor, not separate from it which is what i would like

I assume that a single actor class exists for client and server, using roles to distinguish between the two. If so; 

How do certain aspects of the gameloop differ between server and client? For example, assuming that actors have an update function, is it just seperated into the server update and client update depending upon the role? Or is it the same and just the method it invokes are different.


PARTNERS