Which 3D engine to use?

Well, it’s time to pick which engine/sdk I am going to use to make my dice game.

Now the big question is what game engine to use. There may be many to choose from, but from a mobile app perspective, there seem to be only 3 that I would want to use. Of course, I’m ruling out Unity, because it is not open source. I’m trying to make an open source game, and I’d like to use open source tools so that anyone can openly tinker with it. I’m also ruling out several that work for Android, but the sdk is only available on Windows computers (irrlicht for example). That leaves the three main options of LibGDX, GoDot, Ogre, and jMonkeyEngine. There may be others, these are just the ones I know about.

Above is the quote from my post last week. I needed to do some research to decide which 3D engine and SDK (software development kit) to use to make my game. As I said, I’m sticking with open source tools, so that ruled out Unity and several other big name brands of SDK’s. I also am using a Linux computer, so it can’t be an SDK that only works on Windows or Mac. So, that leaves me with four main options that I could come up with. Obviously there are more options out there, but I’m trying to stick with ones that meet these criteria:

  1. Active development – Something that is still modern and will get updated over time, so I don’t have to learn a new SDK after I get the hang of this one.
  2. Guides and example code – I’m new to this, so I need it to have plenty of examples and guides to springboard off of.
  3. Active community – A place where I can go to ask questions if I get stuck.
  4. Easy Android integration – The whole point of this is to make an Android game, so it should be easy to get to that point.
  5. Java or C++ compatible – I don’t want to learn ANOTHER programming language just to make this game. I want to use and improve the tools I already have.
  6. Easy to use – It needs to make sense to me, or it will not work. If the API calls are ridiculous, I wont accomplish much.

So, with those in mind, I have sorted it out between my top four choices. Before I get to that, though, there are a lot of other options, but they don’t meet the above criteria, so I couldn’t spend my time on them, even though they may be great engines to use. That said, here is the breakdown of my thoughts on the top four choices, and what I plan to do. It’s not really a review, just my thoughts on what to do.


I’ve actually used libGDX before, to make my open source game “Critical Velocity“, which was a 2D side scrolling space ship game similar to flappy bird. It does have an active community, is still being developed, and has lots of guides and tutorials and example code to draw from. It doesn’t have an SDK, you just add the java libraries to your app and use your standard Android SDK platform to build it, which is a big plus.


The only downside is that it is made for 2D games with 3D kind of as an add on, which seems to still be under development. But, I would be familiar with it, since I’ve used it before, albeit for a 2D game. It also doesn’t have an “SDK” it is rather a library that you add to your own app.


There are quire a few perks to using jMonkeyEngine, it is actively being developed, and it seems to have a pretty good community behind it. There seem to be a lot of guides, documentation, and explanation of methods and classes, which is super helpful for me. It also seems to be a well fleshed out 3D engine, with a sustainable future and some neat features, most of which I am too new to understand. All the programming is done in Java, which is a plus for me, since it is a language that I am already familiar with.


I am not sure if I can see a downside to using this setup. It seems to be pretty solid, there are a lot of indie games made with it, and it even has book tutorials on Amazon, so this might be a good direction to go. I tried it out a little bit, and got confused right off the bat, but I’m not sure it that’s because of the interface, or because I am new to 3D game development.


Next up on the list is Godot. Hailed as “the game engine you waited for”, it seems pretty impressive. With a super permissive MIT license, an attractive interface, a visual editor, and full c++ support, this sounds too good to be open source true.


The only concern I have is that it will require some other languages as well. It seems to support c++, of which I am only a beginner, but used to. Yet it also uses GDScript as well, which is an open source scripting code they made just for this development SDK. Where I see that as a problem is it will probably only be useful inside of Godot.


Last up is Ogre. Ogre seems to be very actively developed at the moment. So active, that it appears to have created some sort of rift between the different versions. From what I can gather by doing a little research (just my opinion based on what I saw), there is the old version Ogre1, which you can use to make Android games, and the new version OgreNext, which only works in Windows and Linux for now, with hopes of adding Android later.

