Battle System Re-design and Other Progress

With Android added to the supported platforms, I quickly face the need for adding a pause feature to the game.  This comes in two flavors:  an ability for the player to pause upon a whim and the capability for the device’s operating system to safely place the software on hold.  For example, the game’s current state will cause accepting a phone call to either crash or reset the software.  I have placed effort already into the process, but I came across a limitation when testing.

As mentioned several posts ago, I introduced ScheduledThreadPoolExecutor.  It works quite well for executing tasks based on the concept of timers, but it does not allow the capacity to monitor whatever existing timers that may previously count down in its queue.  I can still access the job items though.  The system driving the progress bars seems to not express any trouble with my current attempts for pausing.  I would like to mimic the success of the progress bars with the battle system.

I desire to take advantage of the moment and expand the battle system.  As of this posting, it only supports Scorpibot and Saphirel.  I would like to add the capability of handling more than two characters, plus I aim to throw in a dash of randomness towards the notion of who initiates attacking first.  Basically, that comprises the essential idea of “auto-battle”.  I want to roughly personify each character as an object in a list of characters that each possess a timer statistic for tracking “initiative”.  As far as auto-battle goes now, Scorpibot and Saphirel just exchange blows every four seconds.  In other words, I prefer to swap the handling of timers by the ScheduledThreadPoolExecutor to a List of character objects instead.

The game’s download size will increase somewhere under a measure of 100 Megabytes when I eventually post its next version, because I added new music.  This prepares for the slow integration of Sylveria into the software.  Also, the game now randomly chooses from one of three random backgrounds to present for the sequence of battle.  As another added feature, Saphirel’s own health bar keeps track of his survivability.  I put in place a way to check a single opponent’s health, but I intend on later mixing it with an individual test ability of Saphirel to help promote its usage.  I will wrap up Cycle 3 when I obtain successful test results with Allatori as the last step.

Thanks for reading!

Android Conversion Complete and Compatibility Issues with Apple

It took a while, but I finally managed to migrate the project’s code base to also work with Android.  It took some effort to fit the action into smaller screen “real estate”, and the font size still needs some serious attention.  I also obtained a developer’s account with the Google Play Store, so eventually, the Android version will become available on Android phones and tablets.

It might be at least a few months before I can address iOS.  On top of that, the chief leaders of LibGDX, the game frame-work I use for this project, do not currently pursue keeping compatibility with Apple’s new approach to gaming.  In this article, you can read how Apple decided to drop OpenGL in favor of its proprietary solution:  Metal.  Apple never put much effort into keeping it a secret, sort of like how the business refused to invest much into OpenGL.  Apple tends to treasure the proprietary stuff that it owns in much higher regard, and while Metal has the capacity to create both a better and more efficient gaming environment, it sort of isolates Apple systems even further.  Either way, Apple proves repeatedly that it knows how to arouse profit in that specific type of arena.

On the good side, I think I found an open source solution for maintaining compatibility between Android and iOS / MacOS.  I applied this effort for the purpose of building non-gaming software in a professional way.  The Multi-OS Engine, a project of Intel, keeps a valid avenue available by using “native code” instead of keeping a reliance on OpenGL.  While Gluon and Codename One still appear to need OpenGL for Apple stuff, I expect those businesses will adjust as necessary.  I will need to acquire a different Mac for future testing, since a currently supported MacOS stays essential for building iOS software.  I will likely attempt to integrate the Multi-OS Engine with LibGDX in my game project for the future, just for learning’s sake.  While OpenGL remains on MacOS for now, “deprecation” inherently means that it will no longer receive updates.  That includes no longer receiving patches that will help it function should it accidentally stop working.

Cycle 3 – A Few Updates

I decided to review some Kanban stuff, which is meant for keeping things organized for projects.  The idea involves keeping notes under three different categories:  “To Do”, “In Progress”, and “Done”.  I wanted something with a nice web presentation.  Many of the sites I experimented with did not offer this option, though some did have good layouts.  After reviewing 30 or so web sites, I narrowed the choices to Trello.com and Airtable.com.  When I tried a basic layout with Trello on my mobile phone, a rather “large” menu covered most of the screen.  With Airtable on mobile, it instead just groups everything into one large column of different colors.  I have chosen Airtable for now, just because it remains a bit more readable.  You can now find this project’s current progress by clicking the “Progress Status” button in the top menu.

I have migrated the project from the Eclipse IDE to IntelliJ IDEA Ultimate.  I tried reasonably to run the project with both Eclipse and Android Studio.  With Gradle, it could work with just Android Studio alone, and I am aware that developers exist who correctly pull off the technique.  Android Studio poses as a unique form of IntelliJ, tweaked by Google.  Either way, I had to give up on Eclipse, and I do not desire to focus on Gradle for Android Studio’s sake.

