Everything I can think of that I set out to do for Cycle 3 has been completed. As part of the transition to this next Cycle, I again will need to gather what core points I would like to focus on. While last Cycle included the addition of Android support, I still need to add the feature of pausing for when the Android operating system calls for it. The “Pause” button in the bottom left of the game itself allows the player to manually stop the game action and allows for the experience of a few upcoming features. However for example, if a phone calls happens, the game will effectively crash on Android. To my knowledge, this does not pose as an issue on desktop and laptop systems.
I would finally like to focus on art somewhat. I have some resources for transitioning 3D resources to a 2D model. I take this path, because I am not completely fluent with human anatomy. By keeping with a 2D environment, older devices should still maintain reasonable gaming performance.
I would like to put together a skeleton structure for adding upgrades to characters. I originally intended on using the ‘Gleaned’ music set for this purpose. I desire a relaxed aria for a moment of strategy. This music set rests as available when the “Pause” button in the bottom-left corner inside the game becomes pressed.
I also want to build the beginnings of random story encounters. Key events of the story line will remain the same, but battling “story bosses” would influence the story in different array of ways. I may also take a similar approach with potentially hostile environments, instead playing out a bit like a board game with the advantage of real-time elements. In a standard table-top game, each player must wait for his or her turn to participate.
Several other items need reviewing. While the details listed above in this post will likely survive to make Cycle 4, I must also consider the possibilities of other issues. The toughest barriers to progress this last Cycle included revising limitations in the code and the previously thriving need to focus on school. At least for now, school no longer demands attention. Updates to my goals for this project reside in the Airtable chart, which pulls up from the “Progress Status” button found at the top of this page.
Thanks for your attention span!
I am satisfied with the level of protection on the software for now. Everything seems smooth so far, and I have yet to find a bug with it. The tech support at Allatori performed very well at their duties as I requested help.
I will need to post the ready results of Cycle 3 on this site and update the Licensing page for the new songs. I eventually need to also add the licensing details into the game itself, since the project presently stands mature enough. While I intend on posting the MacOS version, I can not presently test it. The Android version of the software will initially arrive on this site and remain available for a time. My intent includes placing the game on Google Play, but the current file size limit on that service requires that I delay that action for the moment. I need to break up the game into smaller pieces for a more gradual process of downloading, which I will likely initiate sometime in Cycle 4’s middle.
I would like to entertain more the thoughts of enhancing the art in the game. The Saphirel and Scorpibot animations carry an age that approach the length of a decade. It is time for some new stuff!
Thanks for reading!
I have finished the basics that I required for this Cycle. I still need to run the code through Allatori to see if that properly works. It has been a fun and long run these months, but I am ready to move this project into different directions. I have graduated school, and I need new direction for myself as well. Hopefully, this testing process ends soon.
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!
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.
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!
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.
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!
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!
In regards to Windows, I might consider “Launch4j Executable Wrapper” for future builds of the demo.