If you use Ogre1, it appears to be more of a library that you add, like libGDX, but if you use OgreNext, it seems to be a full fledged SDK. So, I’m not sure about how I would want to use it.

It also appears that Ogre1 and OgreNext do not work the same, so if I learn Ogre1 to build my Android games, will I need to relearn OgreNext so I can continue with that in the future? Perhaps that’s just my perception, but my perception being my reality, I don’t think I can put in double the effort to learn how to make 3D games.

Final result

I think I am going to give Godot a try. However, if it doesn’t work out, jMonkeyEngine is the runner up. Ogre seems to be undergoing some massive changes, and I’d like to work with something that is a bit more stable, but libGDX doesn’t seem to have all the “bells and whistles”, seeing that it is just a library to add to your current development.

I struggled this week between jMonkeyEngine and Godot, but in the end settled with Godot because the interface was so intuitive. I was able to walk through a few things in no time. Literally, within minutes and without any documentation, I loaded someone else’s project and was playing a game and editing code. I am also looking to expand my c++ skills rather than work on my Java. So, Godot it is, at least, for now….

Linux – keep it simple.

Android Remote Control through ADB

Today, I stumbled on perhaps the most ingenious use of ADB ever:

Remote control your Android phone through adb

A program and write-up by Marian Schedenig, that they shared on their website. This is perhaps the best adb tool I have ever seen, in that it takes three simple principles and puts them together to allow you to remote control your phone over ADB with your mouse, without ROOT permission!


Here is a small gif that I put together from a screen recording of me using this awesome java tool. Essentially, it uses adb to take screen shots of the phone. Then it downloads the screen shot and updates it’s display. Finally, when you click on the screen, it sends an x/y co-ordinate to the phone over adb to tell it you swiped or clicked! It is absolutely brilliant!

The updates are a little slow, and you do have to edit the config file for your specific needs, but it works great, and is a really useful tool if you broke your screen or have touch screen issues, or just need to display your screen for an audience to view while you press buttons or work with apps. Since it is written in java, it is cross platform as well!

Linux – keep it simple.

Interview With Frozen Bubble App Creator Pawel Fedorynski!

Frozen Bubble has been one of those fun staples of the Linux community for quite some time now, so when I realized that it was also available on Android, I had to pick it up! I can’t begin to tell you how many hours I’ve spent playing this game as a youth, but guess what? It’s just as playable now as it ever was, and now you can get in on the action on your Android device!

The game is fairly simple, according to Wikipedia:

Frozen Bubble’s protagonist is a penguin a la Tux, the mascot of Linux and popular feature in many free software/open source games. In this game Tux has to shoot coloured frozen bubbles to form groups of the same colour. Such groups disappear and the object is to clear the whole screen in this way before a bubble passes a line at the bottom.

While that captures the gist of the game, there are several elements to the game play that are not described there, like new bubbles being added while you play, and the way the point system works. While it is a simple game, it certainly is entertaining!

Several people have worked on this game over the years, and while I was not able to speak with all of them, I did get the pleasure of conducting an email interview with Pawel Fedorynski, who ported the game from Linux to Android.

Enough talk, here’s the Interview!

Mr. Fedorynski, I was just reliving my youth while playing Frozen Bubble on my Android phone! While considered a classic now, it has just as much playability as it ever did! You were not the original Frozen Bubble author, what pushed you to develop it on Android?

I got a G1 phone as a Christmas gift from my employer and wanted to develop something for it, Frozen Bubble port seemed like a good choice, especially since the phone had a trackball.

You also made an Android level editor, is that original with you, or ported from something else?

The editor was actually contributed by Rudolf Halmi, https://halmi.sk/.

How long have you been programming, and what is your favorite programming language?

I started in 1986 in BASIC on ZX Spectrum+ 🙂 My favorite language is C++, mostly because I know it best.

There are a lot of Android apps out there, and not all of them are open source, but I’m glad yours is. Why did you decide to release Frozen Bubble under an open source license? Was it a requirement of porting a game already established under that license?

