[career] Mobile game server side question.

Hey Lee,

It depends on what your server side should be capable of :)

First thing you can do is determine the functionalities by talking to the other coders, the designers and the producer. Even if you are in a smaller team where this roles mix up you can identify needs in terms of game play experience, business model and app performance. If you know that, you can decide (with the team) if you build the whole stack yourself or if you can use (cloud) services. You can even go down to setup our own physical servers in your office but this probably means that you cannot handle a lot of traffic (remember: app performance).

Nowadays building a backend can be more like assembling than actually building everything from scratch. It starts at the bottom, the infrastructure layer, where you can go for Infrastructure-as-a-service offers (Iaas) like Amazon Web Services or a layer higher at Platform-as-a-Service solutions (Paas) like Heroku, Mircosoft Azure or Google App Engine. At this point it´s also important to think about which kind of data you want to collect, how you want to store and access it, speaking of data base system and data ware house because Iaas or Paas providers not always support every kind of data system setup.

Still, you might want to keep the effort for all this in mind. You can build the most sophisticated system ever but if it exceeds the requirements its normally a wast of valuable engineering time. So, if your backend requirements can be nailed down to a specific set of features you can also go for a Backend-as-a-service solution (Baas) or even the offers of certain app service providers. The Baas solutions available out there differ and you want to find the one that´s matching your use case. Here it´s gaming, so you might want to take a look at NativeX, Playnomics, Applicasa or OpenKit for example. If you want completely spare the effort of doing any network programming, there are app services like swrve or playhaven who go for a special set of features.

If you go down this latter of building you own stack, so all levels of your software architecture, starting at infrastructure level up to the point where you are "only" integrating an app service via SDK or API always keep the road map of your game project in mind. If you want to have a special level of insight or control later in the games' life cycle make sure that your backend setup can do this because exchanging it ones your game is live will cause massive effort and you might lose users alongside the process which in a mobile game means they might never come back again.

Keep in mind: All this services and solution (can) have a price attached so make some calculation and get the OK from the management before building something in or at least before something goes live.

Hope that helps ;)

Cheers,

Christian

embraase

It depends on what kind of mobile game.

You can break it down generally into 4 types in terms of server-side requirements:

1) games that just use the server to store leaderboards and perhaps some features tied into in-app purchase etc

(eg the games really only communicate with the server at the beginning or end of the game)

2) games that need to communicate with the server during the game, in something like a slow turn-based game (Chess)

3) games that communicate with the server or peer-to-peer during the game, in a fast turn-based game (Starcraft)

4) games that communicate with the server during the game, asynchronously and rapidly (some FPS games, MMORPGs)

These requirements often call for completely different solutions.

For 1 + 2, some of the API / network game packages might be a great way to get going quickly.

For 3, I'm not sure.

For 4, in my experience, building 100% ground up custom code is often the way to go. That's what I'm doing for my own game, it is a real-time, UDP driven game server written in Google's Go language for C-like performance but with higher-language productivity. For this case, I typically don't see the need for a network SDK as writing the basic network classes isn't that much code. I was able to get a basic server framework going really quickly.

Mobile networking is like regular networking, except someone keeps pulling out the cable from your computer for 1 minute every 5 minutes.
If you can make a game that works under those conditions, you'll be well prepared.
Are you going to be the only one working on mobile services back-end, or will you join a team that's already doing it? If you're joining a team, you're likely to be able to learn from the others on the team. Don't be afraid of asking questions until you understand, because that's much better for the team than working on something you don't understand!

Hi,@embraase

Thank you for your terriffic reply! I will definitely have a good talk with my new colleagues to get familiar with the whole project especially the server part.

That's indeed the best way to blend in a new dev team. These advice about server infrastructure are quite valuable to me. I did some research based on the keywords you provided and made some notes on my own, hopefully now I've got some topics to start a conversation, it feels amazing!

Hi, @starbasecitadel

Diversity of c/s in mobile game! It's very helpful, Thank you! The team I am about to join is making a simulation game, basically the content is about ruling your nation, building your cities, gathering resources and war. So I suppose it's mode2.

Hi, @hplus0603

Thank you! your analogy is very interesting also inspiring! It's a team I am going to join so like you said, I will ask questions until someone get annoyed XD.

Hi, @starbasecitadel
Diversity of c/s in mobile game! It's very helpful, Thank you! The team I am about to join is making a simulation game, basically the content is about ruling your nation, building your cities, gathering resources and war. So I suppose it's mode2.

Welcome!

The good news for that is that it is an easier problem to solve (imo) than say case 3 or 4, because the latency requirements are much more flexible. If you are playing a simulation and you do your turn and it takes an extra second or two (occasionally), it is no big deal, versus a FPS or other action-based game where that extra 1 second lag could easily mean another player gets a free kill against you. Often in the kind of simulation game you are doing, you don't even need to write client-side prediction, so that alone drastically simplifies the network code.

The only "problem" is there are so many solutions and designs available for your case which are effective that it makes it harder to choose one :) Another limiting question would be how many players per game will it have. 4 players per game has fewer challenges than 10,000 for example.

Hi Lee,

I was just begin my mobile game server development two weeks ago. We use LPC(MUDOS) to get the job done. All the fundenmental level including DB and socket already been encapsulated into Hex files. And we are only care about the upper logic implement level.

Cheers,

Hi finanshow

Glad to know there is comrade out there, my studio have done all the fundamental levels such socket, DB

Currently I' m on the logic level to implement a quest system and its mgr.

cheers

p.s @hplus0603 How do I solve this specific situation you've mentioned?

"Mobile networking is like regular networking, except someone keeps pulling out the cable from your computer for 1 minute every 5 minutes."

Hi finanshow

Glad to know there is comrade out there, my studio have done all the fundamental levels such socket, DB

Currently I' m on the logic level to implement a quest system and its mgr.

cheers

p.s @hplus0603 How do I solve this specific situation you've mentioned?

"Mobile networking is like regular networking, except someone keeps pulling out the cable from your computer for 1 minute every 5 minutes."

Hi Lee,

On the logic level, which language you guys use? Lua, Python is been widely used here.

And another question: Is Erlang papular in your area or country? Now, I'm working in Canton@China. The biggest web-game company, then do use Erlang as their server programming.