81monkeys: Transitioning from Desktop to Mobile

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,

Let’s jump right in!

CREATING A REAL-TIME ONLINE GAMEPLAY EXPERIENCE

The core element of the game is PvP and we knew we needed to create a real-time online gameplay experience. After trying a few approaches and failing, we decided to give Google Firebase real-time database a try. The problem was that we didn’t have the expertise or skills to create the extensions for Android and iOS. So, we took a chance and hired someone externally. This is where I first started to learn about extension writing. You can find the extension that was initially made for us here, and we have since added a bunch of our own functionality to it.

https://marketplace.yoyogames.com/assets/6401/firebase-ios-android-web

Hiring someone turned out to be economical for us, and I recommend looking into this option if you can’t find what you need on the Marketplace, or if you’d like to accelerate the development of your own extension writing skills. We’ll cover more on extensions in the section on Implementing SDKs and developing extensions.

MANAGING UI ASPECT RATIOS AND SCREEN SIZES

We knew that between Android and iOS, we would have to accommodate many different layouts for our game. Since our game was essentially a 2D board game, we could treat all the screens the same. We created our own system for managing our layouts, that takes into consideration the screen width and height, and places all the assets out accordingly. That means spacing, scaling and everything is handled by our layout manager. The benefit of this approach is that we’re able to manage and tweak every element of our game. For instance, on small phones, we need to make sure that the buttons are large enough to read and tap, but on a 10-inch iPad, these buttons would be huge. So, we added logic in for scaling on large devices for some objects while letting others take advantage of the extra space. This can be seen here.

sudoku

OPTIMIZING THE GAME FOR MID TO LOW-END DEVICES

It is important to keep the low ram availability of most mobile devices in mind when making your texture groups. A balance must be struck between your texture swaps and the size of your texture pages (Sudoku Scramble uses 2048x2048). With texture pages, you can micro-manage your ram usage by organizing your texture pages by game screen. In Sudoku Scramble we have a rule of not letting a texture group contain more sprites than can fit on a single texture page. GameMaker will allow you to add more sprites to a group than will fit on a single texture page. When this happens GameMaker will make a new texture page. But this takes control away from the developer as it can be hard to predict what sprites it will be separated onto the additional pages.

Tip: you can preview your texture pages by running the debugger and opening the “textures and surfaces” window. Textures will load only when the game is paused.

Keeping track of your render batches is a must if you are developing with low-end devices in mind. This means to make sure you render as many things off of a single page at once, as possible. This may even mean having some duplicate assets, however, if you have the room to spare on a page It can mean far fewer swaps.

sudoku

Tip: It is important to preload textures with texture_prefetch and texturegroup_get_textures to minimize lag mid game. Remember to flush them when you are done with them using texture_flush.

A great way to keep things small is to create a slicing system for buttons, popups and other tileable assets. We use a 3-9 slice system for all our popups as shown here.

sudoku

sudoku

Something that has made a big difference to our game is the use of SWF (vector) animations. We have over 100 animated avatars in our game, plus several other complicated animations, and we wouldn’t have been able to have them in a mobile game without SWFs. We use Adobe Animate to create our more complicated animations and import them directly from there. There are a few quirks to getting SWFs into GameMaker which will mean you will have to avoid making your animations too complicated. This may change as updates come out for GMS2, so make sure you’re doing your research.

Another trick to improving performance is to limit the number of instances at any given time. If a single object can be responsible for rendering multiple sprites, it is usually better to do that than have more instances. There was recently a fantastic blog post with information on optimization strategies for this problem. To avoid me reiterating what was said there, I recommend giving this blog a read: Optimization in GameMaker

CREATING TOOLS TO ACCELERATE MOBILE GAME DEVELOPMENT

Making a game that accommodates many different platforms means testing on many different devices. However, we won’t necessarily have access to every device we target, and it can take a lot of time to constantly build to devices. This is a problem as we need to ensure our UI can adapt to any screen aspect ratio. Our solution to this was to create a system that resizes the game window and application / GUI surfaces while testing on PC to reflect the aspect ratios of targeted devices. This allows us to rapidly test our adaptive UI without the need for an array of devices. We even added in notches for devices like the iPhone X to make sure it doesn't conflict with our UI.

