OFFICIAL Tech Blog: Transitioning from Desktop to Mobile

rmanthorp

YoYo Games Staff
Admin
YYG Staff
TRANSITIONING FROM DESKTOP TO MOBILE

81monkeys is a social and mobile game developer who released Sudoku Scramble, a two-player Competitive Sudoku game on mobile. They kindly wrote the following blog, which tackles the trials of mobile development.

This is the blog post that I wish I had read when I first transitioned to mobile game development. The following is an overview of the top challenges and solutions I faced developing mobile games in GameMaker Studio 2 having focused solely on PC games prior. This is about giving you an idea of what you’ll have to focus on when starting a mobile game project and starting you on the right path.

My background is not unlike most GMS developers. I first started using GM 5 in high school and had made a bunch of prototypes and PC games, before attending a game dev school. I landed my first job at an indie studio called 81monkeys. 81monkeys is a mobile game studio and they had already begun development of their first game, Sudoku Scramble. Sudoku Scramble is the world's first competitive multiplayer Sudoku game on Mobile. The biggest challenges we faced were,
  • Creating a real-time online gameplay experience,
  • Managing UI aspect ratios and screen sizes,
  • Optimizing the game for mid to low-end devices,
  • Creating tools to accelerate mobile game development,
  • Implementing SDKs and developing extensions
READ: https://www.yoyogames.com/blog/518/transitioning-from-desktop-to-mobile
 

rIKmAN

Member
Another good read, hopefully YYG can keep these articles coming regularly as has been the case with the last few.

Congrats on the release Stephane, hope it does well.
 

Pfap

Member
Was the texture page optimization strictly needed or just a precaution on your part? Were you running into noticeable issues on lower end devices?

The blog mentions you gave some other networking approaches a try, before finally deciding to go with Google firebase. Did you research other cloud providers, or how did you decide on Google? What were some of the approaches that failed?
Really curious about this one as I have been researching server solutions. I went to the Google docs for the real time database and was surprised to see the amount of features it offered. Did you do any price comparisons, or just went with the first that met your needs?
 

Stephane

Member
Was the texture page optimization strictly needed or just a precaution on your part? Were you running into noticeable issues on lower end devices?

The blog mentions you gave some other networking approaches a try, before finally deciding to go with Google firebase. Did you research other cloud providers, or how did you decide on Google? What were some of the approaches that failed?
Really curious about this one as I have been researching server solutions. I went to the Google docs for the real time database and was surprised to see the amount of features it offered. Did you do any price comparisons, or just went with the first that met your needs?
Hi Pfap, yes we did run into issues with our textures pages. The swaps were causing noticeable slow down on certain screens. We spent about a week just optimizing our textures pages (it would have been much easier if we had started doing this from the beginning) and assets, and it made a huge difference on low-end devices. There's actually still some optimization that we are planning to do, for instance, we're looking at reducing our sprite sheets to 1024, but we first have to evaluate the positive and the negative impact of it first, for instance, swaps for RAM usage and download size. The goal for a casual game should be below 50 MBs if possible. We'll update the post once we're doing our testing.

As for networking solutions, we use both AWS and Google Firebase, our matchmaker and primary APIs are on AWS, which hands multiplayer games off to Firebase once a match is found. We've optimized our Firebase data usage and clear it up after games are complete, which means that we haven't paid anything for Firebase and don't expect to until we have over a million users playing. We have also integrated many of Firebase's features like Deep Links, Remote Config, Analytics with custom events, and plan to add more in the near future. There are definitely some great platforms out there such as Amazon's Spark, but for us, Firebase made the most sense. Our game only needs to send tiny bits of data when users take actions like selecting a space and playing a number. These events don't happen that often, unlike a game with characters running around, which would need to constantly stream way more data than our game. All that being said, with the GMS extensions for Firebase, it's quite simple to set it up just to create a prototype or MVP.
 

Stephane

