I have made some changes to the inventory system to allow for easier crafting of small items.
When accessing the active inventory when a crafting item is in the world, the crafting dummy will now be visible in the active inventory and can be interacted with directly.
The active inventory is the inventory that exists in the world, and allows the player to move and select actual gameobjects. The GUI is only used to display items and move them between the active inventory and the bulk inventory.
This solution does work, but it is still quite clunky, and I will need to do a larger rewrite here in the future.
I have added some new harvestable resources and items to the world, which I intend to use to test and improve the crafting and inventory systems.
These items were added to the world with relatively little difficulty.
I have also tested and improved the rotation and movement of the items in the world. There were several bugs that caused strange behaviour when moving and rotating items, especially large items, these have now been fixed.
The next step is to optimise the crafting system and add better options to craft smaller items.
I have been focusing on debugging and improving the crafting and inventory system.
This system is very complex, and needs a lot of refactoring.
In particular, I need to add a better way to craft small items either in the inventory or in the world.
Currently, this is done by creating a dummy item on the ground, and combining other items with it to form the finished item.
This is fine for large world objects, but it can be difficult to interact with small items like this.
I don’t want to add a solely gui based approach, since this would hurt realism, so I plan to try to add some kind of immersive crafting system that works better for small items.
I have made some client and server improvements to the Login system.
It is now possible for the user to have multiple characters stored on the server, and by using a different username for each, the user can select which one they want to play as.
The save/load system in the game does not allow for multiple saves per character, this is by design (I do not want players to be able to save before a major decision, and load again if they don’t like the results, this harms immersion).
However, I do want players to be able to experience the world in different ways, with different characters, possible at the same time, this is now supported.
The client variables (inventory, etc) still only support one character, I will need to optimise this in future, but the server side support works great.
I have also made changes to the database to improve security, which is an important step before release.
I have fixed another, more minor, optimisation issue, which I again identified using the unity profiler, and I have made other significant optimisations to performance.
The framerate is now substantially higher.
During testing, the framerate, even in a debug build, it usually capped at the target framerate, which is currently 80 in my build.
It sometimes drops below this if geometry is being loaded in, etc, but the lowest framerate I saw was over 60 FPS, which is excellent.
This is, however, running at 1080P in a window.
Running a release build at 4K in a fullscreen window (not exclusive fullscreen) resulted in an average framerate of 40-50, and a minimum framerate which was over 30.
I think this is, again, excellent, since it means that users can either choose 1080P at over 60 FPS (For those who prefer framerate to resolution) or 4K at around 40-50 FPS (average) for those who prefer resolution over framerate.
While these numbers are coming from a build running on a very powerful system (AMD 5950x, nVIDIA 3090, 128 GBs RAM), they are “worst case” numbers, with all graphics options maxed, all post-processing effects enabled, and while rendering the most complex scenes in the game.
For less powerful systems, it would be possible to significantly improve performance by making even very slight changes to the graphics settings (Grass rendering, in particular).
The game allows extensive changes to be made to the graphics settings, so users can customise it to their hardware, or even for future hardware, as it becomes available.
I have made some minor improvements to the item placement system, as well as some other minor improvements and bug fixes.
However, the most important improvement that I made was when I discovered a serious bug in the ground cover paging system.
The system works by finding nearby terrain chunks and rendering any ground cover objects on those chunks, and hiding any ground cover objects not on those chunks.
This system was always quite slow, but I assumed that this was due to the large number of ground cover objects that are being rendered (I am not using instancedmeshes yet, this is an optimisation that I will add later).
However, while improving this system using the profiler, I noticed that the distance to each terrain chunk was always 0.
It turned out that there was a simple bug that was resulting in every single terrain chunk being scanned, instead of just the neighbouring ones.
I was not rendering any more objects than necessary, since I had another check in the code for this, but by searching all chunks instead of just neighbouring ones I was effectively searching through tens of thousands more objects than needed.
This problem was solved relatively easily, once I figured out what was causing it, and the performance of the project has increased massively as a result.
I have solved most of the remaining issues with the traffic system.
I have found some problems related to paging the cities in and out, but these were preexisting.
There is an also an issue with the AI spawning in the wrong location that I need to fix, and I need to do some more testing on the mechanics of the system, but it is mostly done.
The only work remaining is to add the placeholder art and some final, last-minute, improvements.
The idea that I had to solve the direction of travel problem seems to work, but it was more complex that I thought.
Searching for the nearest intersection node in the grid was quite complex, especially when I needed to make sure that it was an intersection with no obstructions (such as buildings, etc) in between.
I was eventually able to solve this, but there were still other minor issues relating to collisions between vehicles, etc.
I also had to add a solution for a situation where the AI could no longer travel in any direction. To resolve this case, I simply had the AI change lanes if there was no path possible on their current lane.
This solution now works reasonably well.
There are still some minor issues to fix, and I still need to add some simple placeholder art, but the main work on this seems to be done.
I can now generate all of the required graphs for the vehicles, and it can be done without any noticeable performance impacts.
The next goal is to get the AI vehicles to travel around the graph to random points without colliding.
I tried a few solutions to this problem, but none have worked yet.
The main problem is that the A* graph system does not respect direction, so the AI vehicles can travel in both direction on the same “lane”, which causes them to collide with the vehicles behind them.
The next solution that I am about to try is to allow the AI to only travel in two directions, forward, and either right or left depending on which lane the AI is in. Then, I can search for the nearest intersection node on the graph that is in that direction, and move toward that.
