next »

[agnasg]

tilemovers is a fun puzzle game. The objective is to move the red tile to the goal position (different in each puzzle) by sliding the other tiles out of its way.  150+ different puzzles in 3 levels of increasing difficulty.

What's going on? Is this real life?
(it has lore)
"Never moving from point A to point B had been so challenging!"

From the depths of the underworld emerges the nefarious Zootmer, diabolical architect of intricate dungeons and labyrinths. Builder of prisons, Zootmer will do the impossible to avoid the escape of our hero to the vortex of light, an infinite system of passages where with skill and dexterity and overcoming terrible enemies our hero will be able to find the way out.

Game Additional Info

This is a solo developer project. You can learn more about my 6+ months journey below.
Also, the game is already on itch.io please check it out: https://agnasg.itch.io/tilemovers
I'm looking for testers for the Android version: please download the Android version
tilemovers on Google Play


Notes about the migration from the Windows version to Android.
I will work on:

C++ (no surprises here)
SDL2 (could be Qt but the paraphernalia is too flashy (and paraphernalic), which I'm not saying that SDL2's is not, but it's more for the Android Studio (AS) issue).

Challenges

SDL2. The problem with SDL2 is SDL. There are two versions and everywhere (StackOverflow and even some SDL tutorials sites*) the philosophies of both are confused. The approach is slightly different and the calls are different. Bottom line, SDL2 looks like SDL but is different.

Android. I've already done some things, nothing fancy, so this is new, or almost new. I don't know Android Studio so we'll see.

Now, the problem from the business point of view is that this project (publishing an application in the play store and making money with it) is supposed to be something that should not last more than 2 weeks from start to finish: I'm already on my second one and the application is just ready to start the migration. Besides the migration, there is a lack of marketing, many other things. (NOTE: since I wrote that until today it has been 1 2 3 4 5 6 months).

It's like the process of entering Tiragarde Sound (World of Warcraft) an alt, it should be fast (10, 15 minutes?) But in reality, it's 2-3 hours.

Note: this section discusses my vicissitudes migrating tilemovers to Android. It is an adventure with lots of action, intrigue, ambushes, romance, suspense, and a happy ending.

Starring:

Android Studio (AS): the development environment (something like Visual Studio)

Gradle: the build system, allows to organize and execute the compilation and link with all the components involved.

ndk: Native Development Kit, a set of tools that allows using C++ with Android.

For Android installation, which I do for the first time (as I said at the beginning I have never worked with mobile app) I followed this guide. https://lazyfoo.net/tutorials/SDL/52_hello_mobile/android_windows/index.php. There are other guides on google, but this one seemed to be the best.

Note (04-01-2021): another guide is this one that is slightly updated and has detailed explanations. Unfortunately, I found it very late. As the author says, "you are entering the realm of Android development... take a deep breath...

Problems encountered: many, including some unexplained. One of the many pitfalls (something that particularly happens with Java applications) is that there are multiple versions of multiple packages and compatibility tables between packages and multiple errors due (perhaps) to those incompatibilities. For example, here are the compatibilities between versions of Android Gradle Plugin and Android Gradle: working on this project I had to check innumerable times StackOverflow, and find tables like this very often.

Another error that appeared and is not included in the guide:

Unsupported method: TaskExecutionResult.getExecutionReasons()

The console indicates that there is an incompatibility with Gradle without giving further details. One step that I skipped in the guide is step 12 because the error did not appear to me:

Minimum supported Gradle version is 4.1. Current version is 2.14.1.

Well, in the new version, or because I had the 3.1.x version the error message is different (after several stumbles, slips, falls, laughs, disconsolate screams at midnight, screams and other manifestations of frustration the message "Minimum supported Gradle version" appeared without explanation. If it was always there, I'm not sure now) . To solve it, open the project's build.gradle file and modify the line

classpath 'com.android.tools.build:gradle:3.1.4

a

classpath 'com.android.tools.build:gradle:4.0.2

and in the file gradle-wrapper.properties the line distributionUrl should read

distributionUrl=https\://services.gradle.org/distributions/gradle-6.1.1-all.zip

(Here 6.1.1 should be replaced by the latest version).

The window will display a link to do Sync, which will allow you to download the update.

Android Studio is a difficult horse to tame. How do you define the architectures to be compiled? By default, it compiles them all, "armeabi-v7a", "armeabi", "x86", "x86-64", "arm64-v8a" (answer). If I am going to change an asset, what should I do? If I press "rebuild", it starts compiling everything again, that's not what I want, but that the final apk includes the new assets. How do I create a new project based on an old one? I'm surprised that "Import" from an old project is the same as "Open the project", apart from opening it doesn't do anything else (this can cause problems, right?) (at the end you simply copy the folder and open the project from the new folder).

Eventually, I got the answers to these and other questions, but you have to be prepared to spend time on it (i.e. the learning curve is steep).

My impression is that the installation process and application settings are very detailed and change as the versions of the plugins and packages change. It is best to download the application and start working step by step. Eventually, everything works.

Other ambushes?

The abiFilters variable that indicates which architectures will be supported by the Android executable (the possibilities are 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64') should only be modified in the file build.gradle of the application (the one in the app folder) can also be adjusted in Application.mk usingAPP_ABI := armeabi-v7a arm64-v8a x86 x86_64 but it is either ignored or the effect is unknown (at least to me).

As a productivity trick you should have at hand the file build.gradle(:app) and change the variable 'abiFilters' to the architecture of the device you are using. For example, fishing the problem with the corrupted sqlite database, I had to test alternatively between the Pixel 2 API 30 emulator (abiFilters 'x86') and my cellular device (an old BLU R1 HD) (abiFilters 'armeabi-v7a')

Another curious note: the Pixel 2 API 30 emulator is not as slow as the internet says, you can work on it. I had to spend several minutes (more than I would like to admit) because I couldn't find how to get to Settings->Applications to delete the game and install it again (you can also do it in AS -> Tools -> AVD Manager). It turns out that in google pixel phone the menu with all the icons opens sliding from the bottom to the top (in all the android devices I've known is from top to bottom).

Still another much more curious note: implementing the movement by sliding the tiles requires a combination SDL_FINGERMOTION and SDL_FINGERUP. I had already implemented all the combinations and validations for the movement of the tiles, but I still had to create new functions especially for SDL_FINGERMOTION. The right way is to forget the amount of reported movement, at least the 2-3 hours I was translating those deltas into the right resolution, in windows and in all the combinations of devices in android, I determined that it is useless. Equally useless is trying to convert the float value 0...1.0 that SDL_FINGERUP gives to the correct resolution. My final implementation is to determine the direction of the movement with SDL_FINGERMOTION and do the calculations when SDL_FINGERUP is triggered.

In the next post I'll add a lot of more details of the migration process, the SQLite integration and more. If there are interest I can add more details about the Windows implementation.

If you read Spanish you can see a lot of details about all this in my blog micronosis.com

See you tomorrow.

[Rogod]

FYI: Your first, second & last links don't work

[agnasg]

FYI: Your first, second & last links don't work

Fixed. Thanks a lot!

[agnasg]

Some screenshots, missing from the first post:
Your mission, if you decide to accept it, is to move the red tile to this

Here:

or here:

or in other 150+ puzzles of increasing difficulty!
Features:

• 4 types of tiles 1x1, 1x2, 1x3, and the nefarious 2x2
• 4 behaviors: faster (move everywhere), static (can't move), angel (move vertically), and human (move horizontally).
• 3 levels of difficulty

Check out the video :

[agnasg]

Database handling. How to work a SQlite database on Android.

In this post, I describe how was the process of migrating the code of SQLite and the database from Windows to Android. Why my game tilemovers requires a database, is the subject of another post, suffice it to say, for now, that the idea behind programming video games is the intrinsic fun in doing it, that is, for me it has/should be fun to do it, and there is nothing more fun for me than programming games that use complicated databases. If someone has fun playing the game, it's a wonderful extra, but not required.

As I explained in the previous post, if it's the first time you program an Android app (and mobile in general) there are many obvious questions you don't know the answer to (although it's something a mobile programmer knows from preschool and Sesame Street).

Where are the files stored, and in particular, the SQLite database?

It is an asset like any other and is declared in the assets folder within the Android Studio file structure managed by Android Studio (hereinafter AS). That is to say,

\appprcmainassets

but you can't write there, those files are read-only. You have to move it to the data area of the application (it is said easy but it is a Russian novel to do it: read on)

And you have to ask permission to write in the database?

As the official documentation says, the application does not require permission to read or write in the directories assigned for internal storage (again, we are not talking about the assets folder, where it can only be read)

Why can't an asset be opened using ifstream or file pointers?

According to this answer in stackoverflow, because no. But in the scope of this answer, if you can use sqlite.c (i.e. you don't have to migrate SQLite to the java/kotlin version) but the database has to be in the data area of the application (why am I repeating this so many times? Because a skilled programmer with experience in other platforms will find it very difficult to understand that an application has at the same time 2 data areas assigned, one read only, and the other read-write-as-what-you-want).

After my research (which may not be complete, and may contain errors) The alternatives on hand for working with databases or data files in an Android application are as follows:

• You need to work with <code>AssetManager, AssetManager_open, AAsset_read</code> to access the database as is explained here. This is a solution to do it implemented in C using NDK. It is called SQLite-NDK.. This is a solution implemented in C using NDK. It's called SQLite-NDK. I didn't do this, although I leave the possibility open for other games, see below.
• The database stored in assets can't be used directly, you have to install it in  <br>"data/data/your-package-name/databases" (see point 5 below)
• An idea is to have the data in a json or xml file, create the database and then load the data (as explained here).
• Another suggestion is to use the Content Provider
• Another idea is to use a <code>DataBaseHelper class derived from SQLiteOpenHelper</code> to copy the assets database to the application's data area. Here is explained how is the process. This explanation seems to be clearer. This was the procedure implemented.
• To obtain the location where the database is going to be located you should use: <br><code>File dbFile = context. getDatabasePath(name_of_database_file);</code><br>(see here, and see documentation in developer.android.com, this function must be used or the application may fail on some new smartphones, for example, Huawei)

There are several challenges to making this work. First, we have to find out how to call code written in java from the application developed in C/SDL2 (yes, at some point the question arises why not migrate completely to kotlin (the native language of android applications) and the answer is that the idea from the beginning is to migrate an application developed in C++, on Windows using SDL2 to Android. Don't forget that).

The solution is simple as explained here. The next step is how to integrate a java class to an application developed using NDK, inside Android Studio (the reverse is easy and appears here, that is, how to use NDK from an application developed in kotlin).

The interesting thing is that seeing that article I remembered that Android Studio has menus, many menus, and among them there is a "Add Java class", which works but not necessarily on the name of the project (as my intuition tells me) but on the package folder that in the case of my sdl-based application is called org.libsdl.app

When adding the class, Android Studio asks which package we are going to add it to, we indicate org.libsdl.app. We copy the content of our class to the file created. This file is stored in apprc\main\java\org\libsdl\app

Our java file is basically a class ( DataBaseHelper ) that verifies that the database exists. If there is no copy from assets to the data area.

Please contact me if you need more information or help with this process.

[agnasg]

Modules

tilemovers can be broken down into 4 modules:

• The graphic system implemented in SDL2
• The logic of the game that implements the movements of the tiles, their types and the commands that govern them.
• The database module that uses a SQLite bd to store and load the game information.
• An editor that allows to create the puzzles and stores them in the database.

In this post we are going to talk about this last module, the puzzle editor. When I understood the need to have a tool to add, remove, change the type of tile, and save the changes, I set the following goals:

• Easy to use, that is, adding and deleting tiles should be quick and easy.
• Easy to change the type of tile (static, fast, angel and human)
• Integrated into the game to repeat the cycle of test, change, test quickly.
• Must be easy to implement

To meet all these requirements is inevitable that the control panel is congested especially because my goal is to work integrated into the game. I was looking at some ideas of how to make the guide, including panels like this one:



For which I would have to use a third library (the game is already using SDL2 and SQLite) and that is not good, at least for this project. I'm thinking about planning the study to analyze the possible use of DearImgui for the guides of the following games including the next game (memory + arcade + platform, still without name) and for khpx, but not for tilemovers because that was going to add more time to the already bulky project.

That's why I simplified everything and I kept an embedded panel with all the buttons:



The first line is operations with the tiles: exchange position, change their status, add new tile, remove tile. Then buttons to save changes, save as a new puzzle, options to generate a random puzzle (when it was uninspired). Also option to change level when your difficulty level was not appropriate for your current level. Finally buttons to assign the type of tile: faster (moves in all directions), static (does not move), angel (moves vertically, human (moves horizontally).

The operations of adding and deleting tiles are best seen on video:



Conclusion

I didn't keep track of how much time I dedicated to the editor specifically, but roughly it was about a month (which we could translate in 24-30 hours, which is what I dedicated monthly to this project). In comparison to the total time spent, I could say that the editor took up 20% of the project's time. I think this is the best time spent in the whole project.