This is the story of how we met with Lumberyard in our office. For people who never heard of Lumberyard, it is a great tool to create visually stunning video games or immersive entertainment experiences. It powers many highly acclaimed games such as New World and Star Citizen, both extremely ambitious massively multiplayer games with huge open worlds. When we learned that this Hollywood grade engine can also build for mobile, it became a must to give it a try!
This is Diego from TestFairy, and this post will be written in a personal tone for a change. I believe it is OK for me to claim that I am the one who spends most of his/her free time playing video games (thanks to not having kids, yet o.O) and tinkering with game engines in the office. My love for RPGs is a deep one and I believe the mobile scene can always welcome more RPG games built with love and care.
Imposter Syndrome Revisited
If you ever tried to create a game using a game engine, you might have stumbled upon a few roadblocks here and there when you tried to export your game for mobile. Game engines use native mobile SDKs to be able to compile and package their final builds for the target OS. This can sometimes become a not-that-of-a-straightforward experience which makes me feel a little stupid. Lumberyard caught me off-guard on my first attempt. Normally, when I want to try a new game engine, my personal workflow looks something like this:
- I go to the engine’s website and download it
- I wait for the installation to complete while reading the engine docs
- I try to build a “hello world” scene
- I click a bunch places to build my game for mobile
- I am given a cryptic error message which I google and reach no helpful result at all
- After reading through deep forum posts and Github issues, I finally figure out the steps I missed during installation
- Fixing my local installation, I retry with a new build
- I upload a new build to my device and it crashes
- Suspecting that the crash implies a few missing native libraries which are dynamically linked, I try to fix my configurations to include necessary files
- After trial and error for a few days, I succeed and take notes in order to avoid the same mistakes in the future
- Reading my notes again and again to obtain muscles memory, I feel like I’m preparing for a GDC talk which I’ll never give
- A few months pass and all my notes become obsolete due to a new upgrade in the engine, I sigh…
For Lumberyard, it was different. Lumberyard’s docs although being thorough in textual explanations, also lead me to a ten minutes long Youtube video, explaining the workflow step by step in real time. This is my first time setting up an engine by following a video tutorial and I admit, it was refreshing.
When you download Lumberyard, it is shipped with a setup utility called Setup Assistant. It can download all the dependencies required to create a mobile game with Lumberyard, including the engine source code and native platform SDKs.
Having open access to the game engine code is a huge win. It allows me to modify existing functionality without worrying about ABI breakage and dynamic linking issues.
I normally use a Macbook to develop for Android. This meant Lumberyard would need to work on a completely fresh Windows machine, which doesn’t have any of the developer utilities you expect to have on a workstation.
Steps
Setup Assistant is a self-documenting tool, which asks you for your intentions, and provides the necessary steps to prepare a development environment for your needs. In my case, I told the assistant to enable these for me.
- Compile the game code
- Compile the engine and asset pipeline
- Compile the Lumberyard Editor and tools
- Compile for Android devices
It then told me I should install the following components, which I did by clicking a single button!
- Android Native Development (NDK)
- Android Software Development Kit (SDK) Tools
- Java SE Development Kit (JDK)
After installation is complete, I created a new project with the Project Configurator. This tool acts like a project management utility + package manager of GEMS (3rd party dependencies) for all your projects. It can install these GEMs to enable functionality such as VR and ad network integration. I admit, I got distracted and wasted an hour exploring for no reason. It was fun nonetheless.
The docs told me I should enable Open GL ES 3.X for my Android builds which I did by making the following change in the lumberyard_version\dev\AssetProcessorPlatformConfig.ini configuration file.
[Platforms] ;pc=enabled es3=enabled ;ios=enabled ;osx_gl=enabled
Making the change, I ran the following command in cmd and it created a fully working Android Studio project with gradle, cmake and stuff, configured more beautifully than I’ve ever accomplished for my personal NDK projects.
lmbr_waf.bat configure
If you ever worked with NDK, managing multiple CMakeList.txt files can sometimes become confusing. I created a backup of this project to learn from it for non Lumberyard projects as well. Learning to use gradle modules to decouple functionality in plain java projects is a really useful skill. Lumberyard carries that lesson into the native world by showing how NDK can utilize the same flow with the help of cmake. Feel free to take a look at this post to learn more about modules in gradle.
Anyways, I check out the created project to learn how Lumberyard structures its java and C++ code. There is a LumberyardActivity as you can expect, a detailed manifest, a slightly modified gradle script and lots of dry modules with little to no config other than a cmake file.
I plug my device with usb and click run.
It starts building and… Wow!
First builds can sometimes be long but I didn’t expect this long. It takes an hour before my game runs but it is definitely worth it. My phone screen changes and I am shown my game, running in 60 fps with 3D graphics which I am only used to see on a muscular gaming PC.
At this point, I am kinda scared. I make a few changes in my “hello world” game and click run again in Android Studio. This time the cache kicks in and the game launches instantly! All hail the gradle modules! Thanks Yigit Boyar, you weren’t lying when you told us it’s not gradle’s fault if it builds slowly.
Back to Work
Gil asks me from Slack about my results and I explain him my findings. He reminds me that I should test it with TestFairy which I totally forgot and it was the very reason why I started this whole enterprise.
I run the build command from cmd this time and wait for the APK.
lmbr_waf.bat -p all build_android_armv8_clang_release --package-projects-automatically=True
When the commands returns, I notice that a new folder in my Lumberyard installation is created, named as BinAndroidArmv8Clang. Inside of it is my APK and all the dynamic libraries for the armv8 architecture without the stripped symbols!
I run curl to upload my build to TestFairy and in a few seconds, everyone in the office has my crappy game in their phones.
curl https://upload.testfairy.com/api/upload -F api_key='NOT_123456' -F file=@BestGameEver.apk
I feel empowered! I can now start working on my dream MMO, if only I had an artist friend to help me in the process. 🙂
More Useful Guide without Me Mumbling
If you are ready to try it for yourself, I created a much shorter version of this post in our docs. Feel free to let me know if I did any mistakes in my instructions. Have a nice day hacking!
