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.

Google Apps on the SODP AOSP for the XA2 Ultra?

As you know, I’ve gone Google App-less, or “gappless”. But, for better or worse, not all of my ROM users have done the same. Typically, when you build a custom ROM, you build it without things like ROOT or GAPPS, and leave it to the ROM user to decide what they would like to install. In the case of installing GAPPS, they typically use TWRP to flash an opengapps zip file that installs all the desired Google Apps.

This is useful, because there are lots of Google Apps, and users may want some of them, but not all of them. Thus, when you install your zip from opengapps, you choose how many Google Apps you would like, pico, nano, mini, stock, full, etc., the bigger the tag, the more Google Apps you get.

Unfortunately, my SODP based AOSP ROM has an issue with Gapps. As I said, I don’t use Gapps anymore, but my users reported that they could not install Gapps. So I tried installing it myself to see what the issue was. Sure enough, it would install properly, but when you booted into the phone, the Gapps were not there! It was as if they never installed. I’d like to take credit for the Gapps resistant ROM, but it was purely unintentional.

So, this may seem counter productive, but I’ve release a build with built in Gapps as well. Since the end user can’t install it themselves, you can actually follow opengapps guide to build your ROM with Gapps included in the build. While I don’t like using Gapps anymore, I certainly want others to have the freedom to do so. The only difficult thing was figuring out which level of Gapps to include. In the end I decided with “stock”, which is less that full or all, and more than pico, nano, and mini. I figure that if you want Gapps, you probably want the standard, or stock amount of programs.

The only downside, is it makes my build almost three times the size! Believe me, it took three times longer to upload too! I think next go around, I’ll probably use mini for the Gapps level, to save myself some uploading bandwidth. I of course, still release my own builds without Gapps, for those so inclined.

Linux – keep it simple.

Sony Open Device Project and the Xperia XA2 Ultra….

Now that I’ve built a few ROMs for the XA2 Ultra (AOKP and Resurrection Remix), I’ve turned my attention to the Sony Open Devices Project. The SODP, as it is abbreviated, is an effort to make custom ROMs for various Sony devices that are as open source as possible. This includes reducing the amount of vendor blobs (binary large objects) by replacing them with open source code wherever possible.

While the phones in this program are not 100% vendor blob free, they are dramatically reduced and continue progressing as time goes on and developers continue their work. It’s a great idea with several volunteer and professional staff members (courtesy of Sony), and I am all for it. Here is their statement from their web page linked above:

For some of the Xperia™ devices, we provide Android™ Open Source Project (AOSP) device configurations on GitHub. This means that the software will be open for you as a developer to use and contribute to. This is a way for us to support the open Android community, and it is also a tool for us to facilitate and verify contributions to AOSP.

That said, I’ve started progressing in that direction. I’m not skilled enough to do the helpful work of breaking down blobs and coding an open source alternative, but I’m jumping in by using their material as a base for my ROMs that I build.

One of the greatest advantages I see in using this material is the newer kernels. The XA2 Ultra comes with kernel version 4.4. However, the SODP includes kernels 4.9 and 4.14! Using a newer kernel brings better performance and enhanced security, which is always a plus!

It will be interesting to see what comes of this, how functional the ROMs are, and where I can go from here….

Linux – Keep it simple.

First low resolution sample printed case for my LTE project!

Yesterday I printed up a low resolution (meaning less fill) plastic case for my LTE project. It is really low quality and not very structurally sound. I needed a quick print so that I could look at the design, hold it in my hands, and decide what needed changed.

Overall, I like it.

But, there is room for improvements. The Arduino and LTE shield are in a great spot with easy access to the USB/power plugs, which is great. But, the Nokia screen is larger than the hole I made for it to slip through, so I need to adjust that. Also, my screw holes are twice the size that I thought they would be, so I need to shrink those down. Also, the button holes, for the six functional buttons and one switch are a little too small, making them difficult to use.

