I'm building an mp game that needs to have some sort of a queue system (eg League of Legends, CSGO, Dota2...)
So my question is how to implement such ?
I mean the core concept (I'm not looking for done code, even though some code would be welcome)
EDIT:
I have created a lobby system where you can invite players and if they accept their id is put into the lobby array and the lobby id is returned to them on client side. So the problem now is when the lobby creator hits the start queue button... How to find other lobbies that combine 8 players (2 teams of 4) but leaves the premade players in the same team
Related
I am working on a QT project for a board game that supports two players connecting to each other. The sockets provided by QT would've done a wonderful job, but since I cannot easily open a port (my ISP owns my router), I had to settle on other ways of connection that doesn't depend on that.
My idea is the following:
Use NGROK and have both players open their own TCP tunnels;
Input their NGROK urls into the game so we know where to scrape off;
Serialize the board state data (including the board size, the current points for both players, and booleans determining if the other person has pressed a pass/resign button) into a JSON file;
Scrape the data off the other persons JSON file and update the board state for yourself;
Rinse and repeat until the game terminates.
Would this be a good alternate way of doing the connection or am I impairing myself too hard by doing this way? Are there other, easier ways of sending this data back and forth between the two players?
I am making a small multiplayer game, where the host player starts a server from her application which runs the game logic for everyone and displays the graphics for her. Up to 3 other players need to be able to connect(currently via TCPSocket connections) to receive game states to render on their computers and so they can send input commands to the hosts computer to update game state.
I have been able to implement connections using blocking sockets and a SocketSelector, as well I have implemented sending commands from clients that update game state, however, I do not understand via the documentation and tutorials available how I can separate the runServer code and the hosts update and render code without utilizing additional threads. I have been told that the selector should be enough such that I do not need to open new threads to keep constant game time updates. My question is a request for any examples of this style of implementation.
I have a small Clojure game (think Snake but multiplayer; if you hit another snake, you lose) running over WebSockets - logic is in the Clojure backend, rendering is in the browser.
Every "turn" of the game takes 100ms, during which the game steps, which involves 1) calculating the next state of the game, 2) sending the game state to every player over WebSockets 3) checking if the game is over, and if not 4) sleeping for 100ms minus the time it took to do steps 1-3, and 5) looping back to 1.
There is a global atom games, which is a map from a UUID to a game map (has player coordinates, directions, etc.). When a player presses an arrow key, the browser sends a message containing the game's UUID, the player's UUID, and the move. On receiving that message (independent of the game loop), the server directly modifies the games atom to update its to-moves map to say that the player with some UUID wants to turn :right. Step 1) above takes the to-moves list and changes each players' directions accordingly before moving each player forward (every 100ms). This method works.
I learned about core.async (go, channels, parking, etc.) but I'm not sure if it would be applicable in this case. I was originally thinking that instead of a :to-moves map as part of the Game, I have a buffered channel instead. Then when a player submits a move I can do (>!! ch [<player-uuid> :left]), for example. And when I calculate the next game, I can get the moves with (
This is more of a learning project, so if core.async will pretty much be the same as my current method that's fine. But is it applicable in the first place?
Thanks.
Firstly, I'm assuming that when you say "running over websockets" you mean that you're running ClojureScript in the browser and that you want to use core.async in the browser to decouple your websocket communication implementation from the event generation.
In that case, core.async channels is a very neat fit since you can setup your websocket as a consumer on a channel and pass that to all the pieces like the keyboard event listeners to write to.
It also lets you then setup an outgoing channel that you can cleanly hook up to your game state and make the changes received from the server into the atom.
The point of it is to introduce the decoupling so that as long as you implement some kind of thing that gives you an input and output channel, it'll work. You could replace the websocket implementation with a dummy test or replace the events and game state management with simple listeners and emitters so you have a nice seam to isolate bugs with.
I wish to implement a simple multiplayer Hangman game with the rule slightly bended.
Rule:
All the players have to guess the alphabets in the word at the same time. Whoever player guesses a correct alphabet gets a point, and the player who puts the ending alphabet gets bonus points.
This will be about speed. The faster correct guess gets you ahead of others.
I intend to have a Qt/QML based GUI and the programming language will be C++. Platform will be Linux.
I am thinking I'll need:
- One thread for handling user typing.
- Second thread for parallel display of what other players are typing.
- Third thread for parallel display of scores of every player on every player's screen.
Do I need these 3 threads or I am barking the wrong tree?
It sounds like you're planning to have this game communicating over the network, where each player is using their own computers and running a copy of the program.
You should only need one thread for the application, but you might decided that more threads will make it easier on you.
You can easily connect signals from player's typing (either use an event handler, or connect your widget's "editingDone" signal.) to the appropriate logic for updating the scores and showing the other player's answers.
I think you'll run into the most problems with deciding on how to properly network the application to all instances, assuming that that's what you're trying to do. But the Qt network stack can allow you to do asynchronous network communication without having to manually create new threads.
I'm currently trying to write (as a part of "simple multiplayer game as an example of real time client-server application" assignment) multiplayer game server for simple fast-paced game for few players (less than 20 i think). I'm using TCP sockets for packets that require guaranteed delivery (ie.: chat messages, login and logout requests, ping packets, etc) and UDP for everything that does not necessarily need to be delivered since only the last packet that got through is important (ie.: user input, game world and objects updates, etc).
I should mention here, how my game world looks like. Every object server side has its id, role and owner members. Id is basically identifier for clients so, once I send them object updates they know which object to update on their side. Owner is information about object owner, ie.: player which controls the actor. I use it to remove orphaned objects once player loses connection / logs out. Most objects however has this value set to Server. And finally role determines whether object is important to clients. This can be set to ServerSide (for objects that do not need to be replicated to clients as they are only used in server side game state calculation), RelevantToOwner (this objects get replicated only to their owner, ie.: player private inventory does not need to be replicated to everyone), RelevantToList (object gets replicated to all players from list, ie.: i have list of players to whom the object is visible and i replicate only to them) and RelevantToAll (replicate to everyone).
When user sends login packet I check whether I have free slot and if yes, then I replicate world to him (send current world state - every object that does not have role set as ServerSide or RelevantToList - unless of course the client is on the list for that object).
Then after each iteration of server game state update loop I send exactly same thing - whole world state.
When users send logout packet I remove him from logged in clients, free slot, and remove all orphaned objects from game world (objects that had this user as owner).
Here are my questions:
Is this model suitable for real-time multiplayer game or am I doing it horribly wrong?
Is there a way to reduce amount of packets sent after the initial world replication (ie.: updating only objects which state has changed since last iteration. I've given it a thought and so far I've encountered one huge problem with this approach - if UDP packet from previous iteration is lost and state of the object haven't changed in subsequent iterations, the object will not be updated on the player side.)
How can i pack multiple object updates into one packet (I'm currently sending one object / packet which is inefficient and also probably horribly wrong.
Could someone point me to some working example (source would be nice) of simple Client/Server game so I can see how professionals do it? C++ or C would be nice but Java / C# / Python are fine too.
This depends a lot so much on what type of game you're talking about - example: Im doing roughly the same thing in a text based muck game.. My updates are simple, on arrival, send room details. On change, send messages to say people/object came/went. Done.
UDP is how most online games work just because they need to deal ith 100k+ connectios. UDP loss is often why players "warp" in game. If you're doing 20 people and you can guarentee that, then sticking with tcp will help.
do you need to send them the whole world? Is your world not made of zones/rooms. Normally you send the smaller area. It also depends on how much data on the objects within that you should send, for example. If a player has an inventory, no point sending that to all the other players unless they specifically ask for it - items worn (if a visual game then yes you need to or it draws them wrong)
Just because we have much faster connections these days doesnt mean we shouldnt take into consideration some people dont. You should try and send updates only and have the client maintain its own state, and then, when you change zones, and reload the area, you ensure sync.
To pack object changes in a packet, most likely Im guessing its location changes, eg co-ordinates, and availability, eg, person picks up item. Have an upate structure, item_id, update_type, update_values[], then you can send a chunk of updates.
Are you after text based or more mmorg type? text based I can say google tinymuck, or tinymush, tinymud, there are plenty, graphics ones? thats harder, you could lookup some of the old EQ code and WoW emulators maybe..