This week was another of incremental progress on Mini Solar System. There's still lots that I'm doing in my personal life which means I don't have nearly the time I would like to dedicate to MSS, though I did complete some tasks that needed to be done.
Organization & File Structure
The largest one of these tasks was to organize the file structure in the /Source directory. When I came back to the project one of the first things I noticed was that all the source files were just sitting in /Private or /Public and there were no subdirectories. This is in stark contrast to the other projects I have worked on in the past couple years where source files are organized and grouped by their use. For example all single use game related classes like game-mode, game state, game instance, save game, were all in a /Game directory. Player pawns and controllers would go in /Player, and so on. I grouped together classes related to the color generation as well as ones related to shape generation. I did notice while going through all these files that there were some types that did not need to be their own file.
The most egregious example of this currently is EFilterType.h which defines a single enum for shape generation with two values. What I think would be right in this case is to make a file specifically for type definitions, like ShapeTypes.h, and put all the related enums, structs, data asset types, etc. in there so that the single header can be included wherever the types need to be defined. I would then probably do the same for Color Types and Celestial Body Types. This way the file structure can be made concise and anyone looking through the project is not bouncing around through a dozen different files.
Asteroids
The most development I got to do this week was with the asteroids in the game. When I came back to the project and was testing getting the editor working, I noticed that player defined asteroid belts weren't being saved or reloaded at all! And there was no comment or TODO that would indicate that it was planned, what an oversight from past me. Recollecting my experiences with the asteroids I assumed it would be more involved of a process. This was because I was using Niagara particles for the asteroids and, at the time, Niagara was a beta feature for the engine. This meant that core functionality, like getting the value of a user variable in a Niagara system, was not implemented yet. Luckily for current me Niagara has had the last five years to mature into an extraordinarily robust particle system. Getting the asteroid belts to save and load then was as simple as getting all the data from every particle system in the scene (which I did last week) and packaging it into a struct that could be used to create an identical emitter when loading the scene.
In this process I saw how much the Niagara system has progressed. There are emitter modules that I was using that have now been deprecated, and there seem to be more tabs in the editor. I would love to go through and really dig deep into what the modern Niagara is capable of. I will probably do so for the planet orbit debug which is a ribbon based Niagara system. I don't know if I will continue to use Niagara for the asteroids in the long term. Only because I want to explore other ways of performantly instancing static meshes that I can have a little more manual control over than what Niagara gives out of the box. This is definitely more of a long term idea as I'm sure the talented engineers at Epic have streamlined Niagara to the best of their ability, but I would like a more true asteroid simulation.
Right now the gravitational force is not actually simulated for the asteroids and so they simply orbit the world origin. I'd like to somehow calculate the gravity for individual asteroids and allow them to crash into things and get destroyed while still remaining performant. But I don't know yet how to do that, so food for thought.
Comments
Post a Comment