lteproject1

I’ve been using FreeCad to build the case, and either my knowledge of 3D modeling is so low, or this program is really tough to use, but this is very difficult. I’ve actually taken more time on building the case (not designing, but actually building) than any other part of the project thus far. If you know of easier to use programs, please let me know in the comments.

The case will be rather large, about 7 x 4 x 1.5 inches. Seems a little overkill, but I need to fit the battery, the Arduino, the LTE shield, the Nokia screen, and the buttons all in there. I went with the raised sides to protect the buttons, so they wouldn’t get slammed or pushed when not in use. We’ll see how well that works.

Linux – keep it simple.

AsteroidOS on my LG Urbane

I took a little break from my main project to try out AsteroidOS on my LG Watch Urbane (Bass). I have to admit, I really like it. If you don’t know, AsteroidOS is the free and open source alternative to Google’s Android Wear operating system.

Don’t get me wrong, Google’s Android Wear is a great product. However, I don’t like how you cannot build your own custom ROMs from it, like you can with Android itself. You can also only access your Google Wear watch with Google’s apps installed, which is somewhat lame.

One thing that Android Wear still has a leg up on over AsteroidOS is that AW has many, many more apps. What I came to realize after using AsteroidOS for a week was that I didn’t miss one of them. Actually, the only thing I really use my smart watch for is, well, as a watch that notifies me that I have a text or phone call. Since the notification pops up on the watch face, I can determine if it is important enough to pull my phone out of my pocket or not.

Hopefully that doesn’t give you the impression that AsteroidOS is not a full feature wearable operating system, though, because that would be wrong. By default it comes with a calendar, calculator, timers, stop watch, weather app and more. There are also several other apps that you can get for it, built by a growing open source community. I guess what I’m trying to point out, though, is that I love the simplicity of it.

Screenshot_20190517-060054

AsteroidOS also comes with it’s own controller app, like Android Wear, but it’s open sourced, so you can have a look for yourself to see what’s going on under the hood. Or if you are really talented, you can edit it and modify it for your own needs.

It has a really great way for controlling notifications, but I did notice that you have to wait until you receive a notification from an app or the system to be able to edit the settings of that notification. By default it doesn’t know what apps you have installed, so it doesn’t list them until they actually post a notification. The first notification will show up on your watch, and then you can go into the app and decide the fate of future popups from that app, service, or function.

Just like Android Wear, AsteroidOS has a ton of watch faces made by users, or you can make your own with their SDK. The background of the watch face can also be changed, and there are numerous other options as well. It’s simple, but in a sleek sort of way.

There is one thing I don’t like, though. There is no selectable “always on” setting. You can enable it via usb, through an ssh connection to the watch. However, with this enabled, the watch will never sleep, and battery life suffered horribly, so I don’t recommend it.

However, with the default time delay mode, the watch face stays off until you swipe the screen or push the watch button, and I found battery life to be twice what it was when using Android Wear. So that is a big win for me. Before AsteroidOS, I often barely made it through the day, putting the watch back on the charger at single digit percentages. Now, with AsteroidOS, I find that I’m putting the watch back in the cradle with around 50% battery life left!

Oh, and one more thing: no more wasted data! With Android Wear, my phone was always “searching for WearOS updates”. This search burned several gigs of data per month! Fortunately, AsteroidOS doesn’t waste my data at all, with the exception of periodic weather updates, which seems to happen fairly infrequently when you are not looking at it.

Overall, I’m hooked.

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.

Shaken or Stirred, picoEngine?

Well, more like Random or Normal, actually. I’m off to a bit of a slow start, but I am making progress on the picoEngine.

picoEngine_2

Here you can see picoEngine’s “many” options…..

First on my list was to give picoEngine an option for the GUI users to select from. Right now, the only option it has is to be completely random about moves, or to play as normal. Okay, technically it can’t play at all at the moment, but if it were to play, these are the two “styles” or play modes.

