Hi guys, to anyone having problem running games on Android with the latest Buildbox 3D beta build 3049, I’ve found where the problem lies, at least in my case. Looking for a solution I realized that the generated app now takes much less space on the device than with previous build, about 20 Mb less so I suspected something was missing. I looked for differences in the project folders generated from Buildbox when you export to Android and realized that in exports generated with the latest Buildbox build (3049) there is a missing library named libplayer.so. I checked an export created like a month ago with the previous Buildbox build and this file existed at various locations, the one that matters is at: <PROJECT FOLDER>\android\app\src\main\jniLibs\armeabi-v7a
Here’s the fix
I copied the folder jniLibs\armeabi-v7a from the old project folder <OLD PROJECT FOLDER>\android\app\src\main\ and pasted it into the new project folder at <NEW PROJECT FOLDER>\android\app\src\main\ then ran the app from Android Studio and it finally worked but…
… it was very unstable, I’ve tested it with the game I’m working on, Space Runner 2600, and with the default Twisted Road template and the result is the same, the game only run for a few seconds before crashing. This all happened using Android Studio 3.3.2 and 3.4 (the latest one) with Buildbox build 3049. But then I’ve found a different version of libplayer.so which works way better. I’ve got two versions on my PC coming from previous builds: 1) 17734 Kb, should be from Buildbox build 3044, this one is very slow and crashes after a few seconds. 2) 18038 Kb, should be from Buildbox build 2429, looks faster and way more stable, no crashes at the moment but something is missing, like text labels, I guess that’s because such components were added in later versions. It’s not the best solution and for every build you have to copy the folder into your new build but at least it works and allows me to test the game on real smartphones. Now it would be just great to have an updated libplayer.so file for build 3049 from the developers while we wait for a better fix.
I’ve been working on a new game since February and posted no updates since then, my bad! Here’s a recap: Space Runner 2600 is a space runner game (duh) built with Buildbox 3D, what I’m aiming for is a space themed, fast paced, action game where you collect gems while dodging other spaceships and obstacles. A very casual game with a twist: in game choices! This is to allow the player to explore the game world the way he likes, giving him simple quick choices to literally change the course of his journey. Since the previous post in February, which was just a couple of weeks in the making, a lot has changed, at a glance you may see the flying saucer has been replaced by a spaceship and gems are way different. Of course most of the changes are in game mechanics as well as in ship movements and interactions with other static/dynamic actors, objects and environment, in short a lot of tinkering and scripting, that’s what I’ve been working on the most. I’m now starting to build levels, here are a few screenshots from the latest build showing three different scenes from Centauria City on Proxima B world. Like, comment and share at will! Thanks! 😀
The game I’m now working on is my first real attempt in 3D and other than working on the design and mechanics of the game, in the last couple of weeks I’ve been learning a lot about creating UV maps to apply textures to 3D models. I had little knowledge and negligible experience in the field so I decided to spend some time to master, so to speak, the matter.
In case anyone’s wondering: UV mapping is the 3D modelling process of projecting a 2D image to a 3D model’s surface for texture mapping. The letters “U” and “V” denote the axes of the 2D texture because “X”, “Y” and “Z” are already used to denote the axes of the 3D object in model space. (from Wikipedia)
Kill that polygon!
Along the journey I ended up improving my 3D modeling ability, especially regarding low poly models, something quite important if you’re trying to create a 3D game aimed to run decently even on older devices running on Android 4+. I knew it was important but I’m now aware of the fact that lowering the number of polygons in a 3D model as much as possible without ruining the model itself is quite a form of art. If you are going to create your own models then you have to be careful while making them, for example you might be tempted to use curved surfaces, they’re soo cute… but after all we are talking about making models for apps that will run on devices with small displays like smartphones and most tablets. On a small screen there will be little difference between a curved shape and an approximated or even a non curved one in many cases but you might end up with a tiny fraction of the polygons and this matters a lot in terms of computation required by the CPU+GPU of the device. Consider the model in the picture, it’s first design contained many curved shapes and was a few thousand faces (a.k.a. polygons), after redesigning it a few times now it is just 56 faces, more or less 1% of the original model. Sure, the first one was beautifully rounded, while the second one has rough edges, the point is that you really don’t need that level of detail in a model that probably will just fill up less than 5% of a 5 to 7 inches display. This is especially true considering that the model will be textured (which is: wrapped up by an image) and material/shaders will be applied so the casual viewer’s eye won’t be aware of the fact that your model is low-poly, it will look beautiful if you applied nice textures and shaders on top of it.
The first part of this journey ends here. More on this in next article:A BIT OF A PITA.