Discussion list for Unity developers.
unity-dev at moock.org
Thu Feb 22 01:07:30 CST 2007
> We have made our first multiplayer game! yeap!!! :-) -- congratulations! Do you have a URL? > All it's ok, but in some cases we think we are not using Unity correctly. We know Unity is based on a MVC Pattern, but in some situations we don't see clearly which is the model, the view or the controler (almost always in the client part). The most problematic to understand for us is the mission of the class that extends Uclient. -- not all of uclient is mvc. the client-side room architecture is mostly mvc, with the URoom acting as the model and URoomView acting as the view (and often also the controller). in complex applications, you're probably best off making UClient a simple proxy class that forwards work on to other classes (perhaps rooms). in very simple applications, you can theoretically just dump your logic and display code into UClient, but that is not a recommended practice. > What are the differences between invokeOnRoom and setClientAttribute? What are the situations to use one or another? What are the criterions to select invokeOnRoom or setClientAttribute? == the invokeOn* methods are used to send individual commands to other clients. the set*Attribute methods are used to set enduring characteristics on clients and rooms. for example, to send a private chat message to a user, you would use invokeOnClient(). but to change a client's hair color, you'd use setClientAttribute(). > An example: > I want to send a message to all clients connected. Each client have to detect this message, and processing it in his view (like a graphic chat). I think this example requires invokeOnRoom, but is possible to do it with setClientAttribute... -- you should use invokeOnRoom() unless you want to retain the information so that other clients automatically see it when they connect. think of the invokeOn* methods as methods and the set*Attribute methods as variables. colin