Networked Game Structure

[Simie]

Hi Aren,

I currently have a game which has a structure like this: (classes in bold)

- Each connected player has control of a Planet
- Each planet contains 12+ BuildingSlot gameobjects, each of which can contain a building of any type.
-- Player can trigger construction of Building gameobjects in these slots (Building is subclassed by many unique building types)
-- These buildings have their own unique properties to sync (e.g.: reload time for weapons), as well properties common to each (health, construction progress, etc)
-- Buildings may be destroyed by the actions of other players

I currently have it set up so the Planet, BuildingSlot and Building all have their own TNObject, to prevent all the building logic taking place in the root Planet object.

I've read around some previous topics in this board and it looks like you recommend against having nested TNObjects, I'm wondering how you would recommend structuring a system like this in that case. I'd like to avoid bundling all my building logic and communication in one place if possible.

Any advice would be appreciated.

Thanks!

[djray2k]

My opinion (as I always preface since I'm no expert) would be to just have the Planets (or player) maintain TNObjects.

Any kind of upgrade could be easily called all within the same TNObject. If you needed to update the amount of Buildingslots, update when a building is created, update the status of a building, all these things could work with one TNObject.

[Simie]

I can definitely see it working with a single TNObject on the root Planet. It just seems... wrong to put all the logic in once place like that. I'm not very experienced with networking, so maybe that's just how it has to be done.


Misc. question: Are reliable (TCP) messages executed in the exact same order on every client?

[ArenMook]

You can use many TNObjects if it's easier for you. It's not a good idea to instantiate TNObjects frequently (think: bullets), but if you want to have many TNObjects in the scene, you can. For objects that simply exist in the scene it's really up to whatever is more convenient in your case.

Yes, main traffic is always received in the same order it gets sent.

[Simie]

Are there any complications I should expect when using nested TNObjects? I've browsed through the code for TNObject, and it looks like there is quite a bit of parenting logic in there. RFC calls seem to seek out methods in all MonoBehaviours that are in child gameobjects, not just the ones attached to the same object as the TNObject behaviour.

EDIT: Another question: Should RFC ids be unique across all objects, or unique within an object? IE can I have Class1 with a method with RFC ID 1, and Class2 also having a method with ID 1 and not have any problems?

[ArenMook]

It's not a good idea to nest TNObjects in dynamically instantiated prefabs, but you can nest them freely in a static object (read: object that's not instantiated via TNManager.Create). The reason for that is that when you do TNManager.Create, it will generate a single TNet ID for your prefab, not multiple. There is no concept of hierarchy on the server, so when you destroy a TNObject, it doesn't go searching for its children.

RFC IDs should only be unique per-TNObject. Meaning each TNObject can have up to 255 specific RFC IDs. If you need more than that for some reason, just stick to unique function names (though can't imagine why you would).

I personally use function names everywhere except functions that are sent more than a few times per second.

[Simie]

If I were to create an object via TNManager.Create, then another by TNManager.Create, and parent the second object to the first, would that cause problems? I've got them parented so the planet moving will move all the buildings attached to it. I could move them out and update the positions in Update() if you think parenting would be a bad idea.


Another misc question: Any reason why System.Double isn't one of the default supported types for RFC parameters? Took me a while to track down why an RFC call was failing (the error wasn't particularly helpful... actually, the error was fine, I don't know why I didn't realise sooner) until I found that double's don't serialize correctly.

[ArenMook]

Depends... will one of them be destroyed at any point? If you happen to destroy the parent, then the child will be gone too -- something TNServer won't know about. If they won't be destroyed, then it should be safe enough.

TNet 1.9.0b supports serialization of just about everything, including doubles. What version are you on?

[Simie]

The parent objects won't be destroyed, so it should be fine then. Thanks.

I'm on 1.9.0b. I had to add System.Double to TNSerializer.cs (in WriteObject(), GetType(int) and GetPrefix(Type))

[ArenMook]

Curious. Well, I'll add it.