Object Oriented Networked Game Design Question

I am making a game.
This will be a good game.
The game is being written in managed directx in C#.
I have a question about this game.
It is a multiplayer game in which people connect to a server.
Each person controls a person.
I have a moveable object class.
Every graphical object inherits that class directly or indirectly.
In my person class, should I have the moveable object as a member variable or make the person class inherit the moveable object?

confusing question... thet depends on what you plan to achieve. haveing all movable objets inheirt from movable objest class is not a bad idea, you shorely know what taht means... a massive polymorph usage, with a nice and short universal code for object handling..

in my opinion the question is not whether to agregate or inheir, cos inhertion is quite natural for that sort of structuralization and generalizations of handling rutines, but the question is why managed directx... it's not a good way to start with a game, directx is kept as managed library for wider compatybility and tools usage, but games usually need all the power you can get... it it's a small non-complicated project it'll do just fine, but if you plan a real relase, then managed dx ain't your dreamed platform

just compare effeciency of dxsdk examples given in both c++ and managed c# , there _is_ a difference

well just a little of-topic warning ;)

now back to busines, agregation may seem to be a slight more memory conserving (in further handling of "person" class movement) than inhertance, but the beauty of polimorphic simplicity 'll meake you smile when watching the code

Inheritance leads to pretty code but you say that your game is distributed;
what is communicated from client to server and back again? I assume the
moves are actually handled on the server (otherwise there is a fear of
cheating clients) so the local avatar must communicate positional and input
(or consumed input) information up to the server. The server must
distribute positional/movement data on all objects of interest to each
client. It begins to sound like the communicated piece (at least as far as
movement is concerned) is a base "movable" object. It might be easiest to
have movable as a field of your objects so that you can serialize that
small object to the wire.

There are alternatives that support inherited code (many engines I have
experience with do it with inheritance; I have written distributed systems
that work both ways) but it depends on how low-level you're going to get
with the communications code.

The question you ask is complicated because of the interaction of client
code, server code, communication code, and software engineering principles
for designing complex systems. Please let us know how your thinking goes (I
love arguing about design questions and I am not the only one here).

Well, first of all, I am using DirectPlay for the server. This decision is based on the face that DirectPlay has a LOT of built in functionality, and making a server to compete with the directx server is a difficult task. Also, future changes that the managed directx team makes to directplay will only benefit me.

It seems that you want an example of how I handle movement. I learned about this method from an article the Game Programming Gems 3 books.
Lets say that Person A wants to move forward. His program does initial validation checks, and if it seems that it is alright for him to move forward, he will be rendered at his new position on the screen. He then sends a packet out to the server that states his new position (don't criticize me if this is inefficient, but please provide an alternative; i'm doing optimizations later). The server then performs validation checks, and if it finds an error, it will let the client know and deal with it. The server then reveals the clients new position to everyone (if it changed).

The client uses an asynchronous connection that calls a function every time a packet is received. That packet is parsed, and then the appropriate event is fired. If that event is significant for the player class, he will be subscribed to it. Else, the event will be handled elsewhere. For example, if some parsed data reveals that player number 7 just shot your player, an event will be triggered that passes in the appropriate parameters, and the player class will be subscribed to this event and handle it.

When the player moves, he will fire an event that states his new position. The ValidateAction class will be subscribed to this event, and it performs the initial validation checks and if the movement is valid, then this class will fire another event that the client (connection/socket class) is connected to.

Let me perhaps save some time by anticipating a criticism. You may dislike my use of events, but I am only implementing this system after much, much thought. My reasoning is that events allow for much more readable code, and much more changeable code. For example, if i later want to make a MovementAnalyzer class that analyzes the movement habits of a group of players and I did not make an event that passes in the ID of who moved and his new location, I will have to changev the client's connection class code to call a function in the MovementAnalyzer class. And if i later get rid of the movement analyzer class or adda new one... again I have to change the client code. I believe this is anti object oriented, as the client class is dependent on the external classes. Making a PlayerMove event would solve this problem.

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

I like the optimistic predictive movement pattern. One other thing to keep in mind is that there are some things that move (particles, for example) that do not have to be coordinated at all (who cares if the rocket explosion on client A looks exactly like client B? The explosion's center point and the damage radius are handled at the server). Note that this communication pattern is good for things like first-person shooters where the coupling is somewhat loose; if you want to have coordinated animations (say a martial arts title) the connection is not strong enough (coordinated animations in a distributed program is a serious challenge).

I think the publish/subscribe model is a good model for taming the complexity of the communications model. With this model, your original question comes back up and it seems that you could handle movement either way (inheritance or aggregation). Inheritance might make sense (I know, devil's adovcate; this is really a broad design decision and I can critique either choice but since neither is obviously worse than the other it is as much a stylistic as a technical question). Then the start-up code for Mover can subscribe to events about this Mover and have all the code to handle those events in the default case.

I will argue about the event connection between a Mover and ValidateAction; events are announcements of actions that have happened. Receivers don't have a way to "unfire" the event and I think that ValidateAction should be able to suppress an invalid action (so no subscribers to that action see the event). Firing a "cancel" or "correction" event will be necessary for things like movement after a trip to the authority but imagine that an AnimationManager sees the "Walk" event before it sees the "cancel" event. Not that big of a deal but it will begin playback of the animation and THEN will have to remember what state to return to when the cancelation shows up.

Looking at my argument against the Mover/ValidateAction publish subscribe connection: At the cost of additional event types you have the ability to publish a "proposed move" from the Mover and then have the ValidateAction object publish the "move" event after validating. Then those interested in moves (as opposed to simply proposed moves) can subscribe to the approved move event. Increases complexity of events but decouples ValidateAction from Mover (and all the other action starting objects).

Yes, i have decided to use cancellable events (actually built into C#). I'm working on getting the basic architecture for my game up where people can connect and walk around. Right now I am trying to work out some thread sync issues. Actually, let me start a new post on this topic.

0

Featured Post

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

What is RenderMan:
RenderMan is a not any particular piece of software.
RenderMan is an industry standard, defining set of rules that any rendering software should use, to be RenderMan-compliant. Pixar's RenderMan is a flagship implementation of …

As game developers, we quickly learn that Artificial Intelligence (AI) doesn’t need to be so tough. To reference Space Ghost: “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer. (http://www.youtu…

Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…