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.

libGDX

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.

libGDX

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.

jMonkeyEngine

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.

jMonkeyEngine

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.

Godot

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.

Godot

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.

Ogre

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.

Dice, anyone?

LowPolyDice

Now that I’ve completed the low poly course from Udemy, I’m ready to start using my fledgling, but newfound skills in some form of application. That said, the most fun and easiest way that I can imagine using 3D models is in some kind of game. The question is, what to make?

If you’ve been reading this blog for a while, you may remember that I once made a dice game app called “Ship, Captain, and Crew”, based on the sailor dice game of the same name. So, I’ve decided to revamp that project by creating a 3D version of the app. Essentially, I’ll be starting from scratch, but utilizing the same game mechanics that are in the first game.

The two big things I think I will need are the 3D objects and then some form of 3D game engine to render it. Today I completed the first part, which was making the dice. It took me about an hour to throw this together, but I think it will do as a low-poly die for the game. In theory, I will just use 5 of them during the game itself.

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 4 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 four main options of LibGDX, GoDot, Ogre, and jMonkeyEngine. There may be others, these are just the ones I know about.

So, now I need to do some research and see which one will work best for me. I’ve never made a 3D game before, so this might take a while….

Linux – keep it simple.

Finished, picoEngine?

picoEngineComplet

Today I released version 1.0 of picoEngine.

That’s right! My UCI compatible chess engine is now released as picoEngine version 1.0! You can view the tag on my GitLab. Now you too can download and compile picoEngine for yourself! It comes with a generic 64 bit version that I tested on Ubuntu 18.04 with both Arena and PyChess interfaces. Here’s the information on this release:

Version 1.0

Features:

  • UCI compatible engine!
  • Accepts both FEN and MovePos standard inputs.
  • Up to 8 ply weighted moves.
  • Has an optional random move mode for easy chess players.
  • Fast, even at 8 ply only takes a second on a modern 64 bit machine.
  • Light weight, it only takes 2 MB of ram to run this engine.
  • Small size, the (Linux 64 bit) compiled engine is only 364.2 KB in size.
  • Small source code, the entire source repository is less than 1.3 MB in size.
  • Can output moves and engine evaluation (only displayed by interfaces that support it).

I hope you enjoy it! If the prebuilt doesn’t work, just review the read me for simple compiling instructions, involving just one command. (I like to keep things simple.)

Linux – keep it simple.

picoEngine, in passing?

One of the key things that any chess engine needs to be able to do, is take the input from the calling program with regards to en passant. With a little algebra, it wasn’t too hard to set up:

enpassworked

Fortunately, it was pretty easy to add the ability for the engine to check if the move was an en passant move, but it relied on two parts, both of which you can check out in the commit on my GitLab.

The first part was to make a flag that en passant was enabled, because the enemy pawn moved two squares. The second part was to calculate if the conditions were met on the next move to be an en passant move or not. If so, it then needed to adjust it’s own board and remove the “extra” pawn that was left behind!

Sounds simple enough! Guess you’ll have to be the judge of that by looking at the commit though.

Linux – keep it simple.

picoEngine Meets FEN

print

One of the more interesting parts to programming chess engines, is using the UCI, Universal Chess Interface. In that interface standard are very specific settings. One of those is that engines should accept input as either move by move, or through FEN.

The FEN part was actually quite easy. Just breaking down characters of the line and figuring out what goes where. The toughest part was understanding vectors so I could do what I wanted to do. Here’s a glimps of the code:

