Ship, Captain, and Crew: Sounds Good…


Well, one of those things every game needs is sounds. Not just sound effects, but also background music. It’s a really easy way to enhance the game experience without actually changing any part of the game mechanics. The only problem was, I didn’t know how to do it in Godot.

So, after reading several tutorials, and reading Godot Engine’s how to’s and Q/A’s, I started out by adding some music to my game. At first, per the guides, I just added a new child node to my game launch menu that was an AudioSamplePlayer, and added the music to it. Unfortunately, this worked great in the launch menu scene, but as soon as you changed scenes, such as going to the game table scene, the music would abruptly stop.

So I read several more Q/A’s and guides. The problem is, if you put something in a scene, it ends when the scene does. What I needed was a scene that would be always loaded and was outside of the normal game. Per the guide, I then made a scene consisting of just the AudioSamplePlayer, chose music for it, and saved it as it’s own scene, called MusicPlayer.tscn. Then I went to the project settings and added it to the auto loader when the game starts.

But it didn’t work. In fact, the whole game crashed.

Turns out, since my automatic global scaling script changed all the root nodes children’s scales to meet the screen size, it would crash trying to pull the rectangle size of the MusicPlayer scene (since it doesn’t have one). That was a bit frustrating. But, it turned out to be a simple fix. I changed the MusicPlayer scene to have a Control Node as the root node, and gave it the same size as every other scene in the game, 1920×1080. Then it would allow me to set it’s size, and the game would continue. Seemed a bit hacky to me, but to God be the glory, it worked!

Then there was the question of the dice sounds, when the dice hit the table. Granted, later I’ll be going over the dice mechanics code in the game, but for now, it was simple to add to each dice:

func _on_AreaA6_body_entered(body):
if == “TableObject” :
diceA = 6
#print (diceA)

I simply added one audio node to the game table scene, called diceSoundPlayer, added my dice wave sound to it, and then started it with each collision between dice and table. It worked great!

Feel free to check out my project on my GitLab!

Linux – keep it simple.

Ship, Captain, and Crew: Scaling the Screen


So, now that I’ve completed BornCG’s great 3D game tutorial, I’m ready to set out on my own! Of course, I already mentioned what the game would be about, it is a remake of the classic “Ship, Captain, and Crew” dice game. I’ve already made a 2D version of this game as an Android app, but now I’m trying to develop some 3D skills by remaking the game using Godot’s 3D engine.

I have several goals for this game:

  1. 3D – I know, it seems kind of obvious, but I never made a 3D game on my own before! (No tutorial, help, etc.)
  2. Featuring all of my own 3D models – I want to personally build each 3D model to enhance my limited Low Poly Blender skills.
  3. Cross platform – I would like to be able to play this game on a Linux, Windows, and Android OS.
  4. Open Source – It is important to me that this project is open sourced to the public for any to view, edit, copy, and use. Perhaps my meager and fledgling skills will help some other newbie to create something better than I did.

So, with that in mind, my first goal was to tackle screen size. Once before, I made a 2D side scroller called Critical Velocity using the libGDX library, and I found out after I made the game that I needed to work out different screen sizes. It was really hard to do so after the fact, and so I wanted to start with that here, so I don’t run into the same problem.

I found several guides on how one might accomplish this in Godot. Some just moved the camera further or closer based on the size of the screen. Some used the stretch mode. Others scaled objects to meet the criteria. And yet others had different assets to use for various sizes. So, after viewing all three, here is what I came up with:

First, I made a script that is automatically loaded as soon as the game starts. It looks like this:

extends Node

var my_viewport_scale = 1
var actualScreenRatio = 1.777777
var numberOfPlayers = 1
var computerPlayer = 0

func _ready():
var viewport = get_node(“/root”).get_children()[1].get_viewport_rect().size
# comment the below call for OS.get_screen_size() if you want to force a
# certain screen size. If this call is not commented out, it will use the
# native screen size of the device or computer, unless it is greater than
# the Godot project settings of 1920*1080.
viewport = OS.get_screen_size()
# print(viewport) # Reference only

actualScreenRatio = viewport.x / viewport.y

my_viewport_scale = viewport.y/1080

So, in this script, I am asking the operating system for the size of the screen. I am building the entire game in a 1920×1080 resolution, but I use this math to find the screen ratio, and the screen size. I then set a scale based on the y axis ( my research seemed to point to that one being the best to base off of, but I don’t know particularly why ). Once these variables are in place, I can put this at the beginning of any “scene” that I make:

