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.

Critical Velocity – an open source libGDX game that was crashing on small screens is now fixed!

Critical Velocity is a fun little open source arcade style scrolling game that I made after finishing my Android developer class. It was my first released game using the libGDX engine, an open source graphics engine that is great for making games. Due to my inexperience, however, I didn’t take into account that all screens are not created equal. Some screens are bigger than others, and some have lower resolution than the phone I built the game on.

This caused a problem. After releasing the game, I quickly was alerted to the issue through the GitHub issue tracker, where several players let me know that it was crashing on startup with their phones. It took a little bit of time to figure out, but I came to realize that the app was crashing on phones that were smaller than 800×480 screen resolution.

At first I thought there were all sorts of problems with graphic asset sizes, and memory issues. I tried numerous things to fix it, but nothing worked. Finally, I gave up. But, a few days ago, I decided to take another look. By God’s grace, this time I got it figured out! Before, I was working off of the information provided by people with smaller resolution screens, but I decided that I should load up the game in an emulator with a 320×240 resolution screen, and watch the logs. That’s when I found the problem.

The issue didn’t have anything to do with libGDX, the graphic assets, or the amount of memory the game takes (about 15 MB). As it turns out, the math just didn’t add up. Literally!

In the game, the upper and lower walls are separated by a gap. The size of the screen and the size of the gap is used to determine where the next set of walls opening can be (up or down) from the previous wall. The idea was that as you went faster, an opening at the top of the screen followed by an opening at the bottom of the screen is technically impossible to reach, so this math would keep it “near” the other opening within reason, but still allow it to be randomly placed, up or down from the previous one.

The math looked like this:

Place of the next wall opening = randomly based off of (1/2 of the screen height – the size of the gap) from the center of the screen.

This worked great on my test phone that had a screen resolution of 1920×1080. With the standard gap that I set of 450, the math looked like this:

Place of the next wall opening = randomly based off of (960 – 450 = 510) from the center of the screen.

But it didn’t work for a screen as small as 320×240 because:

Place of the next wall opening = randomly based off of (160 – 450 = -290) from the center of the screen.

For a random number, you can have a negative outcome, but you cannot put in a negative input. The random number is based on starting at 0, and create UP TO X random numbers. So if X is negative, then the random number generator doesn’t know what to do!

So I had to invent a way to fix this problem. Fortunately, that was easy. I used an if/then statement to ask what the screen size was, and then changed the gap size to be less than 1/2 of the screen size. I also had to edit a few parameters, such as thrust, speed, and distance also based on screen size. You can check out my code and commits here and here, if you’d like.

Long story short: Don’t make assumptions, check the logs and they WILL lead right to the problem! If I had run the emulator myself before, not having a small screen phone anymore, I hopefully would have seen this right away. Here are some screen shots of the game on different phones. Unfortunately, I still have a lot to learn to make sure that the game LOOKS the same on different sized screens, but at least now it doesn’t crash!

Linux – keep it simple.

What is the difference between isTouched and justTouched?

Fortunately, it did not take long to figure this out, but as a beginning java programmer using libGDX, I couldn’t quite figure out the difference between isTouched and justTouched right off the bat. A Google search actually told me the answer, but at the time I did not understand what that answer meant, or when you might use them.

So, to dumb it down for simple folks like me:

  • justTouched – When used in a render method, it will only count the first time you touch the screen, like a “touch down”, but does not render “holding down” the screen. It also does not care about “touch up” or releasing the screen. You might use this to tap an object that you want to register the tap, but do not want it to continue registering that you are holding it. This could be useful to pop a balloon in a game, tap a button, click on something, etc.
  • isTouched – When used in a render method, it will continuously count that you are touching the screen until you let go. This allows you to “hold down” on the screen. Some examples that I could think of for use might be drawing with a paintbrush, turning a page, a button that must be held down, pushing a rock uphill, etc.

Both of these tools have their places, and I could see reasons to implement one or the other depending on your needs. Hopefully that helps someone else out there.

Linux – keep it simple.

How to “touch” objects in libGDX