vector<string> split(string str, char delimiter) {
vector<string> internal;
stringstream ss(str); // Turn the string into a stream.
string tok;

while(getline(ss, tok, delimiter)) {
internal.push_back(tok);
}

return internal;
}
………………………………………..Edited for space…………………………………
void inputPosition(string posString)
{
vector<string> sepVect = split(posString, ‘ ‘);
string str1 = sepVect[1];
if (sepVect[1] == “fen”)
{
// FEN board setup.
string stringBoard = “”;
string str2 = sepVect[2];
for (int i = 0; (unsigned)i < str2.length(); i++) {
char myChar = str2.at(i);
if (isdigit(myChar))
{ int imyChar = myChar – ‘0’;
for (int a = 0; a < imyChar; a++)
{ stringBoard = stringBoard + “-“; }
}
else if (isalpha(myChar))
{ stringBoard = stringBoard + myChar; }
} // end for.
int j = stringBoard.length();
for (int i = 0; i < j; i++) {
if (i < 64){ theBoard[i] = stringBoard.at(i); }
}
if (sepVect[3].at(0) == ‘w’)
{ whitesTurn = true; } else { whitesTurn = false; }
if (sepVect[4].at(0) == ‘K’)
{ Kcastle = true; } else { Kcastle = false; }
if (sepVect[4].at(1) == ‘Q’)
{ Qcastle = true; } else { Qcastle = false; }
if (sepVect[4].at(2) == ‘k’)
{ kcastle = true; } else { kcastle = false; }
if (sepVect[4].at(3) == ‘q’)
{ qcastle = true; } else { qcastle = false; }
if (sepVect[5].at(0) == ‘-‘)
{ enPassant = false;} else { enPassant = true;}
moveSince = stoi (sepVect[6]);
turnCount = stoi (sepVect[7]);
} // End FEN

I just broke down the string into vectors separated by spaces. Then in each vector, I figured out where the piece needed to go, or how many blank spaces I needed.

Now I still have to work out a few oddities, but I think this should work fairly well, and seems to have in the few test runs I’ve given it. You can check out the whole commit on my GitLab if you’d like!

Linux – keep it simple.

Blindfold Chess, Mr. picoEngine?

While building the picoEngine in C++, I will often be wondering what the engine is thinking. One of the problems is that I can not “see” the engine’s board, so I don’t know why it would make a particular move. So, I added a print function. This also is in keeping with my “engine mentor” Logic Crazy, who often used this technique so he could evaluate the board position.

The code is rather straight forward:

string printBoard = “”;

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

printBoard = printBoard + theBoard[i];

}

cout << printBoard << ” ” << whitesTurn << ” ” << Kcastle

<< ” ” << Qcastle << ” ” << kcastle << ” ” << qcastle

<< ” ” << moveSince << ” ” << turnCount << endl;

Not only did it work, but it seems to be rather helpful. Now, as I work on inserting positions via FEN and the startpos moves system that is defined in the UCI, it makes checking my work easy. Here is a screen shot of it in action:

print_picoEngine

Linux – keep it simple.

Fool’s Mate Friday: Keeping the king safe!

bk

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.

Added the ability to castle to the Beginner Chess Engine

For better or worse, I added the ability to castle to the Beginner Chess Engine.

device-2017-10-04-111213

In theory, that would always be better. However, adding this feature actually caused two problems:

Problem #1 – Even though the castle works great, as expected, and is successful, occasionally, on the NEXT move of the side that castled, then the rook can turn into a king.

Problem #2 – The king cannot castle in check, nor to check, but can currently castle across check, which is an illegal move.

Hmm…. back to the drawing board I guess. You can check out what I did by looking at the commits.

Linux – keep it simple.

Added a display for the list of possible moves to the Beginner Chess Engine

Well, if you were wondering what I was doing with my spare time, this is it!

possibleMoves

I just added a TextView to display the move options that the computer had available. Not real fancy, but it allows me to “watch” what’s going on without the debugger running. You can check out the commit here:

https://github.com/alaskalinuxuser/BeginnerChessEngine/commit/c81721cc0d6e8d301e4924d4d2f0de233c06b744

Linux – keep it simple.

Added reset button to the Beginning Chess Engine app, but it doesn’t do what you think….

As you can see, I added a reset button to the app for the Beginning Chess Engine.

added_reset

Originally, I had intended to have the board simply reset back to the starting position. However, for some odd reason, when I would reset the board pieces, odd things would happen….

Like a rook would randomly turn into a king when you move the knight.

So, I decided to have the app close, and then call itself to be opened again a few milliseconds later. It’s a little odd, since the app “closes” and then “opens” again, so it looks like it crashed, only to pop up again.

If this were my chess playing app, I would need to focus in on that a little more, however, I am trying to focus on the engine itself, not the remnants that are somehow misconstrued during recreating the original board.

Here’s the commit:

https://github.com/alaskalinuxuser/BeginnerChessEngine/commit/3f6aae2c2e5327d341e15cb50c9d702dc4356fd7

And one issue closed! Only 9+ more to go!

Linux – keep it simple.