Member
Why do you want to switch to 1024x1024 pages? Do you think the larger texture page size causes any crashes, like the random libyoyo crashes that some Android devs have noticed?
We don't have a problem with crashing on Android, although it does happen, it hasn't had an impact on our users. As for the sprite sheets, we'd like to trim about some MBs off of our download size and reduce RAM usage if possible. We're not sure how much sprite sheets will impact this, but it's certainly worth testing. Like I mentioned previously, this may not be the best solution for our game.
 

Pfap

Member
Is your game completely stateless? Does it just use the http protocol or do you actually have a socket server setup? I'm mainly curious if you had any issues with Apple and their IPV6 requirement?
 

Stephane

Member
Is your game completely stateless? Does it just use the http protocol or do you actually have a socket server setup? I'm mainly curious if you had any issues with Apple and their IPV6 requirement?
Yes, I remember this being a concern. We use HTTPS for our server and then let Firebase (which user sockets) handle our multiplayer games. Firebase does use IPV6.
 

Pfap

Member
Yes, I remember this being a concern. We use HTTPS for our server and then let Firebase (which user sockets) handle our multiplayer games. Firebase does use IPV6.
I'm currently running a development server on a local machine, but I don't have it setup to work with an ipv6 address. So, we are only able to test our game when connected to wi-fi as our server is currently not accessible over lte or mobile networks.
I am using Gamemaker's built in networking functions, so I do hope they work with ipv6.

Is all of your networking code hand rolled with the Firebase extension or did you use any of Gamemaker's built in networking features?
 

Stephane

Member
I'm currently running a development server on a local machine, but I don't have it setup to work with an ipv6 address. So, we are only able to test our game when connected to wi-fi as our server is currently not accessible over lte or mobile networks.
I am using Gamemaker's built in networking functions, so I do hope they work with ipv6.

Is all of your networking code hand rolled with the Firebase extension or did you use any of Gamemaker's built in networking features?
We only use the built-in HTTP functions, the rest we made ourselves. It's certainly a challenge working with networking, especially if you're new to it. What kind of game are you making?
 

Pfap

Member
We only use the built-in HTTP functions, the rest we made ourselves. It's certainly a challenge working with networking, especially if you're new to it. What kind of game are you making?
I'm pretty familiar with networking, not so much with objective c or java though. I guess I may have to find a way to set up a proxy server over https as that seems to be working with ipv6, it seems that network_connect_raw may still not work with ipv6...

It's a multiplayer puzzle game that I was hoping to just run on a virtual server with an ipv6 address and gamemaker's own networking functions. The server is built with node.js and I'm going to be testing with an ipv6 server soon; so if network_connect_raw doesn't work with ipv6 it shouldn't be too hard to run all the data over an http proxy if I'm thinking correctly. I've been leaning towards using the Azure cloud and may possibly begin testing within the month. I would really like to be able to work with my own solutions and not be tied in with Firebase or any other proprietary tech from a cloud provider... something that's agnostic on which cloud it is run.
 

Pfap

Member
@Stephane I gave your game a test and I liked the way it felt, definitely fast enough. I think I have decided to give the Firebase route a go, it does seem to offload a lot of the complexity of managing servers. Although, I really wish Gamemaker had IPV6 and web sockets support.
 

Lonewolff

Member
@Stephane I gave your game a test and I liked the way it felt, definitely fast enough. I think I have decided to give the Firebase route a go, it does seem to offload a lot of the complexity of managing servers. Although, I really wish Gamemaker had IPV6 and web sockets support.
Really? I personally don't know anyone on the planet who uses IPV6.
 

Pfap

Member
Really? I personally don't know anyone on the planet who uses IPV6.
Because it is not really compatible with IPV4, so the only people using it seem to be the ones forced into using it... i.e. Apple developers or those looking to support mobile networks. However, I think the plan ( who's plan IDK ) is to eventually deprecate IPV4 and it makes sense to me... this is a case where having both is not good.
 

Pawel

Member
Hi, great article!
I am curious how you have implemented testing for different screens.
Can you share more details on that?
 
Top