Let's say I have an open world game that supports multiple players.
The game stores their positioning by X and Y in this world.
Also, whoever is playing the game can see a canvas of 11x11, where his player-self is represented on this screen, always centered.
The game world has 1000x1000 squares to walk using keys.
What I know is that:
I could emit events whenever a player walks,
check this event data at the server-side (to see if it is possible and the speed is correct/anti-cheating measures),
update the game state which contains all players and positioning,
re-emit this state from the server so every client would be able to render properly this new player.
The problem is, should I really update someone who isn't even being seen?
When everyone is walking around, moving items, earning levels, etc - those events are being emitted from the client, and that's okay, but thinking about the server-side, it will re-emit that for each update state, and, maybe that will be overloaded?
Also, sending the whole game state, even if it isn't being rendered, opens so many breaches to cheating that this made me think that there is another option.
I'm a beginner at Networking and Game Development, and that is being hard to get into my mind - so I decided to try and put it into a question. This way, maybe with someone reading what I'm thinking about, I might get some clarification. Perhaps I'm just thinking about it the wrong way.
Q: should I really update someone who isn't even being seen?
There is no need.
The normal way MMORPG games do in the server side is to cyclely process network packages and some other calculations like the connection of players like skill cast or something else.
The central of a server may look like below
void run()
{
while (true)
{
processNetwork();
processSkills();
processMoves();
...
}
}
The loop will run several times a second, like 20 frames a second is enough cause players can not feel the little frame, they think they move/play smoothly but the trueth is not.
For your question, player only need to see some little area, when he moves, the server will braodcast his postion to others in the area and the players in his area in the next frame.
And that is just the simpliest model, actual model will be more complicated and we will detach different functions of the game to different server, sucn as chat server, battle server, auction server and others.
What I'm trying to make
Hi, game development newbie here. The game I am trying to make is fairly simple. It's almost exactly like the old FC game "Ballon Fight" except that I'm trying to make it online where players can go through a match making to find opponents.
BalloonFight:
What I Read
I have read some articles, and found most of them lead to two approaches:
Put all game logic on the client, and the client sends player inputs to server on every frame update. The server acts like a dispatcher which only makes sure player A's input is received by both client A and B. My understanding is that if we see the client in this case as a pure function, and if the two players' inputs are received by each other, the game should produce same results on both clients. Thus synchronization is achieved.
Put all game logic on the server, and let the server do the calculations and send back results to both clients. In this case, clients only worry about displaying.
My Fears
Solution 1 sounded like a simpler one to me, but immediately I realized when network problem is put into account, it becomes incredibly complicated. Losing player A's connection for a few seconds means all the input is lost in that period. What I can guess is, to counter that, the server has to detect whether player A is lagged out and accumulate input from player B until player A is back then feed all the accumulated input to player A's client. Player A's client then need to do a fast forward to catch up. This sounds like there's huge amount of infra work on both client side and server side.
Solution 2 on the other hand looks very daunting to me, since for now I have only written some games on the client side.
My questions
in order to make a simple online game like this, what is the most beginner friendly way to synchronize game state?
if I were to use solution 1 stated above, is there any framework that provides such infra so that I don't have to handle network issues all by myself?
In advance, thank you game dev gurus.
What's the approach that should I use to develop an API that receives two moves and return a result (win/lose/draw)?
Scattegories game
Example:
Animal that starts with letter L
Player 1 - move: Lion
Player 2 - move: Lyon
thegame.com/api/v1/game/1/player/1/move/1
thegame.com/api/v1/game/1/player/2/move/1
How return the result to the players?
Should object player wait for the response or ask result?
What's the best way to develop an API with a callback?
Any other way to resolve this kind of problem?
Thanks.
Plurals are a bit more common, ie:
thegame.com/api/v1/games/1/players/1/moves/1
I think it's probably more logical for moves to be directly under the game, independent of players:
thegame.com/api/v1/games/1/moves/1
where each move has an associated player who made the move. This would make it easy to re-run all moves and understand the game history.
For players, their canonical URL would be independent of games
thegame.com/api/v1/players/1
You can still have a way to access all games for a player and all players for a game, if you like
thegame.com/api/v1/players/1/games
thegame.com/api/v1/games/1/players
Assuming this is a 2 (or more) player game with humans waiting on each other, you could probably make each client poll the game every few seconds. e.g. if a client has made the latest move, it starts polling the URL thegame.com/api/v1/games/1?moves_since=123456. This returns a list of all moves since the timestamp 123456. The timestamp could be the time the last move was made by this user. Once it returns a valid move, the client shows that to the user and waits for them to make their own move. If there are several players, the "game" resource could include a field like "nextMover" to indicate which player is next to make a move.
A more modern way would be to use something like Websockets so the client gets an immediate push from the server when changes occur. It's mostly a similar design but server immediately notifies all clients of updates instead of clients polling.
I coded a bomberman application that uses a gamekit peer to peer connection. The problem is that after a while the game isn't in sync anymore.
I looked at the sample code for GKTanks and used their model. There is no client/server relation between peers so I didn't use one in my game. Both peers maintain a gamestate which they update based on received data.
I have a NSTimer that's used for running the gameloop at each frame. The NSTimers aren't in sync so sometimes the gamestates become different ex: players pick up a powerup at approximately the same time and they both get the powerup because it takes a while to send data.
I would appreciate any idea on making the app work. I'm thinking of rewriting the code to use client-server but I'm not sure if it's a good idea... yet
Thank you!
EDIT: I changed the code such that a random player is picked to be the host.
Every time a player places a bomb he asks the server where to place it. The server returns the players position(as seen on the server) and then tells the player where to place the bomb.
For powerups the server checks if a player picked up a powerup and if he did it sends a packet informing him.
Another problem has appeared now. The latency between devices is high(I'm using a bluetooth connection). It takes around 0.2 seconds to place a bomb after the client tapped the button to place it.
I'm sending all data reliably. Am I doing this right?
Well preferbly you want a host-client relationship where only the host can manipulate the game state, so in your case it would be:
Both players rush to the powerup.
Host picks it up first.
It gets registered and the host recieves the power-up.
Meanwhile player#2 also picks up the power-up, sends the action to the host.
The host informs player#2 that the power-up is already disappeared.
The thing with your situation you are bound to get desynchs from packet loss.
With host-client relationship that cannot happen, the only problem is the host always has an advantage that becomes greater when the latency increases between devices especially on smartphones.
In a game like bomberman it's perfectly plausible to send the entire gamestate each time something changes instead of the action that was performed, this is to ensure both devices are in sync.
To sum it up: both users have their gamestate but only the host can manipulate both.
what you should do:
one of the devices is host, another one is client
host process all the game states and makes decisions, then it sends whole gamestate to the client
client gets the gamestate and just draws everything based on it - it doesnt make any decisions (who picked bomb, did bomb exploded etc)
client just sends input to the host (pressed left,right, pause etc)
that's it. if you try to make decisions on both machines, you will run into big troubles trying to keep them in sync.
I find that most game development requires a main game loop, but I don't know why it's necessary. Couldn't we implement an event listener and respond to every user action? Animations (etc.) could then be played when a event occurs.
What is the purpose of a main game loop?
The argument that you "need a loop because otherwise what calls the event listener" does not hold water. Admittedly on any mainstream OS, you do indeed have such a loop, and event listeners do work that way, but it is entirely possible to make an interrupt driven system that works without any loops of any kind.
But you still would not want to structure a game that way.
The thing that makes a loop the most appealing solution is that your loop becomes what in real-time programming is referred to as a 'cyclic executive'. The idea is that you can make the relative execution rates of the various system activities deterministic with respect to one another. The overall rate of the loop may be controlled by a timer, and that timer may ultimately be an interrupt, but with modern OS's, you will likely see evidence of that interrupt as code that waits for a semaphore (or some other synchronization mechanism) as part of your "main loop".
So why do you want deterministic behavior? Consider the relative rates of processing of your user's inputs and the baddies AIs. If you put everything into a purely event based system, there's no guarantee that the AIs won't get more CPU time than your user, or the other way round, unless you have some control over thread priorities, and even then, you're apt to have difficulty keeping timing consistent.
Put everything in a loop, however, and you guarantee that your AIs time-lines are going to proceed in fixed relationship with respect to your user's time. This is accomplished by making a call out from your loop to give the AIs a timeslice in which to decide what to do, a call out to your user input routines, to poll the input devices to find out how your user wants to behave, and call out to do your rendering.
With such a loop, you have to watch that you are not taking more time processing each pass than actually goes by in real time. If you're trying to cycle your loop at 100Hz, all your loop's processing had better finish up in under 10msec, otherwise your system is going to get jerky. In real-time programming, it's called overrunning your time frame. A good system will let you monitor how close you are to overrunning, and you can then mitigate the processing load however you see fit.
An event listener is also dependent on some invocation loop whether you see it or not. Who else is going to call the listener?
Building an explicit game loop gives you absolute control on what's going on so you won't be dependent on whatever some toolkit/event handling library does in its event loop.
A game loop (highly simplified is as follows)
initialise
do
input
update
render
loop
clean up
This will happen every frame the game is drawn. So for games that run at 60fps the above is performed sixty times every second.
This means the game runs smoothly, the game stays in sync and the updates/draws per cycle happen frequently enough. Animation is simply a trick of the eye, objects move between locations but when played quickly enough they appear to be travelling between these locations.
If you were to only update on user input, the game would only react when the user was providing input. Other game components such as A.I game objects would not react on their own. A loop is therefore the easiest and best way of updating a game.
It's not true that all kind of games require a dedicated main game loop.
Action games need such a loop due to frequent object updates and game input precision.
On the other hand, I implemented a minesweeper game and I used window
messages for the notifications.
It's because current operating systems aren't fully event based. Even though things are often represented as events, you'll still have to create a loop where you wait for the next event and process it indefinitely (as an example the Windows event loop). Unix signals are probably the closest thing you get to events on an OS level, but they're not really efficient enough for things like this.
In practical terms, as other people have indicated, a loop is needed.
However, your idea is theoretically sound. You don't need a loop. You need event-based operations.
At a simple level, you can conceptualize the CPU to have a several timers;
one fires on the rising edge of 60Hz and calls the blitting code.
Another might be ticking at 60kHz and be rendering the latest updates of the objects in the game world to the blitter buffer.
Another might be ticking at 10kHz and be taking input from the user. (pretty high resolution, lol)
Another might be the game 'heartbeat' and ticks at 60MHz; AI and physics might operate at heartbeat time.
Of course these timers can be tuned.
Practically, what would be happening is your would be (somewhat elided) like this:
void int_handler1();
//...
int main()
{
//install interrupt handlers
//configure settings
while(1);
}
The nature of games is that they're typically simulations, and are not just reacting based on external events but on internal processes as well. You could represent these internal processes by recurring events instead of polling, but they're practically equivalent:
schedule(updateEvent, 33ms)
function updateEvent:
for monster in game:
monster.update()
render()
vs:
while 1:
for monster in game:
monster.update()
wait(33ms)
render()
Interestingly, pyglet implements the event-based method instead of the more traditional loop. And while this works well a lot of the time, sometimes it causes performance problems or unpredictable behaviour caused by the clock resolution, vsync, etc. The loop is more predictable and easier to understand (unless you come from an exclusively web programming background, perhaps).
Any program that can just sit there indefinitely and respond to user's input needs some kind of loop. Otherwise it will just reach the end of program and will exit.
The main loop calls the event listener. If you are lucky enough to have an event-driven operating system or window manager, the event loop resides there. Otherwise, you write a main loop to mediate the "impedance mismatch" between an system-call interfaces that is based on I/O, poll, or select, and a traditional event-driven application.
P.S. Since you tagged your question with functional-programming, you might want to check out Functional Reactive Programming, which does a great job connecting high-level abstractions to low-level, event-based implementations.
A game needs to run in real-time, so it works best if it is running on one CPU/core continuously. An event-driven application will typically yield the CPU to another thread when there is no event in the queue. There may be a considerable wait before the CPU switches back to your process. In a game, this would mean brief stalls and jittery animation.
Two reasons -
Even event driven systems usually need a loop of some kind that reads events from a queue of some kind and dispatches them to a handler so you end up with an event loop in windows for example anyway and might was well extend it.
For the purposes of animation you'd need to handle some kind of even for every frame of the animation. You could certainly do this with a timer or some kind of idle event, but you'd probably end up creating those in some kind of loop anyway so it's just easier to use the loop
directly.
I've seen systems that do handle it all using events, they have a frame listener that listens to an event dispatched at the start of each frame. They still have a tiny game loop internally but it does little more than handle windowing system events, and create frame events,