Why don't user vars support floats?

[kevinfoley]

We are building a game in Unity. Unity uses floats for most operations. ISFSObject has a getFloat() function, but UserVariable only has GetDouble(). There's no point in wasting twice as many bytes on doubles if we'll have to cast them back to floats on the client side. Why is there no GetFloat() operation for user variables?

[Lapo]

Hi,
User/Room Variable have a simpler interface and support a more limited amount of types that cover all major needs (ints, decimals, booleans, strings etc...).

If you need to structure your data in a more fine-grained way or use types that are not supported directly (such as byte, float etc...) you can add them to an SFSObject and then wrap the object into the User/Room Variable.

Alternatively you can bypass Variables entirely and use custom Extension calls.

Cheers

[kevinfoley]

Thanks. It would be nice if you supported these smaller variable types directly in the future, both because they can make a huge difference in bandwidth usage, and for consistency with ISFSObject. And I assume wrapping primities in an SFSObject has a greater performance hit than if these additional primitive types were supported directly.

[Lapo]

Thanks. It would be nice if you supported these smaller variable types directly in the future, both because they can make a huge difference in bandwidth usage, and for consistency with ISFSObject. And I assume wrapping primities in an SFSObject has a greater performance hit than if these additional primitive types were supported directly.

Wrapping in an SFSObject adds 3 bytes to the packet, that's pretty much all there is to it.

Thanks

[kevinfoley]

But it also requires extra method calls and object instantiation on the client and server. Also, adding three bytes to a small packet is a big deal. For example, wrapping a short in an SFSObject would apparently use more bytes than sending an integer. Or say that we have three values which should all fit inside shorts. If we wrap all three in a single SFSObject, we have to send all three values any time one of them changes. Now that's costing us 9 bytes ( 2 * 3 + 3) to send 2 bytes worth of data that has changed. So it seems that wrapping primitives in SFSObjects is usually going to make things worse instead of better.

Using smaller primitives is usually one of the easiest ways to cut down on bandwidth usage; it is frustrating that your API is not designed with this in mind.

[Lapo]

Usually when you need such level of optimization (i.e. every byte counts) you should choose Extension messages over Room/User Variables, so that you have full control of the protocol and reduce any possible overhead.

For instance you can get rid of SFSObject keys by creating a byte[] packet and sending just that with a single 1 char key.

Cheers

[kevinfoley]

We are working on an MMO game, and if I'm not mistaken, Extension messages do not use the proximity system. It seems counterintuitive for the MMO system to force us into using large data types that will consume more bandwidth, since bandwidth is a particularly big concern in MMOs.

[Lapo]

We are working on an MMO game, and if I'm not mistaken, Extension messages do not use the proximity system. .

Of course they do.
Here's an example:

Code: Select all

@Override
public void handleClientRequest(User sender, ISFSObject params)
{
   MMORoom mmoRoom = (MMORoom) sender.getLastJoinedRoom();

   // Handle position update
   // ...
   
   // Send a response to users in sender's AoI
   ISFSObject resp = new SFSObject();
   
   send("command", resp, mmoRoom.getProximityList(sender));   
}


You can handle the custom request in your Extension, apply validation and such and finally update all players in the sender's AoI.

Hope it helps