Hello everyone! It feels good to be back on ModDb writing a progress report update for Odyssian Void after a year of keeping quite. First, I want to give a shout out to SpaceX for their successful Falcon Heavy launch. It was truly spectacular to watch and has re-inspired me towards my goal of completing this monster of an idea for a game.
So, let's get down to business. First and fore most it has been a year since our last update and there is a lot to cover. I want to start by linking you to the latest Developer's Vlog (#20) video playlist and also to a new alpha track I am releasing for this update called March of Legends. To briefly talk about that let's move on to the music section.
So, for this update I have one track for you. It is very alpha and still has plenty of issues to resolve relating to timings of the different patterns which will be very noticeable at some points. A lot of it is still not completed either, the end of the track has the most work done on it. This will be used in a specific scene during the campaign.
Developer's VLog 20
For this Developer's VLog I go off into newer territory and showcase mostly not game-centric work but proof of concepts which will be folded into the game proper after completion as well as the recode of the modding tool which we will get into in a bit. Here is the first video of the Dev VLog below:
Modding Support/Modding Tool Changes
So, the biggest thing we have to talk about in this update is a massive and systemic change to the modding system. If you recall I was previously using Boost Options to implement a ini import system for the settings for the game. Well while working on the code earlier in 2017 I decided that it was getting way to complex and cumbersome to continue along that path. The settings ini was getting too large and too complicated and on top of that Boost was not properly building on VS2015/17.
So I decided to chuck that whole system and removed the code for it. In its place there is now a completely database-centric settings system which loads the settings into the game through a map from a settings table and then converts any of the information to the appropriate data types. The upshot of this is that it will be much easier to work with the settings now and not that to rely on comments and documentation so much as you would have had to using the ini file.
It also makes it much easier to consume the data being brought into the settings system because the patterns for linking settings together are not as convoluted as was necessary in the ini file. As a result the previous modding tool also had to be chucked and rebuilt from the ground up. It is also much simpler to use as well as having enhanced feature sets that were not possible in the previous version in terms of editing data in the database and then apply the settings to that data to view outcomes within the modding tool itself without the need to run the game.
Proof of Concepts
As mentioned earlier over the course of 2017 I gravitated away from work on the actual game to develop several proof of concept systems which would then be implemented into the game code when I start recoding 0.6A for the 0.7A version. There are currently two major proof of concepts that I am working on, both are show cased in the Developer's VLog.
The first is going to be a complete universe hierarchy system where systems are created, jump gates are connected, trading regions are developed, trade happens which forms an economy, and random events will happen that will affect the economy in different ways. Some examples are planetary events which may cause a drop in certain resources being traded with other planets, raids on trade lanes, sabotage of production facilities, collapses of corporations, and acquisitions of businesses.
The idea is for this to be a proof of concept of the economic simulation and universe expansion parts of the game and to see how feasible it will be to scale up such a system in terms of memory and processing power. It will also allow me to then refine the code and improve performance before starting to integrate it into the game proper.
Currently the state of this proof of concept is still in the early stages. I have just gotten through coding moon creation which will be talked about later on in the new stuff that is being added. Due to the size this proof of concept turned out to be I then decided to break off the economic part of it into its own proof of concept before implementing it back into it.
Currently the economic proof of concept is somewhat functional although limited. I have yet to test it on a truly random data set and instead created a test mapping of systems which would allow for verifiable results to determine if the code was working as intended or not. However this is what it does currently:
Creates systems within the structure set out in the universe proof of concept, uses condition based checks to create jump gates between the systems creating one of three types of gates (Active, Inactive, and One Way), creates planets for each of the systems, uses the planet information to develop trade regions based on the planet size to determine the number of jumps away that planet can for a trade route, and then processes a basic planetary population simulation using three population segments which consume and/or produce a resource.
So, most of the first part of that list are known quantities and systems I have talked about before in previous updates. Let's start with the trade region system. So, as defined a trade region is just a term referring to the area of the map that a particular planet can form a trade route. Let's use a visual example from the Developer's VLog:
As you can see above we have a map of a collection of systems connected by different types of gates. The system circled in blue is our starting system (System 1) and the planet which we are using to create a trade region is a Type 3 planet which gets 4 jumps for trading. The outline contains every system that this planet can form a trade route with. In the bottom half you can see a few trade routes based on two different starting and ending points. The first goes along with the image above it. The second is for a different trade region which is currently hidden.
So how this works is that we take a system and look at the planets. Each planet will have its own trade region. Trade regions are built from trade routes which have a starting system and a target system. The starting system initiates the trade while the target system is the trading partner. The routes are the paths between these two points and are formed of trade lane parings. Trade lanes are essentially the jump gate connections between the systems.
Trade regions are formed by looking through each system's gates and seeing if they match certain conditions: what type of gate is it, how many jumps into the process are we, and does the system this gate goes to already existing in either the current pathing for this route or existing in the trade region because it has already been processed.
Based on these questions we develop a route system by system. Let's use the 1, 2, 3, 4, 6 route listed in the image as the example. Our starting system is System 1 and the planet at S1 we are using is a Type 3 planet. We have gone through a few iterations of trade region development and now System 6 is our target system. That being established we now brute force our way through each system to try and find a path that leads to S6 from S1.
In the case of the chosen example we start at S1 and look at each gate. Gate S3 is ignored as the gate to System 3 is a one way gate. The gate to S2 is next so we add System 2 to our pathing and then go to System 2. At System 2 we have gates S1, S3, and S4. Gate S1 is already in our pathing as it is the starting system so we ignore that, gate S3 is the next gate so we add System 3 to our pathing and go to that system. The pathing now contains System 1, System 2, and System 3.
At System 3 we have gates to S2, S4, and S5. System 2 is already in our pathing so we ignore it and turn to gate S4. We add System 4 to our pathing and then proceed to that system. At System 4 we have gates S1, S2, S3, S5, and S6. S1, S2, and S3 are all in our pathing so they are ignored. Normally we would then go to System 5 but I am going to skip that for brevity. Once we identify that System 4 has a connection to System 6, that the gate is not inactive or one way, and that we are still within our 4 jump limit we add System 6 to our pathing and then process it into a list of trade lanes: 1-2, 2-3, 3-4, 4-6 which are then processed into a trade route and added to a list of trade routes which is then stored within the trade region.
This process happens over and over until each system has gone through the process and all of the routes to all possible trading partners are completed, forming the trade region.
The other system to discuss is the underlying engine of the economic system; the planetary economic system. This system will eventually use all of the resources within the game along with various objects which will impact the generation of these resources and the consumption of them. This process will generate a supply and demand environment which will then drive what the planet is likely to trade for within a given turn.
Currently only parts of the system have been implemented. First the population management system was constructed but it is still very infantile. It works based off of three population segments: children, adults, and seniors. The adult segment produces the resources through working at buildings (eventually, right now they magically produce them) while the other two are the main consumers of the resources. While there are resources available the population will grow a certain amount each turn until the population reaches 50% over the maximum population for that planet (referenced as planetary equilibrium in the past). Once that happens random values will be generated to speed up the rate of decline within the population as the planet is overtaxed and resources cannot be generated in as large of quantities.
Another scenario which leads to a population decline are famines. Right now they have a random change of happening but in the future as this system becomes more developed various factors will go into how often they occur. When a famine happens a random percentage of resources is lost. If, after the consumption cycle processes, there are no more resources left a significant population crash happens and then the planet slowly recovers over time.
While this is going on an eventual Supply/Demand system will process which resources are in highest demand and try to form trade pacts with planets within its trade region for these resources which will then fuel the larger economy.
Aside from the above stuff there have been other changes and additions which I want to talk about. I will create a section for each of these below.
Combat Experience Leveling System (CELS)
While the CELS is not a new system I have updated it based on wanting to find a more curvy cxp growth pattern for leveling up as you progress through the game. Before I was using a formula which pretty much create an almost static increase in cxp needed per level; there was no curve. So I started looking for other potential possibilities to replace that formula with. In that search I remembered logarithmic functions from my algebra classes and looked into those and found something similar that works pretty well.
Now, instead some monstrosity like this:
To Next Level = (Current Level • 1250.0) • 1000000.0 • Current Level / (((1000.0 • (Current Level • 1250.0)) / 2) / 2.3)
I am using something which is much simpler and can even be modified from the database:
base * (pow(level, factor))
Base is an integer which defines a multiplier for the product produced by the pow function. Level is the player level. Factor is a fraction which represents the power part of the pow function. Both the base and the factor are settings within the settings table for players and separately for enemies in terms of the cxp they generate.
This formula gives a nice cxp requirement curve as you get higher which means to takes longer to level without creating a convoluted mess in the code.
Randomly Generated Enemies
There will now be randomly generated ships which will be allied with pirate organizations. Obviously they may not all be hostile. For example if you are on friendly terms with the pirate organization that owns the ships they won't target you. These will be generated as part of the economic system so that calculations on how dangerous a system is, apart from the sec rating, can be done to determine risk levels for trade lanes.
I mentioned these earlier. Each planet will now have up to four moons of differing classes from 1 to 15. The class of the moon will determine how many and how large the ore deposits on its surface are. These deposits can be mined if you know the right skills have the right equipment. Some of the higher class moons can even be colonized and slightly terraformed.
Settings System/Database Table
As mentioned earlier the settings system has changed to a database only solution. One thing I want to mention about this change is that the wiki has now been integrated into the database descriptions for each option. A field contains a link to a page/section of a settings wiki page on our wiki site which then goes into detail about that specific setting, the defaults for it, and what changing the setting might do in game given some example values.
While I was working on the universe proof of concept I began to think about lower sec areas and that in relation to the ores currently in the database. I decided that I wanted to add some complication into the ore system because it was just too simplistic to create new stages each time some new kind of ore was required for a lower sec system.
From that idea came the tier system. Ore tiers are kind of like stages but they introduce more complex ores which can contain much more of a resource or even multiple resources. This will also allow for another new idea to be easier to manage which we will cover next. In order to facilitate this change a new table was created as well as a new cross reference table to link that and the existing resources table together for the multi-resource ores.
I am not going to call it a crafting system because that sounds too simplistic to me for what this system will be. How it will work is that we will have components which will be fabricated from base resources and other components until you reach a stage where you have a usable part. So, for example, regenerative armor.
In order to create this, if you don't want to buy it, you will need the materials to create the armor plating which will go on your ship. You will then need to create the technological components which are molded into the armor to provide power conduits throughout so that small replication devices can receive power in order to repair the armor. In this scenario you may have 10 to 15 components to create for the stage 1 blueprint and another 5 to 8 for the completed blueprint.
You could then take these blueprints and either try and sell them to a manufacturer or use them yourself to fabricate the regen armor either for your own use or as a product that you could sell.
While most of this system is non-existent currently I am laying the grounds works in the database to support it when I do eventually get around to coding it.
Station Shop Menu Filtering
As part of the next stage of development for shop menus on stations the items being displayed for purchase will be able to be filtered by a number of options. Currently the code to allow this does exist on the database handling side but the station menus have not been updated to take advantage of this code yet as it still need testing and further development.
For the last bit in this update I wanted to discuss changes to the modding tool in more details. As mentioned before, the old version of the tool has been deleted as it is no longer compatible with the settings system and had to be re made. Currently the tool allows you to do everything you would need to when creating new stuff for a mod or even for me while I am creating new stuff for the database.
There are three main tools completed currently: the data query tool, the advanced query tool, and the database editor tool. The first tool, the data query tool, allows you to execute simple query commands to locate different information within the database or to view subsets of data to develop newer items. Right now you still have to know a bit about writing sql queries to use it but in future versions I plan to implement a few controls which will allow you to just click on them to drop in different commands and allow the use of a field list to add and remove fields from the query.
The advanced query tool (AQT) is for using joins and unions to get complex data structures from within the database. This tool would be used for testing cross reference table entries, looking up information between multiple related tables, and all of that jazz. An example of that is in the Developer's VLog I think or it may be in the live VLog I did on our main channel in late Jan.
The database editor tool (DET) is used to modify the data within the database. It has two modes, editing and creation mode. In creation mode you are creating new records to place into the database while editing mode is for editing existing data. It is a bit clunky and messy as there are about 30 text boxes which store the data and are always displayed though sometimes disabled when there is no data expected for them. In future version these fields will be hidden and maybe even rearranged so that other hidden elements are not taking up screen space.
The last feature of the tool which is not yet completed is the Futurecast tool. What this tool will allow you to do is to preview some types of changes within the tool so you can get a general idea of the impact those changes will have on the game without actually having to play test those changes. For example, let's say you change the base cxp value for players upward and you want to know how much of an impact it has on how quickly players will be able to level up. You would open the Futurecast Tool, select the type of Futurecast you wanted to execute (in this case player cxp growth), select if you want to use the settings values or custom values, select a subset of enemy ships to use in the calculations and then simulate the player leveling up over time fighting the enemies you chose.
After it will catalog the data and display it in one of several possible forms you could choose form (Ie a spreadsheet, a line graph, a bar chart, etc.). The idea for this tool is to make modding not require the normal play testing to determine how the changes or additional items impact the game which in turn allows you to turn around the mod faster and deal with balance issues without having to really open the game.
Again, everything except for Futurecast is functional in the Mod Tool and in fact I use it when I am creating new data for the game rather than using a text editor or creating it within SQLite Expert.
Well that is everything I can remember having working on for the last year. I am sure there are more things I may have forgotten though. If you want to go digging to see if I missed anything check out the GitHub project pages for the game and the universe poc here: Our GitHub Profile
I wanted to try and get some UI stuff done in UE4 but ran into problems with the initial version of the mock-up UI. I will have something for that for the next progress report update though. That will happen in Jan of next year as I am moving to a yearly update schedule for now to give enough time for enough work to be done for truly substantive updates like this one.
Thanks for following the project!