It was indeed a requirement (the original Frozen Bubble is covered by GNU GPL.)

About how much time would you say you spent working on this game? And that time compared to playing it?

I think about half a year, one day a week. Non-trivial fraction of which was figuring out how to write a Hello World app for Android. Android was pretty new then.

How did you go about testing the game? Did you do all testing in house, or did you have a team of testers?

I don’t recall testing it very much 🙂 Since it was not an original game, but a port, the gameplay and the levels didn’t need any tuning. Once it started running I just uploaded it to the Android Market.

Do you feel that your work on Frozen Bubble is complete? Or do Android updates and user interaction keep pulling you back into working on this game?

The development was taken over by Eric Fortin, who added a lot of new features, including the arcade mode.

How about open source projects other than this one? Are you currently working on anything that you would like to share?

I had a bunch of other hobby projects, some of which I made open-source, but nothing of general interest that is available right now.

Thanks for taking the time to answer a few questions. Before we go, do you have any advice for someone who wants to get started in programming?

I guess one important thing is to choose projects that will keep your attention (as opposed to trying to do something useful or important.)

That is great advice for new programmers like myself!

More about Frozen Bubble and Pawel Fedorynski

If you are interested in playing Frozen Bubble on your Android device, it is available on F-Droid and the Google Play Store for download! You can also read more about the game from the Wikipedia article as well, but best of all, you can check out the official website: http://frozen-bubble.org/!

If you are looking for some entertainment, be sure to check out Mr. Fedorynski’s other game on the Play Store, the Busy Beaver! You can also jump over to the Frozen Bubble Github to check out the code and see what additions Eric Fortin has made to the game!

Linux – keep it simple.

Triple check that, will ya?

device-2017-03-08-124806A long long time ago
I can still remember how
That App used to make me smile….
And I knew if I had my chance
That I could make those dice dance
And maybe they’d be happy for a while….

Uh, wrong lyrics. Actually, it was quite a while ago that I made the Android app, Ships, Captain, and Crew! After the move from GitHub to GitLab, I decided to look over some of my old issues that were imported with GitLab’s great import tool. Among them, I found two issues for this old app that I had made.

The first was that of an issue with screen rotation causing the app to restart. I quickly fixed that by just setting the activity to portrait mode in the manifest file. You can check my commit if you need details.

The second issue was a bit more complicated, in that there was a problem with checking the dice for a ship, captain, or crew. Essentially, if you rolled a 4, 5, 6, 1, and 3, it would say you only have a ship (the 6) and no captain (5) or crew (4). Obviously that’s wrong. The issue is that you need a 6 before you can keep a 5 or 4. And since the dice were checked in order, when it looked at the 5 or 4, it did not have a 6 yet, so they were not “kept”.

This is how I fixed it:

