I'm new to iOS (although I do have a lot of C++ experience) and I am working on a turn-based card game using gamecenter. Here's the catch - The player who's turn it is is the judge and waits for all OTHER players to play a card before the turn is over. Is there a way to do this in Game Center, so all players chose what to do simultaneously and once all have done so, the judge is notified, makes a decision, and then passes priority to the next player? For example, say we start turn 1. I ask the question, #"What is your favorite color?" to all players passing them a gamestate which has that as the question and them not having answered it. Then you respond, #"Green", and our friend Steve responds #"Blue". I then decide which is better, give one of you a point, and then whoever I gave the point becomes the new judge. My question is, how do I allow all players to respond simultaneously, rather than sequentially. I know that, worst case, I could sequentially loop around through players until it comes back to me, then judge it, but this would slow down my game and make it less fun. Is there a way to do this simultaneously?
I agree with NSSplendid about the API for turnbased games requiring sequential turns. The only truly simultaneous method would be using the real-time matches from GKMatch, and that isn't really an option for games with more than a few players.
However, the sequential version could be improved slightly by using a programmatic approach to game center instead of the default view controller.
Ending a turn fires off a push notification through Game Center, and by using GKTurnBasedEventHandler's method handleTurnEventForMatch:didBecomeActive:, you can receive that in your app. When the judge asks the question, have the users display that as part of the game, and have their responses stored locally until their turn. Once it becomes a given player's turn, they receive the notification, even with the app in the background.
In the method, it can check the locally stored answer and end the turn immediately, if they've answered. If they haven't, send the turn once the answer is complete. It's not truly simultaneous, but the judge gets the answers as soon as everyone has responded, without the players having to wait for one player to finish before they can enter their own answers.
The players won't get the notification that the judge has ended their turn until they open the app, but they can't see the question anyways without doing that. Another approach to this, though slightly wasteful, is after the judge ends their turn with their question, is to do a runthrough of all the players ending their turn as soon as they get the "Your turn" notification, so everyone knows a question has been asked, then doing the steps from the previous two paragraphs.
The iOS API is built around the model of sequential turns. While the workaround you mentioned will work, there is no way to get GC to do real concurrent turns. Sorry ):
Related
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'm really quite confused as to how I'm supposed to implement the following app. I have 90% of the code, but the last 10% I can't figure out. I can't figure out how I'm supposed to control the flow of events. I'll describe the app/game first.
The Game
The flow of events happens like this. The user sets the number of teams and the number of rounds. The game will then show a screen saying "Pass to team 1". The player on team 1 then presses a button which pushes on another view.
On this view, the current player tries to describe words/names on the screen to the other players on their team without saying them. Each time someone guesses a word/name correctly, the player presses a button which pulls out more words, and adds 1 to the score for that team. This continues until a timer runs out.
When the timer has ran out, this view will get popped off the navigation controller, and the previous view will tell the player to pass to team 2.
This will loop for the number of teams and the number of rounds.
My Problem
My problem is that I really don't understand how I'm supposed to keep track of all these events. I have a "GameBrain" class where I keep an array of scores and team names etc. but I don't know how to access this from each ViewController.
I asked a similar question earlier and someone suggested a Singleton class, but I've since read that this is bad practice and I can't help but feel that I should be able to do this following the MVC design pattern.
So my question is, how would you guys/girls approach coding a game like this?
Sorry for the kind of vague question. Any help would be greatly appreciated.
EDIT: Are delegates the correct way to go? i.e. Would I create the first ViewController that I need from my "GameBrain", set the brain (so self in this case) as the delegate for this instance, and have the ViewController call a "I'm done with this round" method on the brain which would then fire off the next ViewController?
Your GameBrain should be designed as a singleton, singletons may have some bad sides, but in your case they are the best choice, so just go with it
Since this class has to be accessed by all your viewControllers and since there is no need of having multiple instances of this class, then this would fit a singleton perfectly
I started with a comment but moved on to an answer.
In short, as #Omar says, for a quick little thing you describe the Singleton may work fine.
The longer version, several years ago I designed a quick little thing like this and we released it and all was well. Several months later we had several million users and had undergone multiple development phases and the Singleton pattern we had begun with was destroying the project. I might mention that my boss insisted at the beginning it was a small project and we would release it in two weeks and be done - hah, funny guy.
The reason the Singleton did not work well is because it restricted modularity. In the end, everything "game related" had to come back through this class which in turned sent a message to another class which sent a response back to the Singleton etc. etc. It was horrible.
If you have the time/energy, I recommend you create a GameBrain (or whatever) class for each game. This class is usually only ever used in the "game screen" anyway, so why keep it around when you are back in the menu or sending emails? If you need it persistent the make it backed by a database. If you only need it in one or two extra places (your winning screen might need to know who won etc.), just pass it along by reference - you should only need to do it one or two times.
Good luck.
Let's say, Tiny Tower. On this iPhone game, you can have shops in your tower. You can suspend or turn off the iPhone, but when you return to the game, you will be reported about the shop winnings during your time away.
There are also push notifications when a building is complete etc.
I fear I do not understand how that works, exactly. I'm not asking for the exact solution, I just need to know where to begin researching. One idea I had some time ago was like calculate the amount of seconds the user was away (current time minus the time when you left) and then calculate shop processing for every one of these seconds. But I'm not sure of that.
A better way would be to calculate before you close the app.
Figure out what time it is, then calculate when in the future certain tasks will be completed. This way, you can schedule push notifications to the server ahead of time.
If you calculate after you have re-opened the app, and you can't run processes with the app closed, how will it know when to push?
Take a look at this article about push notifications to understand a little bit better how they work.
http://blog.boxedice.com/2009/07/10/how-to-build-an-apple-push-notification-provider-server-tutorial/
For offline games you add temporal logic to your items and recalculate when game is launched. For online games you retrieve game state from the server, which is constantly recalculating for all users, even disconnected ones.
Game most probably does not actually process in the background (most apps are not allowed to do anything while in background). When you relaunch the game, it calculates how much time has passed, and then processes all the events that would have happened in the meantime.
Additionally, as Paul.s mentioned in comments below, as well as other people in other answers have suggested, on iOS4 you can use local push notifications scheduled before close.
It is either server side execution of the game or if it is a game of chance or something like Farmville where it's determined by time duration.
If you were to make a server and/or game like this then you would need to decide which route to take.
If it will be something where the user has good days and sometimes bad days then you'll need a lot more server power. however, if it's something like time based then you would be able to tell the last time they were logged in and the next time that they should be awarded. you can also take this idea and for each variable that you store, you store how long it takes to be complete and the start time. Then you would do a simple If then o see if the item is ready. The same thing can work for a number of visitors. Where you have 10 visitors per item per hour. If you have two items then each hour you will receive 20 visitors.