• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 682
  • Last Modified:

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?
3 Solutions
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
davidastleAuthor Commented:
I compared the efficiency and most of the examples run at very similar frame rates
str_ek asks the right question: What is your goal?

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).

Good luck,
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

davidastleAuthor Commented:
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.

Please give me constructive criticism.  Playing devils advocate won't help me.
davidastleAuthor Commented:
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.
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.

Just thinking out loud.

U are awesome. Have you written any books?
One in progress. Don't doubt that ad space will be purchased here.
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).

davidastleAuthor Commented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now