for (int i = 0; i < 3; i++) {

// Check three times.

myNumber = firstDie;


if (waschecked){

firstnotchecked = false;



myNumber = secondDie;


if (waschecked){

secondnotchecked = false;



myNumber = thirdDie;


if (waschecked){

thirdnotchecked = false;



myNumber = fourthDie;


if (waschecked){

fourthnotchecked = false;



myNumber = fifthDie;


if (waschecked){

fifthnotchecked = false;




As you can see,  I told it to check the dice, first to last, three times. Yes, this is ugly and poor programming. Actually, I was almost ashamed of this early work, it looked so congested and terrible. However, my goal today was the quick fix, so that’s what I did. Hopefully, the update will be available on F-Droid soon, so you’ll have to check it out!

Linux – keep it simple.

Cancel all notifications!

While trying to update and add features to my old open source Hourglass app, I decided that the issue posted asking for a notification cancel button was a pretty good idea!

Screenshot from 2018-05-02 13-12-03

Now you can cancel your timer at any time from the notification bar! The code was pretty simple, actually, and you can read the entire commit on my GitLab, but here is the important part:

// as a result of notification action
Intent detailsIntent = new Intent(MainActivity.this, CancelActivity.class);
detailsIntent.putExtra("EXTRA_DETAILS_ID", 42);
PendingIntent detailsPendingIntent = PendingIntent.getActivity(

NotificationCompat.Builder builder = new NotificationCompat.Builder(context)
                android.R.drawable.ic_notification_clear_all, "Cancel", detailsPendingIntent);

Intent intent = new Intent(context, MainActivity.class);
PendingIntent pIntent = PendingIntent.getActivity(context, 0 , intent, PendingIntent.FLAG_UPDATE_CURRENT);

This mumbo jumbo just allows the cancel button to be displayed, which, if pressed, calls the CancelActivity class.

protected void onCreate(Bundle savedInstanceState) {

    // Set the screen orientation to portrait to keep the screen rotation bug from stoping
    // the timer on some phones.

    // Just log.
    Log.i("WJH", "CancellAll.");
    allCancel = true;


The moment the CancelActivity.java class opens, it set’s the boolean allCancel to true (meaning yes, we want to cancel) and exits back to the MainActivity class, where the timer is running.

Then, on every tick of the timer, it checks to see if allCancel is true or false. If true, it cancels the timer, repeating timer, and recurring alarm. If false, it continues to count down as usual. Praise God! It actually works! Be sure to check out revision 1.9 of the app for this latest feature! And thanks to “brunetton” for the great idea!

Linux – keep it simple.

Fool’s Mate Friday: Touching up the User Interface….


My uncle once told me that a good paint job will sell a bad airplane. He’s right. As an airplane mechanic, he knew the value of the planes that he worked on. At the same time, he saw customer after customer get “swindled” on a plane that looks nice on the outside.

The thing is, it’s true for apps and games as well. A really good program that doesn’t look good just isn’t as fun. Truth is, this engine app needed a little touch up in the gui department. So, while I didn’t make it pretty, I did add features to try to make it more useful.

Similar to the Beginning Chess Engine, I added a commit to allow the user to make a move by pressing the button. Simple stuff really, but up ’till now, I was doing all of my move making from the command line through the app code itself. Of course, if you can make a move, you need to be able to take it back to, so I added a commit to give the undo move method.

The flow of these move methods are pretty simple. For most moves, it checks the from space and the to space and puts an “*” (asterisk) at the from, and puts the piece that was there in the to space. The process is reversed for the undo move method.

There are a few exceptions, though, like the additional moves that are special, en passant, castle, and promotion. Those are handled by reading the input move first to see if it matches any of those scenarios, if not, then a regular move is performed.

Obviously, making moves in chess is a pretty important part of the game. The longest chess game theoretically possible is 5,949 moves, and that would be impossible to do if you couldn’t actually make any of those moves!

Linux – keep it simple.

Fool’s Mate Friday: Keeping the king safe!


The word “Checkmate” in Chess comes from the Persian phrase “Shah Mat,” which means “the King is dead.”

While in the starting position, there are eight different ways to checkmate in two moves and 355 different ways to checkmate in three moves. Not to mention the countless other ways to be checkmated. Kind of sounds like one of those television series of “1000 terrible ways to die.”

We’ve looked before at code for making the king move, but now we want to break down how we check if the king is safe. Here’s the kingSafe commit, and we can reference several things from that code as we try to understand what I set out to accomplish.

First, let’s take a look back at the flow chart for determining available moves:

  • For each piece, check for valid moves that they can make, where the spaces are empty, or where they attack an opponent’s piece.
  • Add that move to the temporary list.
  • Once we have a temporary list of valid moves, try each move, 1 at a time, and check if the king is safe.
  • If the king is safe, add that move to the “available moves” list.
  • Put the piece back, and try the other moves on the temporary list.

With that in mind, up until now, our engine has not actually checked if the king is safe. We had a isKingSafe() method that always returned true, or “yes, he is”. Now we need to flesh that out and have it really check if it is safe. For the most part, we can combine all the pieces move options into one for the king, and just ask what pieces are at the “end” of those move lines. Here’s the flow chart:

  • Start with the king’s space number, and get the row/column number as well.
  • Using the bishop’s move table, check the next diagonal space until it is not empty. If it is not empty, is it either a bishop or a queen? Then the king is not safe.
  • Using the rook’s move table, check the up/down/left/right spaces until they are not empty. If it is not empty, is it either a rook or a queen? Then the king is not safe.
  • Using the knight’s move table, check the eight “L” spaces to see if they are empty. If it is not empty, is it either a knight? Then the king is not safe.
  • Using the king’s move table, check the surrounding spaces until it is not empty. If it is not empty, is it a king? Or in two cases, a pawn? Then the king is not safe.
  • The king must be safe!

As you can see from the flow chart, it is checking to see if the king is “not safe”. At any juncture that the king is not safe, the rest of the checks are ignored, and a “false” boolean is returned from the isKingSafe0 method. If there are no returns of “false”, then the method returns “true”, for the king must be safe.

In my mind, there are three main ways to handle the king safe issue:

  1. After each piece is moved, have it flag that the king is unsafe (e.g., you check the king, so he is unsafe).
  2. After every move, check from all pieces to see if they are attacking the king.
  3. After every move, check from the king if he is threatened by any pieces.

Method one seems hard to implement, when moving you own piece may illegally threaten the king by no longer “blocking” an attacker. Conversely, method two is way more resource intensive. You would waste time checking both bishops in all directions to see if they “find” the king. Method three seems the most logical, check from the king in all directions for the enemy, rather than from all enemies for the king.

Of the method we chose, there seem to me to be two sub-methods, that of checking if the king is safe, or checking if the king is not. I like to assume the king is safe, unless we find that he is not. I think this is faster, because the moment we find he is not safe, then we quit checking. E.g., if the bishop check reveals the king is not safe, we don’t do the rook, king, knight, pawn checks, we just return “false” – not safe.

Conversely, if we were to assume the king is not safe, and prove he is, we would have to complete all of the checks every time. This would be a waste of resources. Although, with the method I chose, most of the time, the king is safe, so we end up checking them all anyways. But, since we are trying to use this engine on cell phones, we need to save on every resource that we can.

Linux – keep it simple.

Fool’s Mate Friday: Perilous times for pawns!


Did you know that the piece with the lowest survival rate is the white queen’s pawn at d2? That’s right, out of 2.2 million master level games, this pawn survives the least games at only 24.5%. Conversely, king not withstanding, the one piece with the highest survival rate of any of those games is the white king’s rook’s pawn at h2? It survives over 73% of games played! With such a wild spectrum, this small piece is actually the highest and lowest survivor of any chess game. You can check out all of the stats for piece survival here at Oliver’s blog.

Of special interest, Oliver also wrote a program to analyse all of the moves to find that information, which you can look at on GitHub.

Personally, I find the pawn to be the most important piece of the game. But that is for another time. For now, we need to make some pawn moves. Surprisingly, for such a simple piece, it has the most complicated moves:

  1. Pawns can move forward one space.
  2. Pawns can move forward two spaces from the “home” row.
  3. Pawns can attack diagonally forward.
  4. Pawns can perform en passant only under the right conditions.
  5. Pawns can promote to another piece.

I am sure that you realized those moves exist, but by seeing them put to paper we can really get the feel for how complicated making the pawn move is! Of all of those moves, 4 of the 5 are conditional, meaning they can only be done under certain conditions. This makes programming them tough, as you have to check if those conditions exist, then check if making the move is possible, then check if that move is safe for the king.

As you can see in my pawn commit, I added the pawn moves, but there are some flaws in them. Unfortunately, most of these flaws were not realized at the time, but were fixed later, here and here. Essentially, the move that was flawed is en passant, both in the making and the undoing of that move. However, I did not realize it at this point, until I started making the engine perform and undo moves.

So, take a look at the code, and feel free to comment if you think of a better way to do those moves.

Linux – keep it simple.

Fool’s Mate Friday: Keeping the King on the move!


When it comes to king moves, the most interesting is castling, for which I did manage to find a few statistics on the web, based on official games:

  1. White castles kings side 80.2% of the time.
  2. White castles queens side 8.8% of the time.
  3. White doesn’t castle at all…11% of the time.
  4. White castles queens side about twice as much as black.
  5. Castling kings side gives a higher statistic of draws.

From a tactical standpoint, they say that to castle opposite of your opponent creates a more tactical game, while to castle the same side as your opponent creates a positional game. Now I just need to go look up what that means….

In any event, we need to get a move on! Well, at least our king does. So, I created two commits: the king moves, and the king castle moves.

The king moves are really straight forward. I keep thinking that there must be an easier way to do this, but again, it’s just pure math. king position +/- 8 to go up/down a rank, +/- 1 to go side to side, and +/- 7 or +/- 9 to jog diagonally. The easy thing about the king is that he can only move one space… unless he castles.

Castling is rather tricky from a programming standpoint. There are several conditions which must be met:

  • The king cannot be in check.
  • No square the king moves to can be in check.
  • No square the king moves across can be in check.
  • There must be empty spaces between the king and the rook.
  • The king must never have moved.
  • The rook must never have moved.

As you can see, that maneuver alone takes 6 factors into account! Later, I ended up changing this a little bit, rather than booleans of true/false for king moved or rook moved, I went with numbers, but I’ll touch on that later. For now, I went with booleans.

The “king is safe” method has actually not been written yet, so it was interesting to check if the king is safe for this move, before having a way to check that, but in theory it works just fine, once I write the king is safe method. For now, I assign a number to the king’s position, and have it check if the king is safe by moving the number, rather than the actual king, on the logical board, and check if the king would be safe there.

It’s a little complicated, but I think it will do the trick. Be sure to check out the code!

Linux – keep it simple.

Fool’s Mate Friday: Quickly created Queens


Ah, the most powerful piece in the game. The queen. She can move in eight directions over great distances, she can outmaneuver any single piece on the board, she is used in more attacks and mates (statistically) than any other piece. Very valuable. So valuable, that she is worth 3 bishops, or 3 knights, or almost 2 rooks. In chess, that’s valuable.

However, my favorite queen story is that of sacrifice. A top notch player, Paul Morphy, once faced two opponents who collaborated against him in the Italian Opera House in Paris, Salle Le Peletier. His opponents were the Duke of Brunswick and Count Isouard. The story itself is quite fascinating, which you can read up on Wikipedia, or elsewhere, but the interesting thing to me, is how Mr. Morphy sacrificed his queen, despite already having a “material disadvantage”, in order to gain check mate!

Since that was before world chess championships, Mr. Morphy was never officially a reigning champion. However, he beat every opponent so soundly, that before he was 30, he gave up playing chess because no one was a challenge. If only I was that smart!

When it comes to programming our queen into our chess engine, though, we can be really smart! In fact, we can quickly create our queen in minutes, because all we are doing is making a piece that is both a rook and a bishop and combining them in the same method.

As you peruse the queen commit, I’d like to point out something. While we don’t have a full king is safe check yet, notice that we are trying to speed up the making of a list of available moves by first generating the list of possible moves, THEN checking to see if they are “king is safe” moves. If it is not a valid move, then there is no reason to check if it is a safe move in relation to our king.

One of the big goals of this engine is to be an open source alternative for Android app creators, and as such, it will need to run on cell phones, which typically have less processing power than a desktop computer. One of the reasons I started the Just Chess Engine, as opposed to the Beginners Chess Engine, is to get rid of all the try/catch blocks. In the Beginners Chess Engine, we often rely on a try/catch block to fail, so we can stop some part of the process. This leads to wasted processing and time. Here, we are trying to write simple, clean code that doesn’t need a (or at least reduces) try/catch block because it should not return an error.

Linux – keep it simple.