Progress Update October 2013 news - Odyssian Void

Hello everyone and welcome to our progress report for October 2013. I want to kick this large update off by first correcting something I mentioned in the last update. After originally contacting Epic Games about the use of the Unreal Engine I was quoted a price for a single use license when I had called their support line. I was then contacted by their licensing division through my website email and let's just say the sticker shock was over 9000; UDK is pretty much not viable for 99% of indie developers.

So, that plan laid to waste I started looking for other more affordable engines and have found a few. My main contenders are Panda3D and Torque 3D. In both cases the engine is free for use and are capable of impressive visuals. My second runner up is an engine called Cafu; this one costs around a grand for a license.

I spent some time at the end of the month playing around with these engines but I will need to do some serious work before I can determine which of them I will be using.

I also took the time to redo the entire change log on the wiki so that it was much more readable; I will be updating that tomorrow with the full technical details from the changes made during this update.

So that news out of the way we have a crapton of change log-i-ness to go over, about 7 and a half pages in my word document.

There was one project wide change that occurred. Due to some changes made every function call for the mRMessage function was altered so that the function call took place inside of a c-out statement. This was necessary due to how the function was changed to return a string after having queried the database through the datasystem class.

Many changes were made to this class in preperation for the splitting of player, player allied AI, and hostile AI actions. bFSolutions was altered so that it would only deal with the player's choices and the other code was split off into other functions dealing with each separate instance of AI. There was also a quite major bug in the rewards function. This was because the player class was not being updated after battle, this meant that any rewards gained would not be represented in actuality within the player class.

I began work on adding in the AI for the battle loop and I also added in code to deal with the timers for disabled shields and/or ships. The pRetreat function was renamed to bRetreat and I also added in the code for this function as I had not realized it was not yet created (it has been sitting in the header file for half a year now; derp). Retreat is based on several value ranges between 1 and 100 and will, in later versions, have variability related to ECM and warp disruption/aggregation modules.

Fixed a few incorrect calls to the player class where I was calling the player through mPlayer instead of through the pTeam vector and also incorrect calls to the vector that were left over from when the vectors were arrays. Added the bRChance variable to store the randomized retreat value and added a reference to the map class. In addition I also created a call to the bMap setup function in order to set up the entity positions and initialize the battlefield.

I added several new variables to deal with tracking the team leader targets and also to determine if a specific team is in battle. These are used by the AI to determine, based on player selected settings in the future, if battle is ongoing and who to attack if it is. TODOs were also added into the class to remind me of some ideas for dealing with the AI in the firing solutions function.

One over looked area that I fixed was adding ship destroyed checks to the battle loop for player wingmen and hostiles. Another large change is the way in which wingmen are now dealt with by the code. I made wingmen a part of the entity class so that any entity can have access to them. Though this may create a bug in the future where, since wingmen are in fact entities themselves, wingmen can have wingmen of their own and so on; however this may be beneficial from the fleet aspect where your wingmen act as generals for your various fleets.

Due to this change every reference to xTeam must now become mX (mPlayer/mHostile/etc). I have started that process but there are still a few areas that need to be dealt with. I also removed an extra allies variable set that was not needed in one of the init functions. Also because of the changes I then went on to recode most of the battle loop as well as endBattle.

Removed the mHostile reference pass to initHR# as it is no longer needed and then I also rewrote the bAParticipants and bFSolutions due to the changes listed above. Removed some comments from the cpp file as they have now been implemented and are no longer needed to remind me to add them. In addition to all of these changes from the ones listed above I also had to go through a few other classes and deal with these changes there too.

I added a TODO to the end of bInit because I realized I was missing the last five ranks from the function. I then went on to recode much of the hInit# functions and included new code to account for things forgotten or required due to changes as well as correcting a few bugs. I also fixed a serious bug in bFSolutions for wingmen where the code would have throw the for loop out of bounds and caused a crash.

Began coding the distance checks for weapons which have a minimum and maximum range as well as the optimum ranges. I then added a new variable to hold the distance between the attacker and target ship. Later on in the month I added in the rest of the range checking for implemented weapons (rail guns and heavy weapons still need to be added to the game). I also added a TODO to remind myself that there will be bonus damage from optimum range strikes. A range of 1.5% to 2.5% will be applied to the damage total if a weapon hits within the optimum range.

I also added in the collateral damage calculations for bomb damage; they were not present. While doing all of this I found a few lingering bitwise and/or operators that I had missed from the previous update and I fixed an issue in processSDamage where some damages were being turned into doubles instead of floats. Added a second vairable called dBCollateral to store the extra damage caused by bombs.

Added several new functions to deal with opening, querying, and retrieving data from the database. I also added in the SQLite3 variables required to complete these tasks. Vectors were added to store information while it is being transferred from here to datasystem and then to the requesting class.

I finished off the code for the basic framework to get information from the database, cast it into a usable format, and then store it within placeholder sub-classes so that the information can then be returned as a vector pointer to datasystem where the data is stored within a new instance of the placeholder sub-class while the code gets the data it needs. There were several issues along the way but eventually I got a test program running and incorporated it into the code.

