Please pardon my ignorance on the networking questions that follow, I have finally got a reasonable grasp on the interface and scripting and am trying to move into networking some now.
The project that I’m working on will require a large amount of traffic between the client and the server, loading arrays on the fly, using the data from the arrays to load textures, sounds, video, etc. I have thought about trying to use the level system in unity to solve my issues - but I will have a very dynamic interface that will prevent me from going down that path (I think).
I have looked at the WWW and WWWForm classes and I think they will do what I need but I was wondering if there was a better way. One of the members on my team is building the database structure and is very smart in c# and is asking questions that I don’t have answers too (he’s not familiar with Unity yet).
He wants to set up a web service to make calls between the client and server, is this an efficient process? would it work in Unity?
I have read that I will have to manually parse any XML files that are read into Unity. In actionscript, there are several functions that are built in to help parse this information into the appropriate arrays, but I haven’t seen anything like that in unity yet. What’s the best method to take a long list of say file names into an array and then use those file names to load in textures to display the corresponding images?
What about the networking classes that are in unity? Can I set up some sort of constant communication between the server and client? How much of a performance hit is there?
I know these questions are not answered with a simple two line explanation, but before I spend hours going down the wrong path, I’d thought I’d get some input from the experts.
are you creating a Web player or standalone game? If it’s a standalone game, just use all of the .NET 2.0 API that’s available which includes WebServices APIs and don’t worry (your C# programmer colleague will know about those APIs and feel very at home ).
If it’s a Web player, things are a bit more tricky…
You can still use all the fancy .NET APIs for the server, but you’ll have to make sure these are not accidentally included in the Web player because it might add quite a bit to the size of the Web player (I guess 1 or 1.5 MB at least). So you need smart software design
I’m not sure what the most elegant way of handling this would be, but I guess what you could do is have one GameObject to which the WebService scripts are attached which you can do without on the client and that you only include for the server builds (I guess you can look that up dynamically while starting up, which you would only do when running as server; the lookup would fail on the client, but you don’t need the server code on your client anyways, so it doesn’t matter).
If you use that kind of encapsulation, Unity should not include any unnecessary assemblies into the Web player (it’s pretty smart at managing the dependencies), but you’ll be able to develop “as usual” for the server (i.e. using all the power that comes with the .NET APIs).
The standard .NET APIs are not documented in the Unity documentation, but you can still use them (all the System.* namespaces). You can find documentation on the Microsoft pages, and I guess the Mono project documentation will also be helpful (I think there’s good documentation on what is not implemented with Mono, but AFAIK, it’s not that much).
Just be careful not to expect .NET 3.0 or .NET 3.5 stuff - Unity is based on Mono with .NET 2.0
Thanks for the info, we will have both a client and a standalone with the intent of driving the majority of our users to the standalone as a more “complete” experience. However, we don’t want to force that on them if they don’t want it and we want to give people the ability to use our environment while they are away from their primary computer (read, at work).
We are creating a very unique environment that I will be explaining in much greater detail in the future here on the forums.