Hey everyone -

New to the forums.

I'm in the process of getting a lot of the paperwork / notes and am stumbling a little on the multiplayer / network side of things. When it comes to mobile development, you can either go instant multiplayer (live), or have a turn based (notify when it's your turn to make a move).

E.g. (live play)

Hearthstone (card game), each player must have the app open and both playing and must finish the game before you can quit.

E.g. (notification turn based)

Words with Friends (scrabble), where each player can make a move without the other player being there. Then once that player has made a move the other player will be notified to make their move, thus continuing the game at their own paces.

---

The game I'm trying to make is a bejeweled style game where each game can take roughly 30 secs (if both players are connected) up to possibly 2-3 mins (if both players are connected) depending on the action of the game and what happens here an there, etc.

---

The main question is, if I do the live experience, what's the networking difficulty vs a notification experience?

Personal question for you, would you want a 'live' multiplayer experience or a notification experience when playing a bejeweled type game with multiplayer?

I'm 95% leaning towards live experience but would love to hear good arguments on why possibly it could be notification based.

Thanks for your replies!

PS> I am looking for some help with development, so if you're interested in working on a multiplayer bejeweled style game, let me know.

I think 30 second turns is too long for a Bejeweled-style live experience, but it may be okay depending on what else you dress it up with.
The distinction you're pointing out is typically known as "synchronous" versus "asynchronous."
For synchronous games, mobile is a lot harder, because most people use their phones intermittently, and must be able to drop it at a moment's notice.

For what it's worth, my day job has a synchronous mutliplayer match-three-gems game; turns are about 10 seconds. (If you want to try it, register and download the IMVU Windows client, then play the "Walk-off" game once you're through the tutorial.)

For match-three, synchronous or asynchronous aren't that much different in difficulty. Synchronous has some timing based challenges. Asynchronous has the challenge that you don't know whether the other person will return/make the next move, so you have to time out at some point, even though there typically isn't an active process/connection for the game. If you do asynchronous, there's also the question of how the other player is told of it being their turn (and what the previous move was.) So, I agree with you -- for your use case, synchronous sounds like a decent match.

I think 30 second turns is too long for a Bejeweled-style live experience, but it may be okay depending on what else you dress it up with.

The 30 secs I was implying too was game time, how long it takes on average to finish a game being the 30 secs is normally the shortest. When it comes down to the in-game timer per turns I was thinking 10-20 secs as a style for this game isn't really needing to much time to make a decision, plus the short time speeds up the games to be a lot quicker games.

Now I know the true definitions to what types they are thanks.

IMVU, lol, I remember that game, fun social experience.

Hi Skurt,

There is also a hybrid mode in addition to the two that you mentioned.

When there are live players who are entering a lobby room at the same time, it will create a live match.

However, when the aren't, it plays a recording of a past session to the live player. According to our research, players cannot tell the difference between playing against a live player or a recorded session of one.

About creating a completely synchronous game, I wouldn't recommend it. It requires A LOT of players in your game to create a good experience (players aren't willing to wait for more than a few seconds for someone else to join...)

IMO the the hybrid option would give you the best solution: synchronous when it's possible and "feeling like synchronous" when it isn't.

You can read more about the different game modes on Nextpeer's documentation:

https://nextpeer.atlassian.net/wiki/display/DEV/Multiplayer+Game+Types

As for help with development, with our SDK you can create a multiplayer experience in no-time as well as get more users for your game using our cross-promotion and other social tools. (www.nextpeer.com).

Disclaimer: I work for Nextpeer.

According to our research, players cannot tell the difference between playing against a live player or a recorded session of one.

That should be highly dependent on the actual game, and in particular, the level of interaction between the two players.

Sure, two people playing parallel match 3 or a racing game (without, or with simplified, collisions), recorded sessions could be sufficient, but try that with a game of chess...

I would think 'recorded' gameplay is not the way to go with a match 3+ game due to the fact you need to know what the players are doing. I'm needing help developing this game, mainly the networking...etc, I'm more the art / office side of things but I wanted to post a description of the premise of the game and hopefully anyone would love to join up. Nothing serious, just something mega simple and fun :D

About creating a completely synchronous game, I wouldn't recommend it. It requires A LOT of players in your game to create a good experience (players aren't willing to wait for more than a few seconds for someone else to join...)

+1 what he said..

Design your game for async or replay multiplayer, and if you get to a few thousand *simultaneous* users, then think about a sync multiplayer option.

About creating a completely synchronous game, I wouldn't recommend it. It requires A LOT of players in your game to create a good experience (players aren't willing to wait for more than a few seconds for someone else to join...)

+1 what he said..

Design your game for async or replay multiplayer, and if you get to a few thousand *simultaneous* users, then think about a sync multiplayer option.

Why wouldn't a game where you play the player instantly (when you click 'find player' and it searches for a few sec or so no matter the skill level) work out? A match-3 game isn't something you want to take to much of your time on i would assume, just finish the game as quickly as possible and move on to the next one.

I was just curious, trying to see why a notification (player A has made their move) > open app > shows player's A move > Player B turn > submit move > close app....repeat.

Why wouldn't a game where you play the player instantly (when you click 'find player' and it searches for a few sec or so no matter the skill level) work out?

It needs a specific number of players to "bootstrap" itself.
Let's say there's 1,000 players who are interested in the game for a given 8 hour period.
Let's say that each player is prepared to wait for 30 seconds for another player to show up.
This gives players approximately 40% chance of matching to another player before giving up, in the given time period (given that, if three players show up in the same interval, the first two will be matched and the third will be alone.)

If I try to play a game, and 60% of the time, I can't find another player to play at for 30 seconds, would I keep playing that game?
I guess it depends on how good the game is, and how important the synchronous multiplayer is.
Throw 10,000 players at it in the same interval, and you don't have a problem.

One way of bootstrapping this kind of game might be to match against an AI if a real player isn't found within a given time limit.

One way of bootstrapping this kind of game might be to match against an AI if a real player isn't found within a given time limit.

Now that sounds like a better idea for sure. I've seen that in say PC gaming before, but never really mobile gaming.

What about this:

Player A joins the ''player search que", 45 secs later Player B joins the Que....and within 2-5 secs they find each other. Is that doable? Basically the 'behind the scenes' of things that complicated? I'm not a programmer so it's a little harder for me to understand the real definition of waiting for someone...

It would be kinda the same thing even if it was just say 'replay style' since you have to wait till a player joins your game in a way. So you 'start a match', you do your turn, then quit the app, and in the background....ohhhhh wait, I'm getting it now, you've already done your move and can move on, then wait till the other player makes their move....The issue with this game is, I think 'most' players would prefer to just play a game to its full entirely vs waiting per move, etc.

I already know I'm going to have to try out both methods and see which is more productive for the app and for the players.