2018-09-13 12:50:37.472<–1:– engine[slotnr].EngineProcess.Running —
2018-09-13 12:50:37.475<–1:Waiting….
2018-09-13 12:50:37.489–>1:uci
2018-09-13 12:50:37.489<–1:id name picoEngine A01
2018-09-13 12:50:37.490<–1:id author Alaskalinuxuser
2018-09-13 12:50:37.490<–1:Apache 2.0 License.
2018-09-13 12:50:37.491<–1:https://thealaskalinuxuser.wordpress.com
2018-09-13 12:50:37.492<–1:option name Style type combo default Normal var Random var Normal
2018-09-13 12:50:37.492<–1:uciok
2018-09-13 12:50:37.507–>1:isready
2018-09-13 12:50:37.544<–1:readyok
2018-09-13 12:50:43.329–>1:setoption name Style value Normal
2018-09-13 12:50:43.330<–1:Setting Options….
2018-09-13 12:50:43.331<–1:Normal Mode.
2018-09-13 12:50:43.332<–1:Options set.
2018-09-13 12:51:37.602–>1:setoption name Style value Random
2018-09-13 12:51:37.603<–1:Setting Options….
2018-09-13 12:51:37.603<–1:Random Mode.
2018-09-13 12:51:37.603<–1:Options set.
2018-09-13 12:51:49.178–>1:setoption name Style value Normal
2018-09-13 12:51:49.179<–1:Setting Options….
2018-09-13 12:51:49.180<–1:Normal Mode.
2018-09-13 12:51:49.181<–1:Options set.
2018-09-13 12:54:43.028–>1:setoption name Style value Normal
2018-09-13 12:54:43.029<–1:Setting Options….
2018-09-13 12:54:43.030<–1:Normal Mode.
2018-09-13 12:54:43.030<–1:Options set.

Here you can see the chess GUI sending the signal to set the optional mode after each choice that I made while testing it out. My plan is to use a bool for styleRandom and have it make move choices based on that. You can check out the full commit on my GitLab if you’d like, but here is the main portion of the code:

void inputSetOption(string setString)
{
cout << “Setting Options….” << endl;
if (std::string::npos != inputString.find(“Random”))
{
styleRandom = true;
cout << “Random Mode.” << endl;
}
if (std::string::npos != inputString.find(“Normal”))
{
styleRandom = false;
cout << “Normal Mode.” << endl;
}
cout << “Options set.” << endl;
}

Linux – keep it simple.

Building picoEngine, a UCI Compatible Chess Engine

When I started programming, one of my early ideas was to build a chess engine. What sounds more sophisticated for a programmer, than building something like that? It just sounds smart!

Thus entered the “Beginner Engine” which I built for Android using a YouTube tutorial by Logic Crazy. It was great to have someone who programmed in Java explaining every step of making a playable engine. Unfortunately, it had some serious flaws for use on Android. None of which was Logic Crazy’s fault, he was showing the basics of building an engine. But it couldn’t castle, and bogged down my phone every time I used it.

After learning the ropes, I decided to build the “JustChess Engine”. It no longer bogged down the system, and despite being relatively stupid, it is quite playable (except for a pesky en passant bug that I still need to fix). The problem with using the JustChess Engine is that it was written by me for my application, so it does not respond to regular engine commands, like those from the UCI, or the Universal Chess Interface. Instead it only responds to my commands that I programmed it with.

picoEngine_1

Here you can see my new engine, picoEngine, talking to Arena Chess!

Hence, I’ve decided to build a UCI compatible chess engine, so I can learn how to interface with GUI’s through UCI. Thus, I’ve started a C++ project called “picoEngine”, which literally means very small engine. You can check out the first commit on my GitLab, and here is my first bit of working code:

