Hey everyone, welcome to our first progress report of 2016! A lot of stuff happened at the end of February that pushed this and everything else I was working on back a ways and I am now just getting back on top of things. So, lets go over what got done these last three months and then we will get into some deep level details.
First and foremost a lot of coding was completed during this development cycle as well as a lot of work within the database. I would say database work to coding was about 50/50. Made some major changes to the database which sparked off a lot of work within the data_placeholder, database, and datasystems classes. There was also some other large paradigm shifts relating to the modding system but we will get into that in a minute. Other large news items are that I have officially setup the GitHub project site for 0.6A. You can find it at this link: Github.com
I set this up because MSVS 2015 actually has built in support for Git. This will allow me to keep versions and branches separate and also have an online backup should anything crazy ever happen. This will also let you track how much work is actually being committed to the project as well.
With that last statement in mind I also want to announce that I have setup a new Linux server that is hosting some agile software that will be used to not only give you a granular level of detail of the planned work for a development period but to also allow you to track the progress of each cycle and what to expect, coding wise, from the outcome of that cycle. Right now i am still having some issues configuring the site so that it is accessible from outside my network as well as on permissions. I should have it up and running by the next progress report. I have some footage of the site in the developer's vlog though so you will at least get an idea of what it looks like.
Finally I have finally pulled the trigger and downloaded UE4. They now allow free usage of the SDK with a royalty fee only. I also bought several plugins relating to planets, universe generation, and advanced AI. I have some stuff in the developer's vlog on this as well. Alas I was not able to get far enough to get actual example system built to show you but the potential is there for next update.
No audio, website, or infographics work done that can be or is worth showing. What audio work was done was on refurbishing our existing tracks that could not be ported over to the new FLStudio install. There will be some of the audio work on the trailer track using the new EastWest CCC software though.
Ok, time to get down to business. This development cycle was one of innovation on the ideas for some of the features as well as on streamlining the modding process. I have removed Boost from the project files as it was becoming more trouble that it was worth to keep it updated properly. Instead I did what I should have done from the start which is to load all of the settings data through the database. This way all of the information is in one place and it is much easier to handle. The modding tool will still be a thing but it will now be solely for editing the database, I will be chopping off the .ini file editor (even though that was the one I was farthest on D: ). I go over this a bit in the developer's vlog while adding in the difficulty settings as an example of how the system will work. There is another area too, game difficulty settings. You can create any number of difficulties of varying degrees.
Another area where some streamlining/innovation has happened has been in how inter-table requirements are now going to be handled. If you remember, during one of the more recent developer's vlogs I began to talk about how to handle mission requirements and rewards as well as skill effects/requirements. Well this topic hit a fever pitch during this development cycle as I attempted to find a way to shift 'Missiles' away from the weapon category and into their rightful place as ammo. The issue came when trying to figure out how to relate a launcher with a specific type of missile ammo.
These types are: Ultralite, lite, lite standard, advanced lite, standard, standard heavy, medium, heavy, ultra heavy, and titan.
My first approach was to make something really complicated relating to a numbering system based on powers of two (2,4,8,16,32,64, etc) but it quickly became obvious that this was going to add way too much complexity and probably not be possible from a practical standpoint. So I decided on another 'duh' options which again was to use the database. However instead of relying on SQLite's marginally implemented object relations I am using cross reference tables. This can be endlessly expanded upon and require no in-code handling for most things (damage effects are a separate story which I will cover later). Once again, there is an example in the developer's vlog.
As a quick example, say we have Missile Launcher A, Id 1 in a weapons table, which can use Ultralite, Lite, and Lite Standard missiles. To keep things simple let's also say we have Lite Standard Missile B, ID also 1 in the equipment table. In the cross reference table we would have a row to connect Missile Launcher A to Lite Standard Missile B using the IDs for both. It would look something like this:
ID (for the table): 10
WID (weapon table id): 1
EID (equipment table id): 1
And that is all there would be to it. The code will automatically check this cross reference table whenever ammo is being loaded into the launcher to prevent unsupported ammo from being loaded into it. I am using similar tables for a lot of stuff now from skill effects to mission rewards. This was my answer to that question I alluded to earlier about how to handle these kinds of scenarios.
Related to this is another change I have made that will remove any dependency on ranges of ship IDs or weapons IDs in the settings table. This is to fix a long standing problem I have been trying to solve where mods could potentially conflict with each other based on what ID ranges were specified in the settings ini file. Instead, any number and type of items can be added to tables without the need to track these IDs. There are some special instances where this is still not true (starter ships and equipment for example) that I am still working on how to handle.
Some other database changes have been standardizing some of the tables so that they follow a logical design and breaking out the equipment table so that ships, weapons, clones, skills, planetary defenses, and planetary shields no longer reside the that table. This was done for normalization reasons, normalization being how tables are logically structured. This, in turn, created the need to alter quite a few things in the database and data_placeholders classes.
I have removed the coding that was required for Boost program_options and instead have implemented something much more simple in its place to get the data from the database. This will now be a multi-staged process as we have difficulties which will impact the values of some settings and random generations within the game. Some will even impact probabilities.
I have also changed direction on effects. Before I was thinking that we would have something like effect types that would have specific effects coded into the game or through the database; piercing3, for example, which gives extra damage to hull and armor. Instead what I plan to do now is to break out tons of ship, weapon, and equipment attributes out into identifiers, give you operators like add, remove, multiply, divide, and then allow you to enter in values. This way you can add any and many kinds of effects to equipment and skills and this will allow for a lot more customization. This will apply to anything that have effects on other things, so skills, weapons, equipment, and even ammo will be fully configurable in terms of their effects.
That is everything for the coding and innovation for this development cycle. As I do not have anything else to add that I might normally place after this section (infographics, music, etc.) here is the first developer's vlog part. The first part is up but I have been having problems getting the 5th part to render correctly and the second is missing some audio. I will try to get 2-5 up by next weekend.
So that is all that I have for this progress report. I am hoping to get more work done on the audio for next time and also get some early systems built in UE4 to give you a very rough estimation of the look of the game. I will also be trying to get more stuff up on the website as well.
Thanks for following the project, I will see you in July for the next update!