There are actually many ways that one can “touch” an object in libGDX. You can create scenes with stages and characters and actors, for one. You could do sprite comparisons as another. I decided to go a simple route with intersections.

The goal is to be able to detect that the user has tapped on or touched an object that is displayed on the screen. This is really handy, as it will allow you to manipulate objects to move them, pop balloons, draw pictures, press switches, and more. Pretty much all the usual things that you do in a game. And this is just my rendition of how to do that.

Obviously, the nature of the game would determine if this was a useful method or not. Depending on what you are trying to accomplish, this may or may not be useful. You can check out the whole open source for the project on my GitHub.

So, I first needed some objects to touch, and an object for where I touched under the class:

Circle centerCircle, leftCircle, rightCircle, myTouch;

Then I declared those circles under the onCreate method:

centerCircle = new Circle();
leftCircle = new Circle();
rightCircle = new Circle();
myTouch = new Circle();

Finally, I used shaperenderer to draw them under the render method:

shapeRenderer.begin(ShapeRenderer.ShapeType.Filled); // For visualizing collision shapes.

if (colorChanger == 0) {
shapeRenderer.setColor(Color.BLUE); // For visualizing collision shapes.
} else if (colorChanger == 1) {
shapeRenderer.setColor(Color.RED); // For visualizing collision shapes.
} else {
shapeRenderer.setColor(Color.GREEN); // For visualizing collision shapes.
} // Cool color changing affect, so you know you touched a circle.

 

leftCircle.set(Gdx.graphics.getWidth()*2/3,
Gdx.graphics.getHeight()*2/3,
100); // Set the circle.

centerCircle.set(Gdx.graphics.getWidth()/2,
Gdx.graphics.getHeight()/2,
100); // Set the circle.

rightCircle.set(Gdx.graphics.getWidth()*1/3,
Gdx.graphics.getHeight()*1/3,
100); // Set the circle.

shapeRenderer.circle(centerCircle.x,centerCircle.y,centerCircle.radius); // For visualizing collision shapes.
shapeRenderer.circle(rightCircle.x,rightCircle.y,rightCircle.radius); // For visualizing collision shapes.
shapeRenderer.circle(leftCircle.x,leftCircle.y,leftCircle.radius); // For visualizing collision shapes.

shapeRenderer.setColor(Color.BLACK); // For visualizing touch shapes.
shapeRenderer.circle(myTouch.x, myTouch.y, myTouch.radius); // for visualizing touches.

shapeRenderer.end(); // For visualizing collision shapes.

You can look at the full source code in the link above if that makes it clearer, but the key thing to focus on here is that I now have 4 circles drawn on the screen. The “myTouch” circle is always black, and the three other circles are chosen by the variable “colorChanger”. This was added as a nice “touch” so you could see them change color when clicked. (Bad pun intended.)

So, how do we register the touches? Like so, also under render:

if (Gdx.input.isTouched()) {

/*
* Here is the interesting part. This should be:
* myTouch.set(Gdx.input.getX(), Gdx.input.getY(), 10);
* But then our touches turn out correct for X, but backwards for Y.
* Try it both ways to see the difference.
*
* Note that this is in portrait mode. It may not be that way in landscape mode.
*/
myTouch.set(Gdx.input.getX(), Gdx.graphics.getHeight() – Gdx.input.getY(), 10);

Gdx.app.log(“WJH touchpoint”, String.valueOf(myTouch)); // Write down for logging/testing.

// Did we have an overlap of the “myTouch” and a circle?
if (Intersector.overlaps(myTouch, centerCircle) ||
Intersector.overlaps(myTouch, rightCircle) ||
Intersector.overlaps(myTouch, leftCircle)) {

if (colorChanger < 2) {
colorChanger++;
} else {
colorChanger = 0;
} // If we have an overlap, then change the color.
}

} else {

myTouch.set(0, 0, 0); // If not touched, let’s move it out of the way.

} // End input detection.

According to this, if you are touching the screen, it will take input from your x/y coordinates. If you are not touching the screen, the size and position of your “myTouch” circle becomes 0.