/* Copyright 2018 by AlaskaLinuxUser (https://thealaskalinuxuser.wordpress.com)
*
* Licensed under the Apache License, Version 2.0 (the “License”);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an “AS IS” BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

#include <iostream>
using namespace std;

string engineName = “picoEngine A01”;
string inputString;

void inputUCI();
void inputSetOption(string setString);
void inputIsReady();
void inputUCINewGame();
void inputPosition(string posString);
void inputGo();
void inputQuit();
void inputPrint();
bool runProgram = true;

int main()
{
cout << “Waiting….”;

while(runProgram) {
getline(cin, inputString);

if (inputString == “uci”)
{
inputUCI();
}
else if (inputString.rfind(“setoption”, 0) == 0)
{
inputSetOption(inputString);
}
else if (inputString.rfind(“isready”, 0) == 0)
{
inputIsReady();
}
else if (inputString.rfind(“ucinewgame”, 0) == 0)
{
inputUCINewGame();
}
else if (inputString.rfind(“position”, 0) == 0)
{
inputPosition(inputString);
}
else if (inputString.rfind(“go”, 0) == 0)
{
inputGo();
}
else if (inputString.rfind(“quit”, 0) == 0)
{
inputQuit();
}
else if (inputString.rfind(“print”, 0) == 0)
{
inputPrint();
}
}
return 0;
}

void inputUCI()
{
cout << “id name ” << engineName << endl;
cout << “id author Alaskalinuxuser” << endl;
cout << “Apache 2.0 License.” << endl;
cout << “https://thealaskalinuxuser.wordpress.com&#8221; << endl;
// Options can go in here
cout << “option name Style type combo default Normal var Random var Normal” << endl;
// End of Options
cout << “uciok” << endl;
}
void inputSetOption(string setString)
{
cout << “Setting Options….” << endl;
// Set your options like: setoption name Hash value 32
cout << “Options set.” << endl;
}
void inputIsReady()
{
// Are we ready for input?
// Do any initialization first.
cout << “readyok” << endl;
}
void inputUCINewGame()
{
cout << “Creating New Game….” << endl;
}
void inputPosition(string posString)
{
cout << “Accepting Position….” << endl;
}
void inputGo()
{
cout << “Going….” << endl;
}
void inputQuit()
{
cout << “Quiting….” << endl;
runProgram = false;
}
void inputPrint()
{
cout << “Printing Board….” << endl;
}

I was even able to load it into Arena Chess and talk to it through the interface. Obviously it ran out of time because it can’t actually make a move, but it did respond to standard uci commands, which is great!

Linux – keep it simple.

Segmentation fault (core dumped)!

One of the most frustrating problems I’ve run in to date on my Water Drum game! Take a look at the output in the terminal:

alaskalinuxuser@alaskalinuxuser-OptiPlex-7010:~/Documents/c++/sfml_projects/sfml_water_drumming$ ./build.sh
DrumGame.cpp: In function ‘int main()’:
DrumGame.cpp:428:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (roundNum == demoMode.length()) {
^
DrumGame.cpp:432:26: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
} else if (roundNum < demoMode.length()) {
^
DrumGame.cpp:506:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (currentDemo == demoMode.length()) {
^
./build.sh: line 14: 3281 Segmentation fault (core dumped) ./DrumGame-app
type ./DrumGame-app to launch

A segmentation fault! But why?! It doesn’t really mention it here, so I tried to pull an strace on the program. Amongst pages and pages of gibbly-gook, there was this little gem about the exitButton being out of range.

DOH! I can be really, really, really dumb sometimes!

Here was my code:

window.draw(exitButton[numExitButtons].getSprite());

That should have been written as:

window.draw(exitButton[0].getSprite());

You see, there is only 1 exit button, so the numExitButtons variable was set to just 1. However, in an array (the []) the first (and only) exitButton starts with numeral zero! Boy, I can be a real dunce sometimes! All that time spent working on the issue that was a coder induced numerical error!

2018-06-12-124140_1280x1024_scrot

But, praise God, the DrumGame-app, Water Drumming! is complete! You can check the latest commits on GitLab, and download the source code as well! Be sure, once you extract it, to run the ./build.sh script. This game does require libsfml. If you try it out, you should drop a line to say what you think of it!

Linux – keep it simple.

Interview with WaveUp creator juanitobananas!

WaveUp is by far one of the handiest tools you can add to your Android arsenal! I’ve used this app for over a year now, and I love it! It’s like playing Jedi mind tricks on your phone! You can turn your screen on and off, simply by a wave of your hand over the proximity sensor of your phone, which is really useful to me personally. ‘juanitobananas’ was kind enough to answer a few questions for me in an email interview, as I have been trying to get in touch with open source developers and learn about the story behind the apps.

Screenshot_20180823-125715

A straight forward interface.

The Interview

juanitobananas, You mention in the readme.md for GitLab that WaveUp was your first Android App. I’ve used this app myself for over a year now. Actually, I used to include it in several custom ROMs that I built, such as SlimRoms Nougat for the Samsung Galaxy S4 and Note Edge. It is incredibly simple and super handy! (Pun intended!) While it’s function is really obvious, I was wondering what inspired you to jump into Android development and create it? Did you just need to be able to wake up your screen by waving, or was it a project for a class or school, or a hobby that turned into something bigger?

First of all, thank you, alaskalinuxuser! I’m glad you like WaveUp and
that you find it handy! 😉

As a huge open-source fan, I always try to use the open-source
counterparts of the apps I like. That is, if they are available. This
was not the case for ‘Gravity Screen On/Off’. This is where the
maybe-I-could-develop-such-an-app-myself idea started forming in my head.

Basically, the reason for me to create WaveUp was a combination of the
following: already being a programmer, my love for open-source software,
the non-existence of an open-source equivalent of an app I liked and a
will to contribute in some way to the open-source world, which had been
an itch I’d wanted to scratch for a long time.

Regarding the ‘jump into Android development’ part, I’d say WaveUp was
the perfect app for me to get started with something new, due to its
very simple nature. I was pretty certain I’d be able to develop
something like that relatively fast and in my free time.

With each version of Android that comes out, do you need to revamp some of the underlying code for your app, or is it a pretty seamless transition?
Due to the very simple functionality of the app, normally it is very
straightforward. Although this was definitely not the case for Oreo.
Without getting into too many details, Oreo introduced a much more
restrictive background execution policy. WaveUp needs to constantly run
in the background to work properly. To be more accurate, it just needs
to listen for proximity sensor events. I had always wanted to avoid
adding a permanent notification, but Google made it impossible in Oreo.
I had to put in some work to make WaveUp compatible with Oreo, and I’m
quite sure I haven’t been able to solve all the problems that arose.
How long have you been programming, and what got you started?
I have been a programmer for about seven years now. The first three not
being very intense (programming-wise I mean). My story isn’t the one of
a ‘natural hacker’, hacking stuff since I was a kid. I actually just
learned a little bit of Java and (less) C at university. With these
modest skills I landed my first job, where I would not only program. The
more I programmed the more I liked it. Today it’s my job and one of my
hobbies.
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 WaveUp under an open source license?
I didn’t even think about it. It was out of question: WaveUp had to be
released under an open-source license. Contributing to the open-source
world was just one of the main reasons for me to start playing around
with WaveUp. If I get a little deeper into this, I also believe in a
naïve and (scarcely) philosophical way that open-source makes the world
a slightly better place. I also enjoy believing that open-source is one
of the best expressions of freedom we have nowadays in our world.
Is there a reason that you chose the GNU General Public License v3.0 in particular?

The Germans use a word I love: ‘jein’. Jein is a combination of ‘ja’
(yes) and ‘nein’ (no). The answer to your question would be, jein. When
I decided to license it, I took a look at the most common open-source
licenses. I wasn’t sure if I wanted to license it under one of the more
restrictive licenses like GPL or one of the less restrictive (freer)
ones like MIT or Apache.

I really like the Free Software Foundation and see Richard Stallman as a
visionary, so I decided to go for GPL without thinking much further. I
like the idea of the derivative works being open-source too (although I
see it as a limitation of freedom). I might change it, but for now, I am
happy with GPL.

Your comments on your app read me files, as well as your profile picture suggest that you like having fun with your projects. Sometimes programming can feel like drudgery. Is there anything you do to try to make it more fun, or is it an attitude or perspective that you just naturally bring to your projects?

Good question! I know what you mean. The amount of frustration you have
to be able to bear as a programmer is pretty high.

I guess I *do* have a natural positive attitude towards things. That
helps. A lot. Throughout the years I have gained a lot of patience. This
is essential. But it has just become better after years. It is not
something I have consciously done to make my job (or hobby) better.

There definitely is a difference between me as a hobby programmer and as
a professional programmer. At home, I fight with stuff until it isn’t
fun anymore, and then look for something fun to do. My motivation at
home is to have fun with it and learn. At work I do fight a little
further. But not too much. If I hardly had fun at my job, I could really
not do it.

How much user interaction do you get from WaveUp, in the form of communication, comments, or issues?

I get quite a lot of reviews in Google Play Store, but the way the
reviews in the Play Store are designed don’t really allow for a lot of
interaction.

I receive a couple of emails a week, I’d say. I haven’t really counted.

WaveUp’s gitlab repo has had a total of 107 issues in its two and a half
years.

I’d also count all the people who translate it as an interaction, and
that’s beautiful. WaveUp’s first translation (apart from the languages I
translated myself) was Japanese. That was a Merge Request in GitLab. I
was really happy to see that. Most of the translations are done by
people using transifex, which kindly hosts open-source projects for free.

About how much time would you say you spent working on WaveUp?
I have no idea. A lot! A lot more than I’d ever thought.
Do you feel that your work on WaveUp is complete? Or do Android updates and user interaction keep you on your toes?

Mostly I see it as complete. At least for me. Although I *am* currently
I am working on a new feature to avoid locking the screen if a certain
app is running in the foreground.

I get a new feature request once in a while. Some of these I implement
but most I try to politely deny. Not because I don’t think they’re good,
but because I prefer to keep the app really simple, which I think is one
of the good things about WaveUp.

I still work on WaveUp once in a while, but not as much as I did the
first (and maybe second) year. Well, or some months ago with the Oreo
compatibility issue I spoke about earlier.

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

There isn’t much here, maybe ‘Scrambled Exif’
(https://gitlab.com/juanitobananas/scrambled-exif) which is a simple
Android app to remove metadata from pictures before sharing them.

Right now I am also working on ‘Drowser’
(https://gitlab.com/juanitobananas/drowser). The motivation behind this
one was to learn some Kotlin and write a replacement app for Greenify.
For those who don’t know, Greenify is a great app written by oasisfeng
used to basically stop apps from running in the background, but
unfortunately proprietary. Although I’d trust the developer, I prefer
the code to be open. So in order to learn some Kotlin and kill some
rogue apps in the background I started creating Drowser.

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?

You’re very welcome! Thank you too!

I’d say: Go ahead! Make mistakes. Be patient. Have fun!
Also, if you ask for help politely, you’ll probably get it.

Great answers! I really appreciate juanitobananas taking the time to answer these questions for me. It’s really interesting to learn about other developers reasoning on code, licenses, and projects!

 

Learn more about WaveUp

Want to know how WaveUp works? Well, you can read all about it at the WaveUp GitLab! Don’t feel like compiling yourself? You can get WaveUp on the Google Play Store and F-Droid as well! You can even check out his other projects, such as Scrambled Exif, too!

Linux – keep it simple.