Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

115 Neutral

About MudMesa

  • Rank

Personal Information

  • Interests
  1. @Alberth Thanks for the insight! I'll start off with just handling the requests as the come in then.  I can't say I fully understand the intuition of the calculations yet since I just started taking a look at queueing theory, but I'll take your word for now and keep reading up on it.   @Karsten_ , thank you! Yeah shorter papers are always harder to write than longer ones. I'll take a look! Haha that's cool that it's part of a Greelight game!
  2. Thanks for helping me rethink this, at first I was definitely thinking of having a separate thread handle the second player's requests.   In the pseudocode it looks like local requests are serially processed before remote requests.  To have requests processed in the order they are spontaneously generated, would one sort the requests by a time stamp? (after serially retrieving the local and remote requests as above)    Going off of the pseudocode, my thought is to set up a loop to repeatedly pull local and remote requests into the requests queue, sort those by time stamp, then process each request serially in the queue.    E.g. main { while(1){ requests = read_local_commands() requests += deque_remote_player_requests() sort_by_timestamp(requests); for each request in requests { ... } send_letter_state_to_remote_player() draw_letter_state_for_local_player() } } Really glad to get some alternate architecture design ideas. This "funnel"/"bottleneck" architecture hadn't crossed my mind.
  3. Thank you for your very helpul suggestions and clarifications!    I'll need to use locks on the flags since the words/letters will be accessed and removed at random, right?   Karsten_, thanks for the link and share! For this project I'm working with Java, but I do work with C++ sometimes. No worries, I'll take a look when you upload it and let you know if I come up with anything!
  4. Isn't that in essence a locking mechanism? The host phone will need to be aware of who is accessing resources, and block the other phone. 
  5. Hi everyone,   What would be the best way to handle concurrent random access of a shared resource on a peer to peer* system?   My goal is to make a two player word game, and the two players both need to access a shared set of words and characters. The players can add words/characters and take words/character at random.   My idea right now is this: Have one player host the game, i.e. their phone will act as the host server. The shared resource will sit on their phone.  Every time a player potentially adds or removes a word/character, they acquire a Java lock on the shared words/characters. Locks will "wait" for other locks to be removed first.  Each call to acquire a lock will have to first check if the word they want to remove or add has already been removed or added by the preceding lock. Is this a good design? I'm a little worried it may cause a slow game. I'm also at this point not 100% certain it's possible for Player B to acquire a lock on a resource on Player A's phone.   I'm thinking I will use sockets for the peer to peer system.   Hopefully this is an okay place to post this type of question.   Thanks for your help!   *perhaps the "peer-to-peer" architecture I'm describing some might still consider to be "client-server"?    p.s. I did perform a search and found threads like the following, but not sure if they are referring to the same thing as I am: http://www.gamedev.net/topic/582408-how-scalable-is-lock-step-peer-to-peer/    
  • 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!