Ancient Star
Development log
Project maintained by iktools Hosted on GitHub Pages — Theme by mattgraham
Research screen
by Ivan Kravarščan
And research screen is done. Man that was quick! I expected it to be more complicated since it has a lot of stats to show and some tricky layout. But the layout was a problem in the base Android UI, not in LibGDX and stats were fairly straightforward to copy-paste-modify. Only small complication were radio buttons for selecting a tech field. LibGDX doesn’t make a distinction between checkbox and radio button. They are the same component with different styles. But there is a grouping object that enforces how many are “on”.
Web build
This has been bugging me for a year or two. When I started LibGDX rewrite I noticed they offered targeting web platform too, with come caveats. For some reason I find the idea of having Ancient Star running in the browser super cool. It’s the ultimate demo. When I browse games on itch.io I’m more likely to download one that lets me check it out on the store page, and I’m more likely to come back to such a game.
The framework used offer two ways for making a web build, GWT and experimental TeaVM. Back then GWT was the recommended method but it had, and still has, a huge downside: it can only work with Java source code. The actual letter of the source, not the bytecode that is produced out of it. That is a show stopper because I made the game in Kotlin which is an alternative for Java. Even if the game was in Java, I would not be allowed to use any dependency because they are predominantly distributed without source code, only compiled bytecode.
Over time TeaVM slowly moved from experimental to fully supported method and I took one week to get it working. It turned out that my module setup and build scripts that I cobbled up during previous shallow attempts were actually good but I need to change game code to not use functions that TeaVM doesn’t know how to translate. Most of the issues were trivial and the bulk of the work was moving multithreaded turn processing outside of the crossplatform code module. To clarify this word salad, the source code is split in multiple modules, the bulk of the game code is one module, desktop launcher is in another, Android launcher is in third module, and so on. Launcher modules have all the knowledge of their respective platform and their purpose is to make the app package that bootstraps the common game logic. The problem was that web platform has no multithreading so common game code can’t use it. The web actually does have a different form of concurrency but getting it to work with existing code was not free. So I moved things around, usual programming stuff, make more folders, move old stuff there, make old place reach it through interface, etc.
With that sorted out there were of course a few more minor issues, it would be too good if it just worked. But with them sorted out too, watching the game run in the browser felt like magic.
tags: