Hi,

I am getting to the point of my game where I have to start work on the server/matchmaking side of things. My game is a 2 player versus fighting game with short matches, 5-10 minutes each. Then possibly re-matchmake and play annother player.

One of my main constrains is a minimal or non-existent budget. But I am putting in a lot of work myself I have worked fulltime for more than a year already and will do a bit more than another half year.

My original idea was to just have a master server to run a list of currently active players and that server would do the matchmaking and then players them self would take over, one being listen server and the other the client player. So I wouldn't need servers for the matches themselves.

Now the programmer that I am talking to to help with the networking is suggesting we use the Amazon GameLift system. This would instead be a master server model where the master server would run the game and both players would be clients to that.

With this GameLift system, as I understand it, the servers get 'spawned on demand', instanced into existence when a match starts and then shut down again afterwards. You are billed per hour of uptime + outgoing(from servers) data.

Ignoring that I would have to redo a lot of my replication work to work with master server model instead of p2p listen server, I cannot see what I would gain from using a system like GameLift?

It seems more expensive, I calculate (pulling numbers out of the air) around 20usd per day, 5-7000 dollars per year with 10'000 copies sold and 100-250 game matches a day.

I would be locked to Amazon.

I'm not sure if ping would be better or worse? (maybe better average and worse minimum?)

Would it be slower to boot up a match as presumably the game itself would have to be copied to the instance and other stuff would need to happen.

I would still need a 'listing server' to log online players and do the matchmaking?

Advantages might be,

Less risk of cheating as master server would be running the game not one player. (this is a VR game so most players I think are into it for the experience, not just to win)

NAT issues would be easier to solve.

I could add spectating players more easily.

What do you folks think? Any opinions?

EDIT: Ooops just saw the GameLift post a bit further down, reading that now...

Cheers

Fredrik

You would gain two things:
- a bunch of code is already built and debugged by Amazon, and thus your programmer resources could be spent on other things
- Amazon can scale to very large player counts if your game is a whopping success, so you won't risk collapsing under your own load

If those two things aren't worth the cost to you, then you should say "GameLift is not the right tool for this particular job for these reasons" and stick with the previous plan.

Thanks for your reply. I'll continue ponder and research.

I was told that Epic's game Paragon was using GameLift or something very similar (home made?) and found this forum post by an Epic dev.

It seems like a lot of work, much more than I was anticipating. Maybe that is not all needed for a smaller startup indy game like mine, but I don't know?

https://forums.unrealengine.com/showthread.php?112363-Few-questions-about-Paragon-lobby-and-game&p=549816&viewfull=1#post549816

Cheers, Fred

That approach is mainly driven by the structure of the Unreal Engine.
If you are using Unreal, you may have to take a similar approach, or use a pre-made online subsystem like the Steamworks, Google Play, and Apple Game Center integrations.
If you're using your own system/engine, then you can build only the bits you need, which typically will be:

1) create account (could be web service)
2) log in to existing account (could be web service)
3) list and/or match to existing games (could be a web service)
4) connect to an exisiting game instance (should use your game networking, presumably UDP)
5) host a new game instance (should use your game networking)
6) report results into the matchmaker

Using web services for the account management stuff means that you can use HTTPS for encryption (great!) and you may be able to build an integrated online community easier (or your players can do this.)
If you want to support third party community integration, supporting OAuth for your authentication and authorization would be useful.
For NAT introduction to work, you need the actual game hookup to use your game networking connections, not ephemeral HTTP/S connections.
You'd typically use a web service to find a match, and be issued a token that identifies that match.
Then, the client connects using game-networking to the server using game-networking, providing the token, to start the match / NAT introduction process.
Once introduces, the actual game will run peer-to-peer; the server only needs to run game networking for the NAT purposes.

I am using Unreal. My first platform i most likely going to be Oculus but I am aiming to get to Steam as well at a later date, and I need players' from both platforms to be able to play each other due to small VR total player base.

Oculus have their own Online Subsystem plugin for Unreal. Would that remove the need for much of what the Epic guys was doing? (ignoring that chat client stuff, not relevant to me)

I read in that thread I posted above, that another dev who is starting to test AWS server instancing says that it takes him 'a few minutes to spin up a server'. That sounds a bit worrying. The Epic guy says that they keep a few instances started up and ready to get involved, the number of which based on number of players online and statistics. That would take some time to get working and also that would up the cost/hours of uptime since you are constantly keeping a few running on empty. Might make sense for a big budget big name game like that but sounds like a risky and too optimistic approach for me maybe.

Thanks again hplus,

your bullet point outline sounds like what I had in mind originally and I am leaning more and more towards that.

I was thinking of adding something like GameSparks to the mix to receive player data I want to store, so that I wouldn't have to spend too much programming resource on that. (though it still needs work to do ofc)