In some other news, the Android side of the project now works!  The entire project kept hanging on the database part.  I use SQLite in this case.  Android runs well with Java, but the SQLite part of it functions very differently from the Desktop / Laptop side of things.  To get it working, I utilized a recently updated version of SQLDroid to spoof Android into thinking that it could work like Desktop / Laptop.  The secret lays hidden in SQLDroid’s code and not any of my workings, plus it consists of open source stuff if that “floats your boat” in some way.  I still need to fix a bit of code in my project to make the Desktop / Laptop side work again, but it fortunately should not require much.  Lastly, I will need to re-size the animations.  I think it brings in the need for LibGDX Viewports.  I believe that my animation software, Spine, naturally prevents re-sizing in Android, so the characters appear considerably smaller among the other items.

Thanks for your time!

Graduation!

Great!  Now I need to figure out how to fill my time.

I am experimenting with Trello.com to help organize the mess that can make up a video game.  One major item I desire to test includes converting the project’s current source code to be compatible with Android.  I would need to create a fresh template with the ” gdx-setup.jar ” file from LibGDX.  This project did not originally use that template for the sake of personally comprehending the code better.  I originally tweaked the Super Spineboy example from Esoteric Software as this project’s starting point, pulling animation resources from this project’s really old Lua version.

I am considering the process of taking a 3D character inside Blender, converting it into a 2D model along with its skeleton info, and then animating the results with Spine.   I have experimented with a 3D model,  and the Python script for capturing the layout of the bones works with the Rigify add-on of Blender.  However, I lean towards using BlenRig instead of Rigify for the work flow, because it possibly allows a better layout for the model’s skeleton.  The Python script I found might not function with BlenRig, so I will need to test it.  The whole purpose involves the possibility of mixing 2D with 3D for battle scenarios.  I have the models I want, but I am focusing on the male version for the present time.

Java 10 Compatibility

This project mostly utilizes Java 8 , and according to Oracle, security updates for that version will cease about the time January 2019 arrives.  On March 20, Java 9 reached “End of Life” right as Java 10 freshly came out.  Java 10 will receive security updates for 6 months, more or less.

My experiments mixing Java 10 with the software demo encountered no issues.  From observation only, the loading times in Windows nearly halved, but I gave no attempt to accurately measure results.  Loading times in Linux appeared the same.  My operating systems of choice rely on the OpenJDK from Azul Systems for now.  Also,  Allatori  worked fine.

One of the reasons I chose Java as my programming language of choice involves its excellent “backwards compatibility”.  So far, it holds up well.  I have a couple of documents left to finish for school, so I would like to resume my slow progress with this hobby of mine.  Thanks for reading!

Break Time!

I am trying to finish the last segments of school.  I have one particular project that demands a lot of my personal time now.  As of the time of this posting, I have avoided development on the game for the last 2 weeks or more.  I do have a list of things I look forward to adding, like a background picture, health bars for the bot and Saphirel, and maybe the current form of Sylveria’s music selection.

When I can, I will need to put together a plan.  It is just not going happen immediately.  Thanks for reading!

Cycle 2 – Complete!

A new version of my software is available under “Project Download” across the top.  To summarize my efforts, I focused on cleaning up the “user interface”.  As of this date’s posting, this particular software edition includes the most recent update to Java 8.  I am very satisfied with the results.

Quite the distance still exists for this software game.  I might add some polish, so that the battle sequence goes smoother and longer.  Saphirel’s “Ability Test” buttons still lack much, and they do not affect the battle in any way.  I look forward to the opportunity of changing that item.

This release marks the  completion of Cycle 2.  I will need to gather some information and plan the next point of focus before moving onto Cycle 3.

Recent Progress

It may take a while to flesh out battle sequences.  I feel that emphasis on the GUI, or “Graphical User Interface”, is more important at the moment.  For that reason, I am delaying creation of art and story crucial to the “game”.

I had to revise the system of taking turns.  This should also help me study with the Java OCP certificate.  The new class I switched to goes by “ScheduledThreadPoolExecutor”.  I apologize if the information seems difficult.

For about a year or two, the logic meshing together the battle and GUI stuff co-existed closely.  I achieved great success with dividing the two, and fortunately, more needs dividing.  At the moment though, the explosions still remain with “battle” code.  At least, the pink explosion gets its own button!

I accidentally stumbled across an example for a “loading bar” concept.  It basically shows the progress of how soon the demo will start.  As of this post, it works, and I currently labor to add the notion to Saphirel’s buttons.   They should present an idea of the remaining time left for a button to potentially re-activate.

Finally, Oracle freshly released another Java version.  I wait patiently on Zulu’s next Java edition.  It may take 2 weeks or so.  I expect that my next rendition of the demo should prove available then, under the “Project Download” tab.  The old December 2017 copy stays for now.

Thanks for reading!

Cycle 2 Start

I accidentally “zapped” the blog of the software’s first creation cycle.  As a result, this site experienced some re-work.  I believe that the first cycle emphasized well the template for a character battle.

For Cycle 2 at the moment, the stuff that enables battles to work co-exists too closely with the frame work of LibGDX.  I basically need to separate the two more cleanly, allowing a battle to begin and end properly.  For now, a battle starts immediately when the software executes, and it ends when the software closes.   I am not yet sure how long the task will take, but most of the progress has already been finished.

I also intend on transferring the pink explosion into one of Saphirel’s ability buttons.  Progress will be slow as usual.  Thanks for reading.