Progress Update #35

 The Pre-Beta Crunch


    This week's sprint was entirely consumed by bug fixes before the closed beta. I did a little testing over the weekend and gathered a list of changes that I felt were obvious and would be easily spotted by testers. It contained mostly aesthetic improvements but also some bug fixes and even a few crashes. I started off strong but the 80/20 rule quickly caught up to me.


Day 1

    Like I said, the sprint started with me taking care of the lowest hanging fruit. This was mainly UI tweaks; buttons not having correct styling, fonts not being applied, names not displaying correctly, and widgets blending in with the background, etc. I did also take care of some more major things like the planet collision formula, a crash that would happen because of an uninitialized a struct, and quitting to the main menu prompting the player to save before it does so.

Day 2

    Still going strong, I fixed some things that really should have been done earlier, mainly "the naming problem". "The naming problem" was that when naming a planet, if you wanted the name to have a 'p', even while typing in the editable text box hitting 'p' would execute switching perspectives. I fixed this by changing the input mode of the player controller to "UI Only" while typing, and changing back to "Game and UI" when the text was committed.
    Another feature that was long overdue was the ability to more finely control the velocity of bodies in the system or get them to orbit other bodies. I already had all the functionality to do this, it was just a matter of making a UI to interface with it.
    The last big feature that I didn't even realize was missing until I started testing was the ability to add and remove biomes from terrestrial planets. This was a similar story as the orbits as I already had AddBiome() and RemoveBiome() methods, there was just no way up until now to actually call them.
    Other than that, I took care of some more miscellaneous fixes and minor improvements.

Day 3

    This is where the 80/20 rule came and knocked me on my ass and progress slowed down greatly. I realized that things weren't saving and loading correctly. You could make all the changes you want, adding planets, deleting old ones, changing the smallest detail of a planet until your solar system was perfect, but it wouldn't matter because once you reloaded the game 90% of the changes would be gone.     The main problem here was that any settings assets that you had created at runtime would not be reapplied when the game was reloaded.
    The crux of the issue was that the settings assets are referenced by pointers to the planets, and pointers can't be saved because the instance of that settings asset is destroyed when the level is changed or the game is closed. With time running out and having consulted many a forum, I devised an ID system.
    The idea is that if I can't save a pointer, I can instead save a uint32 that is unique to that instance. When a planet is created, it is given an ID which is then tracked by any settings assets that it references. So then when everything is reloaded you just match up the IDs and in theory everything is back to the same state it was in. It does work, but at the cost of having a metric shitload of nested loops in the LoadGame() method in order to find all of the correct assets to apply to each other. With this fixed (spoiler alert: it wasn't fixed) I was able to move on.

Day 4

    Ok I lied. The ID system was not yet complete as the entirety of day 3 was spent getting a proof of concept working on just a single asset. So I spent the start of day 4 making an interface for the ID system and making sure it worked for all asset types (oop and all that).
    Once that was done I fixed a major bug where renaming a planet would result in duplicate planets when reloading the game. This was achieved with more for loops in LoadGame(), yay!
    I also got around to making the colors of orbits consistent between game sessions and even when planets were added/removed. I was actually able to hijack the ID system to do this; although it's wildly inefficient and could end up being a problem in the future.
    About halfway through day 4 I realized that the loading of IDs had not fully solved the problem from day 3 in one edge-case. This being assets that are saved to disc (a.k.a. settings assets that were made in the editor and are shipped with the game). The problem here was that with runtime generated assets, their instances are deleted and entirely lost when the level changes, but with on disc assets all of their properties get reset. So with runtime assets I just create a new instance on level load and I'm done. With on disc assets though I have to use the asset registry to find the assets, then apply their settings, then apply them to the correct planets.
    What I am trying to get across here is that I had to essentially make two different versions of saving and loading for runtime and disc assets. This was a major headache that carried into day 5 and were I to make it again I would do it so there is only one.

Day 5

    To cut a very long story short, I kept running into bugs with the saving and loading system. As a band-aid fix for now I have done two things:
  1. You can no longer delete or rename noise layers from editor created planets (though you can still edit their properties and that will save, or delete the planet entirely if you don't want it).
  2. When adding a noise layer to a planet you can no longer use pre-existing layers and instead it will create a new one for that planet.
    Band-aid 1 is really a shame because it separates what the player can do with planets that I have made in the editor and ones that they make while playing. Band-aid 2 on the other hand might just be a blessing in disguise. Having the ability to use settings assets on multiple planets might have just been overcomplicated and unnecessary. Moving on without it would mean I could simplify the ID system quite a bit but we'll see.


The Closed Beta

    There are two more last minute logistics I have to take care of before the beta commences; making sure that download keys and the method I have planned for bug reporting will work. With that said, the next progress update will be my usual progress on the game as well as a post-mortem on the beta itself. 

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