I promoted the test version of Ancient War to production on the Play Store the other day.
It looks like only 3 people have downloaded it — probably family members.
I even added a video to the Play store entry, to see if that helps people to find it.
We just got back from a cruise on the Royal Caribbean Allure of the Seas. This ship normally holds a maximum of 6700 passengers. For our cruise it had about 2400, so it was great from a resource utilization perspective. The elevator never stopped when we were going somewhere — Since we were on the 14th deck, we were on the elevator quite a bit. One morning my wife and I went down for coffee, and we were the only passengers there (at about 6:15 AM), at least for a few minutes.
Another thing that was different about this cruise was that at least a third of the people were Pinnacle level (in the Crown and Anchor frequent cruising program) – it takes quite a bit of cruising to reach this level and these folks clearly wanted to get back at it.
The following is a picture of us leaving the dock at Port Canaveral. The vertical object on the barge on the left side of the picture is a recovered Falcon 9 rocket booster that pulled in right as we were leaving port.
The people on the cruise were very aware of covid protocols. You had to be wearing a mask whenever you were indoors, unless you were in a ‘vaccinated only’ area. This picture below is of the line to get the first of many vaccination card checks. It moved along fairly quickly and we were on the ship before noon. One recommendation is that you get to the ship early, since we were seated and had lunch on the ship, before noon.
Since everyone was vaccinated (except some children), most of the venues were marked as vaccinated only areas. Having a vaccination was a requirement for the cruise for all the adults. Another requirement was that you have a negative test result, within 48 hours of departure –- that was the most stressful part of the whole experience. Since the rapid tests were not allowed, we were tested using two different providers, in hopes that we would get at least one result quickly. Next time I would use the cruise line supervised at home test, rather than stressing out about getting the results. I think my vaccination and test status was checked at least four times, and my passport was only glanced at once before we got on the ship.
Overall, the cruise was smooth. The weather was perfect for the entire trip, even though we had to dodge a hurricane. The entertainment was great.
All the entertainers were very appreciative of being back to work. The show was Mamma Mia! and it was by far the best performed musical I’ve seen on a cruise ship. The lead singer was outstanding. The instrumental musicians were very impressive as well. We went to some sort of jazz performance every day. The comedians had you rolling in the aisles, too. The two comedians had quite a bit of material, since they had spent the last year at home with their kids.
The service on the ship was very conscientious. They were glad to be working, as well.
The food quality was a bit less than what I remember, though we did have some great meals.
Several of the ‘normal’ activities were missing like the liquor tasting and other events that require people to be in close proximity. Some were just scaled back, like the art auction (with no champagne).
As I mentioned earlier, we had a balcony on deck 14 on the port side, near the bow. This gave a great vantage point for watching the ship cut through the water. I’ve been on numerous cruises, and this was the first time I saw flying fish. If you look where the white water begins to form , you can often see flying fish taking off perpendicular to the ship’s course. We saw one fish that probably flew for 45 seconds before diving back into the water. There were often birds lounging around waiting for these fish to take off, so they would swoop in and try and grab them. From our rather high location, the flying fish almost looked like hummingbirds coming out of the water.
As far as the ports went, St Martin was in pretty rough shape with many stores closed and people pan handling on the beach like crazy. Not sure if it was covid or the hurricanes that have been through there recently, but their economy looked like it was in the tank. Notice all the people in the picture below!?! Our ship is the furthest one.
St. Thomas was in much better shape, though they could use more tourists as well. I think we were the only boat in that day. There were shortages of things to sell in the shops, for example gold chains were almost impossible to find. Note below how much harbor activity there is in St. Thomas – almost none.
One thing we tried on this cruise was the unlimited thermal spa package. This was $199 per couple, and we used it once or twice a day. You could reserve it for up to an hour. They had three different saunas and heated relaxation chairs. By the end of the cruise, we were ready to take one of those chairs and sneak it into our luggage for a trip home.
Overall, it was a great cruise and I’d happily do it again — we went with a neighbor so we kept busy the entire time, even if it was just sitting out on our balconies watching the world go by.
Now that I have had a few people test out Ancient War on a range of devices, it is clear that my understanding of the libGDX user interface was not up to the task.
I am in the process of redefining the UI so it may be a while until I have another test version. My problems are caused by the limitations of skins. Fonts are defined to a fixed size, where everything else can scale to the screen sizes. Fonts need to be kludged with to scale. I have yet to find a way to do it cleanly.
Granted there are ways to get around this, and I knew it was going to be a problem as soon as I saw how fonts were defined — it is a bit odd for a GUI to have elements that are this fixed — IMHO.
In the version currently out for test, if the device has a screen width of less than 1500 pixels, the GUI starts to breakdown.
Now it is time for some experimentation… to make it look better!
Here is a simple example of the error being seen:
The button size is based on the screen size but the font is fixed! Even the button size is behaving a bit odd! This devices screen width is only 854 pixels.
It is not like I have not published something on the Play Store before, but this is the first time I’ve done something with libGDX and the various changes that have taken place in the Play Store recently.
If you want to try ‘open testing‘ for the game, search for ‘Ancient War Bess’ or follow this link and install the program from the play store entry.
There are a few bugs that I am aware of, but if you find something new, I’ll try to fix it. Count on updates coming out over the coming weeks.
For those geeky enough to care about what the changes I had to make to the gradle file in the Android Studio files for this project to work, in the gradle file for android I had to have the following settings:
release {
minifyEnabled false
multiDexEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
This makes it so the optimization process doesn’t hide some of the code entry points that actually allow the program to work (at least that is my understanding).
I’d say that the whole Android Studio build and promotion to production process has gotten so ‘complex and wonderful’ that it is VERY fragile.
Found out a few things over the past couple of weeks.
I went through all that because no matter what I did, I could not get a Play Store entry that would actually run once installed on the Android device. I started over with a new build and new Play Store entry. I am back to where I was weeks ago with a game in the store ‘review’ process.
Hopefully, I’ll see in a few days if anything is different and the newly uploaded program works.
I think part of the complications I ran into was based on them changing all the rules on August 1st and all the documentation and examples out on the internet are not up to date. At best the instructions on what to do are lacking in detail — at worst, they are totally misleading.
I should have an update in a few days and will let anyone running Android (who cares) know how to install the program from the Play Store.
I did add some features to the program while I was thinking about the problem, like Top Score tracking
and some tactical control during the battle.
I also added a bit of in game help so you could know more about the foundations and the prioritization of populating the ranks of a formation.
OMG, the release process for Android Studio is not working the way it used to. Now (as of this month) you can only promote ‘signed’ application bundles to the Google Play Store. That wouldn’t be too much of an issue, except that it appears my Android Studio does not effectively sign them!??!
I can build an unsigned APK, and it works fine if I transfer it to my phone.
I can build a signed bundle and put it into the release process for Google Play. The process gets all the way to the point where someone can install the app on their device. The install completes from the Play Store and when you try to run it the screen flashes and that is it. No error messages, no nothing – the app just dies.
I’ve just spent about a day and a half digging around the Internet to identify how others have tackled this issue. Made adjustments… It appears that there are numerous people having similar problems out there with the release process. I think it has to do with the key store but that’s only because my unsigned version works.
The only way I am going to get a handle on this is to start at the beginning with a tiny LibGDX app. Make sure it works. Then sign it, making sure it still works. And put it into the release process to see if something tiny works. After that, I can just continue to add complexity until it is my full app.
If I can’t get a tiny app working, I’ll go back to the YouTube/search cesspool of issues that others have been dealing with and see if I can get some insight from one of them. I guess I could also uninstall and reinstall Android Studio, in case there is some issue with my build.
It is frustrating when tools (and your lack of understanding of them) gets in the way! I just saw that there was a fairly major release of Android Studio, so I’ll fire up that update and see what happens.
The last time I setup a release of a program on Google Play was with QSOSender3 (a program to simulate interactions for ham radio code training). Back in 2017, the process was relatively straightforward.
Today, it took me 3-4 hours to figure out all the settings that needed to be defined — and more importantly where to find them! The Play Store release process kept complaining that I didn’t have release countries defined. I swear this used to be optional, so I skipped that step during the initial deployment definition. It was a convoluted research effort needed to find those settings again and fix it.
The Google Play interface was more than happy to tell me that the country definition was missing, but a little scarce on the details of how to resolve the issue. Eventually, I found a countries tab in the user interface for the app release, clicked on it exposing the options that needed to be checked to define the release countries.
After defining a closed beta, an open testing release and finally resorting to a production release, I found an announcement that once you have ‘released’ your software to the store, it will likely take at least 3 days (and that is only an estimate) before anyone can see it. This review is a safety measure to ensure that the software is relatively safe, before anyone can install it. It appears that no matter what size target audience, the review takes the same amount of time. For a closed beta, I only had 3 names on the list and that review used to be almost instantaneous, but no more.
Maybe by Monday, I’ll see something show up, somewhere (unfortunately, it will probably be all three release types). I can then clean up the mess that I find and limit access to only a few until it is more refined.
The following is the game icon, I created, simple but hopefully effective.
Even though my efforts are not what I would consider a completed game, I am going to move it into Google Play so that others can ‘play’ with an alpha test and make suggestions. There is a whole strategic level for the game that has not been thought out. Most of the work to date has been on a tactical interface.
I’ll need to do several things (e.g., create a logo) before going to the store, but I hope to have it out there soon. I am sure that Ancient War will crash on some machines or at least ‘look ugly’ since I don’t have all that many devices to test it on. Hopefully, a few people will look at it and give some feedback.
Publishing will likely be done over the weekend, so I will probably not do another post until then.
There are also a few things that I’ve been putting off for a while that will not be accomplished before the first alpha test (e.g., dialog backgrounds) but I can work on those while awaiting feedback.
Now that the sound is working, it is about time to turn it into something that can be played. So far, the program has mostly been a demonstration of movement and screen element control. Though this is not the final version of the game structure, it seems like it would be a good time to get a version 1 out so people could play with it.
All that is going to happen right now is that when you first start, there will be a number of resources allocated. For example: 100 tokens. Those can be used to buy army elements like:
Archers: 2 tokens
Warriors: 1 token
Knights: 4 tokens
The largest group you can have for a particular battle will be 18 solders.
You can then select the formation desired, and the priority of how it will be populated.
You can then proceed to the battle and see the result.
After completing a few battles, the winner will be decided based on resources remaining.
The following is a very early screen layout for the resource selection:
I still need to add a continue button…
In the process of putting this dialog together, I was surprised to find that LibGDX really didn’t have a screen actor for radio buttons. It does have ButtonGroup to provide the single selection functionality, but not a separate GUI element.
This can be addressed with skins but I’ll need to dig into that to see if I can have both a CheckBox that works/looks like a traditional check box in the same skin as one that looks like a radio button. The worst case is that I’ll need two skins, one with a square CheckBox GUI and one with a round CheckBox GUI.
I was pleasantly surprised that adding sound to the game was straightforward. One of the biggest issues was how much sound to add to improve the game experience. You don’t want too little, but too much is just irritating.
I identified sound for each hit, death, and background. Once the sound was working it was apparent my archers were launching many arrows and the sound was just annoying. I still need to work that out. Turns out that LibGDX doesn’t have a function that lets you know if a sound is still playing. It does for the Music class, but the Sound class as less functionality (read as lightweight, since sounds should be less than 1MB in size).
LibGDX provides tools to both load the sound data asynchronously as well as play the sounds, including in loops – that’s what is needed for background sounds.
When the program starts up, I loaded up all the sounds that are always going to be used, using the AssetManager:
manager = new AssetManager();
manager.load("audio/sounds/ava.wav", Sound.class);
manager.load("audio/sounds/avk.wav",Sound.class);
manager.load("audio/sounds/avw.wav", Sound.class);
manager.load("audio/sounds/wva.wav",Sound.class);
manager.load("audio/sounds/wvk.wav", Sound.class);
manager.load("audio/sounds/wvw.wav",Sound.class);
manager.load("audio/sounds/kva.wav", Sound.class);
manager.load("audio/sounds/kvk.wav",Sound.class);
manager.load("audio/sounds/kvw.wav",Sound.class);
manager.load("audio/sounds/afall.wav",Sound.class);
manager.load("audio/sounds/wfall.wav",Sound.class);
manager.load("audio/sounds/kfall.wav",Sound.class);
At some point later, I can call finishedLoading to ensure that all the assets are loaded before they are used.
manager.finishedLoading();
When I load up the battle field, the sound specific to that field is loaded, the volume set based on the preferences created earlier and start the sound playing in a loop.
backgroundMusic = Gdx.audio.newMusic(Gdx.files.internal("audio/music/"+baseBackgroundString+".mp3"));
AppPreferences myPref = gsm.getPreferences();
currentBackgroundVolumeLevel = myPref.getMusicVolume();
backgroundMusic.setVolume(currentBackgroundVolumeLevel);
backgroundMusic.setLooping(true);
When a battle takes place and events happen, the resources that were previously loaded can be sounded. I am still working on this part since it is bad form to have the AssetManager be a static class (especially on Android?!?!). I’ll have to post on that a bit more later.
Now I have some sounds going so sound selection becomes important. Right now, the ones being used are sounds I purchased from a Humble Bundle.
