Jump to content
  • Advertisement
Sign in to follow this  

P2P + events stupid architecture logic problem

This topic is 2181 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want to keep game logic decoupled from networking, so I have a net class that listens to game events that should be send to the remote peer.

When an event is received, I send this info to the remote peer.

When a packet is received, I generate an event and send to the game logic...loop!



Im producing and consuming forever, and the only way I see to stop this is making the game logic aware of both events and "remote events"..I dont like this..

How would you solve this?


The game logic is really raw right now, I dont have the concept of a "player 2" yet, Im just treating inputs and core mechanics..Input is also decoupled. I was expecting to have just an above layer treating players / scores stuff, and let the logic only with core stuff, trying to keep the concept of players out of the core mechanics, dunno if I will be able to do that, or if I should..


Perhaps I should include in the event data a player ID (or even a bool bRemote) instead of having another event? Then my net class checks if player ID is local or remote before generating an event, the game logic dont need to know about it..


Another thing Im thinking about, is not generating any even on the net class, instead, when I receive a packet Id call the game logic handler method that is called when the event is received...kinda intrusive, but I dont know if this is a problem.

Edited by Icebone1000

Share this post

Link to post
Share on other sites
Is the problem that, once you send a message, it comes back around, forever?

If so, I see a bunch of options:

1) You can timestamp events/messages, saying "this event is for time X." Deliver it at time X, and don't accept messages to re-deliver when the timestamp is "now" or in the past.

2) You can mark messages with a source -- "from network" messages would not get re-messaged.

3) You can intercept the messages to forward on the "send" operation instead of from the queue. Thus, the function that "normal objects" use to put a message into the queue also marks them for sending. The network receive function puts the messages into the queue in a different way, that doesn't re-queue them for sending.

4) You can give each object an ID, and mark messages with which object they're sourced for. Each object has a master on a particular host. Messages are only sent on the network for objects that are mastered on the sending machine.

You can also move away from message replication to state replication, which would be a bigger kind of change.
Which way you go depends heavily on what kind of game you're building in the end, and what your authority/rules model will be.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!