GOOF and Network

Hello,
This is more me talking to myself and hoping someone will point out my errors. So I am playing with Raknet to tye it into GOOF. At first I intended to make a simple interface that looked like GOOFinputListener that pushed the data into the game objects, but that did not seem to work as I need to get state information echoed back from the objects and in an extreme case the objects will be doing a lot of work on their own (collisions, actions, positioning...) that would have to be repeated to the network,

Soo.. I think the best way is to declare a Network interface and then inherit all the needed game objects and have a networkobject factory that would build the object, register it with the network and then the object is responsible for all its network communication. This, however, means that more needs to be hardcoded into the objects.

The last option is to pass all the input through the network layer and then have the server do all the work, but that seems to be a lot of work on the network. Maybe some thing inbetween all this.

Also I would like to have the interface as general as possible as I would like to be able to change from raknet to whatever as need arised. Network programming is new to me

That's a great question, and something I've thought about a lot. One of the next things I'm looking at in GOOF is how to start creating complex interactions between components (GameObjects) in a loosely coupled system.

For example, at the moment GOOF doesn't do much for you when it comes to interactions between objects, messages, and things like that. My intention is to have it so you can take a bunch of components, snap them together, and make something new.

Imagine I want to have something that represents the player, so it should have animations and blending, movement, sounds, and perhaps clothing/equipment. Instead of having an all encompassing PlayerGameObject, I want to have a MeshObject, MovementControllerObject, and SoundObject. These should be fairly loosely coupled - mostly the objects don't know anything about each other, except that they're all snapped together. I want the system to work, and to be easy to use, so that's what I'm still trying to figure out. There's no point creating a system that no one can use because it's too complex.

A few ideas I have are
a) Send messages between snapped components. For example, the MovementControllerObject would know it's running and send a "play run animation" message to any snapped components, and the MeshGameObject just so happens to know how to do that, so plays a run animation.
b) Have an object expose a list of actions that it peforms, and a list of events that it handles, and have a way to join actions to events from within the editor as well as through an API. An example is MeshObject having a list of events "playAnimationRun", "playAnimationWalk", etc. that are dynamically generated based on data in the animation of the mesh. The MovementControllerObject has an event "runStarted", which is hooked to the "playAnimationRun" event.
c) The MovementControllerObject knows about the MeshObject and uses it directly.

So, now back to networking. I think this should be another component that is "snapped" to existing components. For example, you'd have a NetObject that is the base class, then a PlayerNetObject that represents a remote player. Again, the PlayerNetObject really just deals with networking, not mesh loading, playing animations, or playing sounds. It might emit a "play ouch I got hit" action which is handled by the sound object, but doesn't play the sound itself. It snaps together (when I say snap I basically mean added as a child object) with the MovementControllerObject and tells it where to move and what to do (through events or messages or directly). There would probably also be a NetGameSystem that controls creating and destroying these objects.

Well, that's my 2 cents.

hmm,
The problem with every little part interacting with every little part is the whole becomes very complex and difficult to change. Expecially with network information. In some games every little bit must be sent in others only a few pieces of information ass through the network.
I can see the benefit of having the pieces seperated, as this gives the user a lot of flexability they can change the rules of behavior by recoding that piece of the whole, but having a basic glue playerobject would make this easier to handle. You just change one piece.
It would seem to be easier for the user(game dev) to have a sensible player object that can be adjusted according to the game needs. i would like to have the playerobject be based in a higher level language so programming game logic becomes very simple. I am still playing with the basics of setting up the connection and registering the scene right now so I will think about it later

It's completely up to you, I'm not going to restrict you from controlling it directly.

What I'm suggesting is that you will have a PlayerNetObject that does have all the functions required for a Player, including any remote procedure calls and specific data you need to send or replicate (say, using ReplicaManager of Raknet). It's very specific to a player, and different than a GrenadeNetObject or a PowerupNetObject. However, if you separate it from the graphical, sound, etc. implementations you can run it as dedicated server without the graphics assets and sound assets loaded, that's all. You may still need physics, for example, but then again I'd say that physics would be its own object as well. This separation of components, loosely coupled components, makes it so that everything is neatly isolated from everything else. It's similar to Jeff Plummer's "System of Systems" architecture, except it's focused on loosely coupled components. http://www.acims.arizona.edu/PUBLICATIO ... pendix.pdf

Whereas he suggest that GameObjects are bad, I suggest that GameObjects are fine if they're loosely coupled and don't have uber classes that do everything.

This is just a suggestion - how you deal with it is up to you. You asked for my opinion

no, i am interested in your opinion. just haven't grasped it yet. I think i am getting it though. I didnt think that just having one gameobject could be useful. All objects behave differently, use different AI... It would be unmanageable to have everything in one object. As a game designer, I would like to have a bunch of tools that I can script into a custom game object as I designed that game, and not think about any actual mechanics.

Anyways, I am working on connecting to the server, downloading the required resources, and attaching the PLSM so it only asks for the needed resources. Then I will have to figure out how which way is easier to program verticle as in a game object X returns all info, or horizonal, as in all motion managers speak to the network

Ya, I wasn't saying just one game object does everything, I was saying that your net objects are decoupled from the graphics, sound and physics.

I'm not 100% familiar with Raknet, though I have looked into it. It seems to me that Replicas are a nice way to handle objects, and it's all about defining what data each Replica has and streaming it out to the network. VehicleNetObject might have position, orientation, velocity, etc. You might have a class that derives from VehicleNetObject and adds extra data such as a BoatVehicleNetObject that has bouyancy or something, and adds it to the stream as well.

Anyhow, let me know what you come up with.