When you are touching the screen, the myTouch circle is compared to the other circles for an overlapping condition. If they do overlap, the colorChanger is changed, so that the color of the circles can change.

If you download the apk and give it a try, you will see that you can drag a little black dot around the screen, and when you “bump” into or “cross over” the three large circles, they will change color. Pretty spiffy, huh?

Linux – keep it simple.

libGDX music and sound fail….

While finishing my Android app developer course, I ran into this error during game development:

[CODE]

——— beginning of crash
06-09 13:01:19.410 30345-30366/? E/AndroidRuntime: FATAL EXCEPTION: GLThread 758
Process: com.alaskalinuxuser.criticalvelocity, PID: 30345
com.badlogic.gdx.utils.GdxRuntimeException: Error loading audio file: data/spblk.mp3
Note: Internal audio files must be placed in the assets directory.
at com.badlogic.gdx.backends.android.AndroidAudio.newMusic(AndroidAudio.java:120)
at com.alaskalinuxuser.criticalvelocity.criticalvelocity.create(criticalvelocity.java:55)
at com.badlogic.gdx.backends.android.AndroidGraphics.onSurfaceChanged(AndroidGraphics.java:275)
at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1532)
at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1259)
Caused by: java.io.FileNotFoundException: data/spblk.mp3
at android.content.res.AssetManager.openAssetFd(Native Method)
at android.content.res.AssetManager.openFd(AssetManager.java:363)
at com.badlogic.gdx.backends.android.AndroidFileHandle.getAssetFileDescriptor(AndroidFileHandle.java:237)
at com.badlogic.gdx.backends.android.AndroidAudio.newMusic(AndroidAudio.java:110)
at com.alaskalinuxuser.criticalvelocity.criticalvelocity.create(criticalvelocity.java:55)
at com.badlogic.gdx.backends.android.AndroidGraphics.onSurfaceChanged(AndroidGraphics.java:275)
at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1532)
at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1259)

[/CODE]

It took a long time to figure out the issue, so I thought I would try to save someone else the trouble.

It hinges on this line from the libGDX wiki example:

Music music = Gdx.audio.newMusic(Gdx.files.internal(“data/mymusic.mp3”));

Which my line looked like this:

bgMusic = Gdx.audio.newMusic(Gdx.files.internal(“data/spblk.mp3”));

Should work right? But it didn’t. I had to change my line to this to make it work:

bgMusic = Gdx.audio.newMusic(Gdx.files.internal(“spblk.mp3”));

And put the mp3 file in the “assets” folder.

Hopefully, this will save someone else a really long, frustrating search!

Linux – keep it simple.

Setting up libGDX for Android Studio on Ubuntu

Every one else is probably brighter than me. However, after reading the instructions over and over again, and then attempting to follow them, it just wasn’t working. All I wanted to do was start a libGDX project in Android Studio. I finally figured out where I went wrong, so here is the step by step for any one else that gets stuck like I did. Please read all the instructions first, because step 5 becomes step 1, but doesn’t make sense unless you read them in this order:

  1. Go to https://libgdx.badlogicgames.com/download.html and click “Download Setup App”.
  2. A jar is downloaded. Don’t try to import it, or something of that nature. Clicking on it is no good either. Simply open a terminal window and cd to the Downloads directory. Once you are there, type: $ java -jar ./gdx-setup.jar
  3. A window will pop up. Fill in the usual blanks to name your app.
  4. For the Android SDK field, open Android Studio, and click File –> Project Structure. That first field is the Android SDK.
  5. For the folder to put the newly created app in, be sure that you choose a folder that is empty, because it will wipe out everything in that folder. So I recommend you make a folder for it first!
  6. Uncheck the things you don’t need, like IOS, HTML, etc, and click generate.
  7. Once it is done, go back to Android Studio, and click File –> open.
  8. Choose the folder you put it in, and Android Studio will recognize the gradle files in it, and open your new app!

Hopefully that makes sense and keeps you from wasting as much time as I did. Most of you are probabl smart enough to know this already!

Linux – keep it simple.