While doing this I found some problems with one of the functions, the mission function; it was missing several items that cased returned data to be incorrect. Corrected the error in the test program and merged it into the code. I then removed a second missions function I had added while doing some testing to figure out a few issues that I was running into.

Finally I began determining and planning the best way to deal with how to incorporate the save and load functions into the new system. No coding has yet taken place but I expect to get more into this area in December.

This class contains many sub-classes made from structs that will hold various information as it is transitioned between the datasystem and database classes.

Added several vectors to store placeholder sub-classes for transference of data between it and database. I had to go back through and rename these to solve naming conflicts between the two classes. Due to the changes most of the functions in this class had to be recoded entirely.

Most of the code was stripped out and replaced with simple one-line functions to return certain variables while some had to be extended to deal with nulls and return back a value that could be used more easily with the type of data being stored.

I also added in, which took a bloody long time, the in-file change log for this class.

Removed calls to rData from all data retrieval functions and made a new function for the task. How it works now is that an instance of datasystem is created so that rData only has to be called once. This is to save cpu cycles that would otherwise be eated by the game constantly accessing and querying the database for information. Many changes in several classes, including this one, are required due to this change.

Removed all of the xCode variable passes to the get functions in this class as they are no longer required since the value is passed to rData now instead. I then had to add a function to return the text of the query for message requests. I finally then added returns for the race and rank queries as well.

Only two changes were made to this class. I moved the getNOWingmen function and the wingmen vectors to the eWingmen class and then I changed the message processing reference from msg to mp to make it conform to how it is used in all other areas of the game.

Removed iCode from the hard point constructor as it is no longer needed due to changes in the ship class and edited the code to take into account this change.

Edited the constructor for the new database functions and changed hSetup to use the new data acquisition method.

Brought this class over from 0.4A and merged many of the functions into the code. Some had to be recoded to take into account how the code has changed since 0.4. Added the movement system back in and began work on how to implement both the distance formula as well as how to deal with how to create the battle field positions for wingmen; finally settled on creating a random positioning system for wingmen with their base coordinates being based off of the team leader's position.

Fixed a compile problem created by circular referencing. This is the process where a class is referenced in a class that references that particular class. In this case map and entity. This creates a paradox loop for the compiler as it attempts to find the information to port over into the class the reference is in when it finds the reference back to the originator which then gets sent back to the referenced class and so on. The fix is to make a forward declaration for the class in question under the includes.

Changed the setPOS function to take mPlayer and mHostile as parameters instead of vectors for dealing with wingmen positioning. Changed any and all references to pTeam of hTeam to their correct references.

Added the bCSpread function, I had apparently not added it yet. Changed pBStatus and hBStatus functions to take the respective class references instead of vectors. Other major changes took place with these classes. All of the inter-defined variables were stripped out and added to the class definition like they should have been in the first place.

mRMessage has been completely recoded and changed to account for the new method of getting data from the database. Removed some variable types from bHStatus, left them in by mistake and added a new function for the movement of system menu options.

Altered the pCShip function slightly to deal with the new database format and removed the parameters from iWeapon in pCxWeapon function as well as removed the setWeight call from the bomb function as it is no longer needed (iWeapon now will set the weight).

Added a new function to decrement the disabled timers and to unset the disabled flags when those timers reach 0. Added new variables to store the position of the ship in 3D space. Copied the movement system from 0.4 to this version and went about fixing it up to work properly with 0.5A.

Added several new variables that deal with the movement system and also went through and fixed up some of the mRMessage calls so that they would properly call the function. Added some extra checks into the initHPoints function to display a message if there are no open hardpoints for the weapon type attempting to be installed. Added an AI version of the initHPoints function as well, minus the text messages.

Changed the way that initShip executes. Instead of using the old data system it now will use the new one to obtain the ship data. I also changed iWeapon a little; added in some extra code into wSetup that will give greater access to weapon info in iWeapon. I also added rail guns and heavyies to the function as they were missing.

Added a new function called iWeapon to initialize weapon names to "Not Initialized" for use later in weapon installation. Changed the wSetup function to account for the changes to the datasystem and database classes. There were some problems with the cpp file that had to be fixed and the offending code was either rewritten or moved to the correct areas.

Added functions into several classes that were missing and added the getWeapon function to the rail gun and heavy classes. I also removed setWeight from bomb as this is now set elsewhere.

Created this class to deal with realizations on how difficult it would be to deal with vectors of player and hostile entities as time went on and the code became more complex. Instead wingmen are now accessed from the player or hostile entity itself and all of the annoyingly brain-numbing code to deal with the vectors is able to be removed.

As you can see a lot of progress was made but we are still a ways off from an actual working version. Many things need to come together first. Though progress in any form is good news. I will also continue my work on the engines mentioned at the beginning of this news article and I will hopefully have a definitive answer with in the next couple of updates.

I leave you now with the 7th developers vlog and some new music tests:

Thanks for following the game!