- Home /
client/server in the same project?
When creating a multiplayer game, do you normally have one project with all of the code in there? Assuming your server needs access to Unity, and can't run as a seperate app.
My current project is one Unity project, with different scenes for the client and server. I don't want server side code to be available in the client package. I'm using Visual Studio for my script development, the project contains the client and server code, and I think I'm going down a dark, dark road.
It seems to me that at -least-, I should split my visual studio project into a client and server project, and if nothing else client distributions won't get the server side dll. But I'm a little fuzzy on how to implement this, or what the architecture would look like.
I do know that I want the client and server unity packages to have access to the same unity assets. I originally started with a client and server project, but maintaining the shared code between them was getting to be a hassle, so I merged them.
So, I'm thinking perhaps in visual studio I should end up with three projects for the Unity package...one for the client, one for the server, and one for shared resources. I would have one Unity project. From what I understand, if I create a client scene, server scene, etc...the client scene will only include resources that the client uses, and not everything the server knows about also. Honestly, the more I think about this, the more it seems I need to just split this back into a separate client unity project and server unity project.
Any thoughts tips on this would be very much appreciated.
I went ahead and created a common project, for common resources shared by both the client and server. The post build process copies the dll to the assets folder, and everything appears peachy. For now ;) Next, I'll start splitting the server code into a server dll. This won't go to the clients, so hopefully that will protect some resources. Any thoughts or tips on this would be welcome!