Progress Update #37

 The Organizational Update


    This sprint was focused on making organizational changes to the game. Both on the front-end and the back-end.

Front-End

    The changes here consisted of improvements to the layout of the "Bodies" tab of the overview. The first two came as suggestions from the closed beta.

Copy/Pasting Noise Layers

    With all of the different parameters in a noise layer it can take some time to get exactly the result you want. To mitigate the amount of re-typing values by hand I implemented the ability to copy and paste these values. The overview of the system is essentially that when you hit copy the game will store a reference to that noise layer. When you paste then it will replace the noise layer struct with one created one to one from the copied noise layer.


Duplicating Bodies

    The other suggestion from the beta was to be able to duplicate entire bodies. This would help if the player is making lots of moons or something of the like. It was relatively easy to implement too as I had already had a method for adding a body and all I needed to do was make sure all of the additional settings for the duplicate body got applied.
    To easily copy these properties from the parent body to the duplicate I used a memcpy(). I found this method in a stack overflow thread about a similar issue about copying the variables from one struct to another of the same type. Here's what the whole process looks like in just 3 lines!


Body Systems

    The final front-end change that I made was something I've called "Body Systems". Essentially it just allows the player to better organize the bodies tab. You can group bodies together into a collapsible widget so that if you had a planet with lots of moons they wouldn't all have to take up so much space in the scroll box. I'm not set on the design of the UI but it does work.
    Also, right now you cannot have systems within systems but if there is demand for that feature I may put that in at a later date.


Back-End

Cleaning Up Asset Loading

    The first part of the back-end organization dealt with cleaning up the asset loading when reloading a save file. Nearing the end of the pre open beta crunch I was really stressed and just threw together a quick fix to get it working and now was the time to make that spaghetti more readable. I did this mainly by condensing the nested loops into its own method. There are still more optimizations to be done to make it work faster and more efficiently (looping through every asset each time isn't exactly ideal) but at least now it's readable.

New Terrestrial Planet Generation

    The other bit of the back-end that changed was the way that terrestrial planets generate their terrain. Before they would just generate once at a set resolution and there was no feedback to the player as to if anything had happened except for the CPU fan ramping up until the generation was done. I decided to remedy this by implementing a stepped resolution generation.
The idea behind it being that the planet would first generate at a low resolution (e.g. 16) to quickly show that something had been changed. Then it would generate again at a higher resolution (e.g. 32) and again and again until it got to the desired resolution. This also means that I don't have to make more buttons in the overview mode which is already getting quite crowded. 

Comments

Post a Comment

Popular posts from this blog

Polishing the Foundation

Image
     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...
Read more

Progress Update #13

Image
  Niagara Asteroids in UE4     These past few days I have continued work on asteroids. Only that now I have ditched instanced static meshes in favor of getting my hands on the new-ish Niagara particle system.  Learning Niagara     I have decided that since this is an entirely new subsystem of the engine I would do everything in blueprint first, then transition everything to C++ when I knew it was working reliably. Additionally, because Niagara is still relatively new, the official documentation is sparse if existent at all. So with most tutorials at this time geared towards blueprint implementation, starting in blueprint will give me the highest likelihood of finding a solution to any problems I may come across. The Niagara Workflow     The first thing I learned about Niagara is that the workflow has changed significantly from what cascade was. Where in cascade (to my limited knowledge) you worked in one particle system where e...
Read more

A New Chapter

Image
     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...
Read more