func _ready():
# My way to change the scale for every screen size. This allows me to build
# in 1920 x 1080 resolution, and scale it for bigger or smaller displays.
# This works for both 16:9 and 4:3 screen ratios, although 4:3 may not have
# the proper look.
# Tested satisfactory on: 800×480, 854×480, 800×600, 960×540, 1024×600, 1280×768, 1280×720, 1280×800, 1824×1200, 1920×1080
# Did not work well on 1400×900.

var new_y_scale = get_node(“/root/global”).my_viewport_scale
var new_x_scale = new_y_scale

if get_node(“/root/global”).actualScreenRatio < 1.4 :
new_x_scale = new_y_scale * ((800/600) / get_node(“/root/global”).actualScreenRatio)
elif get_node(“/root/global”).actualScreenRatio < 1.61 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.45)
elif get_node(“/root/global”).actualScreenRatio < 1.76 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.54)
else :
new_x_scale = new_y_scale

# print(get_node(“/root”).get_children()[1].get_scale()) # Reference only.

In the title screen scene, I use the “ready” function, which is called as soon as a scene launches, to set the scale of that scene/node. By doing this, everything in that scene is not directly scaled, but is automatically set to scale as the whole view is scaled. This saves me from scaling each object, but rather scaling the view as a whole. At least, as far as I understand it in my limited knowledge of Godot and 3D programming, and it seems to work well.

The key part being that I want to check the actual screens ratio. Once I have that actual ratio from the global script, I can edit the scenes scale to match (at least closely) the ratio of the screen, and scale appropriately. This allows the game to be viewed on a 4:3 ratio screen (like an older computer), and a 16:9 screen (like most phones and modern computers), and several odd phone screen sizes.

As you can see in my notes, I tested this out on various screen sizes, and it worked well on a lot of them. This does have one downside, as it will make some screen resolutions look “squished” a tiny bit. But, with my limited repository of Godot/3D knowledge, this will do for now.

Here is an example from a 3D scene, the game table:

func _ready():
var new_y_scale = get_node(“/root/global”).my_viewport_scale
var new_x_scale = new_y_scale
var new_z_scale = new_y_scale

if get_node(“/root/global”).actualScreenRatio < 1.4 :
new_x_scale = new_y_scale * ((800/600) / get_node(“/root/global”).actualScreenRatio)
elif get_node(“/root/global”).actualScreenRatio < 1.61 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.45)
elif get_node(“/root/global”).actualScreenRatio < 1.76 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.54)
else :
new_x_scale = new_y_scale

# And set the HUD scale…
# print(get_node(“/root”).get_children()[1].get_scale()) # Reference only.

Most looks the same, with the addition of scaling the “HUD” display. In the 3D scene, I over-layed a control node with essentially a 2D scene where the controls and such are floating above the game and within view for the player to use. Of course there is also another axis to change, the “z” axis, which is added in as well.

So, perhaps there is a better way to do this, but it seems to work pretty well for me. I also don’t notice any sort of performance hit doing this, as it only scales once at the scene change, and the scenes seem to load instantly. So I’ll stick with this for now. If you want to check out the project as a whole, you can find it on my GitLab.

Linux – keep it simple.

Collector3D! My First Ever 3D Game, Programmed in Godot!


Well, I finished the online YouTube tutorial by BornCG, which you can check out here. His tutorial is great and I learned a lot. I did make several changes along the way, and I used this as an opportunity to practice my work in Blender, making my own graphics for everything, as opposed to using the material he presented.

Code wise, it is the same game, but I did code several things differently, as I worked on expanding my knowledge of programming. An example would be the player ball rotation. In the tutorial, he shows how to use a variable and a set number to change the degrees to radii of the ball when it rotates.

However, This had several drawbacks. The first was that you needed to fiddle with it in relation to the variable of the ball’s speed. In other words, if you changed the speed of the ball, you would need to watch it move and guesstimate the change needed to the variable for rotation. Secondly, if you use his method, then when you stop pressing the arrow keys to move the ball, the ball stops rotating, but still “slides” until it comes to a stop.

To fix this, I changed the rendering of the ball rotation to be based off of vector speed. This makes the ball look very natural when it rolls. E.g., if it rolls forward, the degrees of roll looks naturally like the distance it is rolling over, and gives it a more realistic look. This also allows me to change the ball speed without having to adjust it’s degrees of roll. The best part, though, is when you release the arrow keys, and the ball is slowing to a stop, it now rolls, in accordance with it’s speed, slowing it’s roll as it slows to a halt in speed. It just look much more realistic.

I do believe that the author, BornCG knows how to do all this, and was just making a simpler tutorial for the viewers to follow. Or perhaps more specifically was trying to show the relationships of variables to those new to programming.

