Development Going Steady
Since last posting, development has been steady. The core gameplay, including platforms, double jumping, collecting coins, restarting the game, floating and the background are in place.
This post will be a bit different. I’d like to help other libGDX game developers by sharing my experience getting the damn project to build for html.
libGDX is Cross-Platform
One of the advantages of using libGDX is that it is cross-platform. That means I can write the code once, and build the project to run on whichever platform I want it to. Up until now, I’ve known this information, but have only built for Android.
It turns out building to the other targets like Desktop and iOS are relatively simple. (HINT: You might need to change the working directory to android’s asset folder, for example.) But this wasn’t the case for html.
I ran into a few hurdles when trying to build for the web. This is how I went about fixing those problems. Hopefully this helps others trying to build a libGDX game for web on a Windows system.
Step 1: Using Gradle to run html:dist
This was simple enough, especially using Android Studio. I used gradle to run the html:dist job, and crossed my fingers.
But of course it didn’t work.
The first error popped up, which seemed to have nothing to do with my code. It was this below:
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs
For some reason, I had to touch up the Windows Registry with this key. With the help of this Stackoverflow post, I opened up regedit and added the above key. First problem solved.
Step 2: Rewrite incompatible methods
The two Java methods I had problems with were String.format() and Class.newInstance(). Others may have more. But now you’re aware. We need to rewrite these.
The error for newInstance() looked like this:
The method newInstance() is undefined for the type Class<capture#4-of ? extends IScreen>
And the String.format() method was similar. This wasn’t too bad though. I pulled the formatting method out into an I18nBundle, and hardcoded a method to instantiate the classes I would’ve otherwise have done with newInstance().
For a project that doesn’t use these methods for example, errors might not come up at all. But I’m glad I’m aware of these issues now in the early phase of the project. I can imagine pulling my hair out two weeks down the line when I have many many more lines of code and more hours of refactoring to do. From here on in, I won’t use format or newInstance.
And that’s that problem gone.
Step 3: Finally, build, WAIT and deploy
Now I was able to run html:dist and… wait.
So here is ample warning: GWT takes a long time to compile. A LONG time. As in, I would not recommend anyone make html builds a part of their regular development cycle because of this. There is no way you can program, build and keep concentration going after the long wait. I couldn’t anyway.
It might sound like I’m exaggerating, but it was longer than 3 minutes. And my PC is pretty good. To me, waiting 3 minutes to compile is no way to program. My recommendation: build and iterate in Desktop or Android.
Once the html:dist job was through, a few warning errors popped up, but they weren’t critical. The crucial part was that the gradle build was successful. The built files were in html/build/dist and opening up index.html directly in the browser brought up my game. Perfect 🙂
And just to prove that it worked, I’ve uploaded a version of the game here. If you play it, let me know what you think. Early feedback is more than welcome.
And that’s how I built my libGDX project for html. Relatively easy after setting up once. Let me know how you get along with yours.