sudoku

Creating tools for testing on PC is important, but it is equally important to create tools that can be used on your target platforms. Here we utilize the onscreen keyboard to issue debug commands. On PC the same tools work with a standard keyboard so we always have full debug functionality and control regardless of the platform we are testing on.

sudoku

The tools you develop can be for more than just debugging though. Here is a tool we made to manage our translations. This is one of many tools we have made to make the development as smooth as possible.

sudoku

IMPLEMENTING SDKS AND DEVELOPING EXTENSIONS

If you require additional functionality that GameMaker does not provide, then you may find yourself in need of extensions. If you’re lucky, someone will have already made an extension and published it to the marketplace, but what do you do if it doesn't implement all the functionality you require or has bugs after an OS update. Whether you need to update an extension or make one from scratch you are going to have to learn how to make and manage GMS extensions yourself. This was the case for Sudoku Scramble. Coming into this project I had a bit of experience writing code in Java(Android) and absolutely none in Objective C(iOS). Luckily there are a tremendous amount of free resources available for learning these languages. There are very few tutorials specifically about using them in tandem with GMS. For me, the hardest thing about learning how to develop extensions is understanding how to “translate” native iOS or Android tutorials into something usable with GMS. So here are a few things I didn’t know when I started out.

Before we get into specifics if you intend to write your own extensions refer to this document by Mark Alexander first. It covers all the basics of setting up a GMS2 extension for Android and iOS, which will not be covered in the following. I had a really hard time finding this information on my own, so I’m going to share this in a bit more detail than the other sections.

Let’s start with Android. Although most implementations can be done within the tools GMS provides, some SDKs require you to edit the Android runtime to get the functionality you need. However, before you jump into modifying your runtime you should know a few things:

To find your runtime navigate to File > Preferences > Runtime Feeds > Master (Beta if you are on the beta channel). From there you can check the runtime location.

sudoku

Now if you open the “android” folder of your current runtime, you can see that it's laid out just like a standard Android Studio project. However, it is incomplete. When GameMaker compiles your android game, it uses these files as a base project. If you have snooped through any of the files you may have seen strings that look like this: ${YYAndroidCompileSDKVersion}. These are functionally the same as GameMaker's #macro feature and are replaced with proper values when GameMaker compiles your game. So, in other words, don’t mess with them, as they almost always correspond with a value set within the GameMaker IDE. Knowing this gives more context when implementing 3rd party SDKs as you can better relate the project files you are working with to those used in tutorials.

It is also worth looking through your asset cache after a build to make sure everything ended up in the correct place. The asset cache will contain the fully assembled version of your android project so looking through this can help you debug errors and ensure that GameMaker is placing everything where you expect it to. You can find this folder by going to File > Preferences > General settings > Paths. Under the IDE heading look for your “Asset cache directory”. Be aware that by default the asset cache is cleared out when you close GameMaker so keep that in mind if you find it empty.

When It comes to iOS SDK implementations, it tends to be more straight forward in terms of following tutorials. The only thing to look out for is that most tutorials mention the use of “cocoa pods” as the recommended method of implementation. There is not currently a good way of using these with GameMaker so go with the manual implementation option if available. Like Android, there are sometimes SDKs that require features outside of the tools GameMaker provide. But unlike android modifying the runtime is not as simple, as it would require editing the XCode project file itself. Often it is just easier to do the project changes you need in XCode. The downside to this is that these modifications must be done every time you compile a new version from GameMaker. In the case of Sudoku Scramble, we do extension development on android first. This allows us to set up our header files beforehand to reflect the Android version. With the headers pre-defined we can do almost all the iOS extension development in XCode without having to recompile from GameMaker.

Going from having no experience working on a mobile game to pushing one to market has been a tremendous learning opportunity. All these tips are born from many trials and even more errors. Although this guide doesn’t go into detail, I do hope that it puts more developers on the path to success.

If you have any questions, please ask us in the GameMaker Community forum post. Thanks for reading!