Other examples were just style points, adding timers and effects when you “die”, rather than the simple “cut to end screen” approach, and other such small things. Overall, the game mechanics and idea came from BornCG’s great tutorial. For a free resource that is widely available, I’d say this tutorial was a 5 star product, and I highly recommend it for anyone looking to start using Godot. I found numerous 2D tutorials for Godot on YouTube, but this is one of the very few 3D tutorials for Godot. Certainly worthy of your time if you are looking to start using Godot.

That said, here are some great links for my game:

* Notes: I did not try the Windows executable, since I didn’t have a Windows machine to test it on. I did try out the Linux executable on two different Ubuntu machines (17 and 18). If you try the Linux executable, be sure to chmod a+x the file so you can run it. Also, if you try out any of the executable files, be sure to comment below how well they worked and what OS you tried them on!

Linux – keep it simple.

Is it “Go-Dot” or “Guh-Doe”?


Since I decided to go with Godot, I’ve really, really been enjoying the experience. Of course it is a tremendous help to learn how to use it while making a game and following a great tutorial by BornCG on YouTube. This guy is a really great teacher! So if you are looking to learn how to use Godot, be sure to check his tutorials out! By the way, according to BornCG, it’s pronounced “Guh-Doe”.


This is a slight detour from my intended project, but I like to have a successful path forward where I start using a new tool or programming language by using some sort of guide or tutorial. I find it helpful in making sure my environment is set up properly, especially if I get the same results as the instructor. So far, his tutorial is a pac-man/sonic like game where your sphere picks up coins and avoids enemies. I’ll try to include my final result when I get done!

So far, we have not used any native code, which you can program in yourself, using c++ or other languages. We’ve only been using GDScript thus far, which is an open source Python like language that is pretty simple to grasp. I look forward to seeing how we implement that, but either way, I’m certainly having fun!

Linux – keep it simple.

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.

Dice, anyone?


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.

Tesla: Star Wars or Tron?


At work the other day, I got the opportunity to teach a class on inductance and resonance in relation to electronic circuits. So of course, I thought a tesla coil would be the most fun visual instrument to instruct with.


Of course, the inexpensive kit I bought off of Amazon came with a small slayer-exciter circuit, which is a little different than the traditional tesla coil circuit, since it finds it’s own resonating frequency, but it was still impressive to watch. We even burnt a few scraps of paper and then used the spark as a plasma speaker, which was pretty fun too.

We also had a few florescent light bulbs around, both straight and round. So the question became: Star Wars light-saber duels, or Tron disc wars?

Linux – keep it simple.

Convert Still Photos to a GIF or Video


Really just a technical note for myself. I thought I had written this down somewhere here, but I couldn’t find it, so, here it is.

Converting png to a video in Linux:

ffmpeg -framerate 24 -pattern_type glob -i ‘*.png’ -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4

Setting the framerate sets the speed of the video. You can replace png with jpeg or jpg if needed. This does, of course, require the ffmpeg utility/package.

And, converting png to a GIF in Linux:

convert -delay 10 -loop 0 *.png myimage10.gif

The delay sets the milliseconds of delay between frame, so lower makes a faster video, higher makes a slower video. 8 to 10 seems about right for something that should look “real time”. This requires the imagemagick package.

Linux – keep it simple.

Low Poly Course: A walk in the park?


While deeply investing my time in the study of servers for the upcoming Server+ beta test, I took a few hours to relax and made this fun low poly man walking in the park. If you are interested, you can see the video I made of it here:

This concluded the Low Poly course, and I really, really loved it. I can’t wait to try out some more fun stuff with my new low poly renders!

Linux – keep it simple.

QFIL Sahara Errors


It sounds like some kind of desert problem, but QFIL is actually a tool that you can use to flash firmware on Qualcomm devices. I’ve made a YouTube video about using it as well as writing about it here on this site in the past. It’s a really simple tool to use, but it never ceases to amaze me at how much trouble it gives me every time I try to use it.

This time, I was trying to fix a BLU LifeXL and get it flashed back to stock. Unfortunately, after downloading the latest QFIL, it failed every time I tried to flash the firmware, telling me that “sahara” had failed:

ERROR: function: sahara_main:924 Sahara protocol error

Well, after spending a while fiddling with it, and searching the web, I found XDA post after post with people doing different things and solving their issues. Some had to unlock the bootloader, some had to get into download mode a different way, etc. But none of those helped me.

In the end, the real issue was that I needed to use an older version of QFIL. I started with version 2.7, but I finally got it to work by using version 2.0. So perhaps if you have a sahara error, you might check to see what version of QFIL you are using. I *think* that the old phone firmware was written back around QFIL version 2.0, and just wouldn’t work with the newer versions. But that’s the best I can figure of why it doesn’t work with the newer versions. It seems odd to me that you would need to know the specific version of QFIL needed for the specific phone firmware you have, but it seems to be the case.

Linux – keep it simple.