Junilu Lacar wrote:One of the challenges in writing software is that there are literally hundreds of ways you could possibly do something. Without more specifics as to the particular solution that you have in mind, a question like yours is open to hundreds of different interpretations and you could very well end up getting as many different answers. To get specific answers, be more specific about exactly what it is you're trying to do.
Junilu Lacar wrote:Assuming your clients are going to browser based, I would do searches using terms like HTML 5, WebSockets, and multi-player game programming. You'll probably find plenty of ideas with those terms alone.
Paul Clapham wrote:It is extremely difficult to find out which of two events on different computers happened first. In fact that could be said to be meaningless. So if you give "Play" buttons to both players, you will not be able to prevent the situation where both of them press the button.
However the server can tell which of two events on the server happened first. So perhaps you could give the "Play" button to the client who connected first?
Junilu Lacar wrote:Your responses make me think that you don't actually have any code right now and you're just conducting a thought experiment based on nebulous notions of how you would implement this.
Thought experiments are fine in physics and philosophy and they may even work to some extent in software development but only to a point. I think we've reached that point now where I would say you need to share some actual code so we can continue having a fruitful conversation based on something concrete rather than conjecture.
Besh Hart wrote:
I didn't post my code because:
1\ Its messy because I'm not done with it.
2\ I didn't want you thinking that I'm just here to dump my code on you so you can fix it.
I apologize for any inconvenience caused.
Junilu Lacar wrote:
Besh Hart wrote:
I didn't post my code because:
1\ Its messy because I'm not done with it.
2\ I didn't want you thinking that I'm just here to dump my code on you so you can fix it.
I apologize for any inconvenience caused.
I should be more careful what I wish for...
1. Fair enough
2. We wouldn't do that anyway
No apology necessary.
Regarding #1, I will say that it would serve you better to make your code clean and well-organized and keep it organized as you go. Otherwise, as you have probably noticed already, it will just get messier and messier. The messier the code gets, the more unwieldy it becomes and the more difficult it will be to work with and change. It will also get progressively more difficult to understand and this will lead you to making an even bigger mess. This creates a vicious cycle that at some point, probably long before you actually get to work properly, will make your code so unwieldy and inscrutable that you'll just give up. If you do get it to work despite it being a mess, it will be so full of bugs that are hidden in the mess you've made that it will be difficult if not next to impossible to fix all the issues.
Perhaps you need to rethink your "requirement" to "stop the client thread". That's actually an implementation detail and thinking like that can drag you down into a deep, dark hole. It seems to me that your real requirement is you need to "prevent more than one player from starting the game." Thinking from there, that might not even be the real requirement. Maybe your real requirement is to figure out which player should be designated as the "active" player whose turn it is to make a move.
As Paul said to earlier, it's difficult to determine in real-time which client player pressed a button first. What you can determine on the server side is which client's request to play came in first. Based on that, I would set a "game started" state on the server side, then inform all clients that the game has started. You would then inform the client whose request came in first and triggered the start of the game on the server side that it's his turn. The other clients get notified that it's not their turn. The clients then adjust their state accordingly.