Progress Update #32

Multithreading Round 2


    My main goal this sprint was to get a smoother and more readable save and load process. Before this week I had random variables in the game mode that would track the loading and first time generation of planets. This made the code very hard to understand and was in dire need of a rewrite.


Loading the Game

    I started with the loading side of things as the save function only took a few milliseconds and didn't need as much help as the loading side of things did. My goal here included a few key parts:
  • The load function takes place on a different thread so that the animation of the load screen stays fluid.
  • At certain points, the load function should increment an enum as to give a sign of progress.
  • Have all terrestrial planets generated before removing the loading widget from the screen.
  • Make sure that all data is still being applied correctly.
    To put the load function on a different thread I tried the same method as the terrain face generation, that is to use AsyncTask() on any thread and call back to the game thread when done. When I tried this though I noticed that much of the functionality of the load function (e.g. spawning an actor, creating an asset, changing an actor's transform, etc.) would actually need to be run on the game thread otherwise it would crash. For this I tried to do multiple callbacks but it didn't have the effect I wanted. When I tried the async task on "any thread" it would execute the load but would also freeze the game thread and thus the animation would stop, and the load progress would not be updated. Until the thread finished and the load widget would unceremoniously disappear.
    I tried again on the "local queue" thread, that let the animation keep playing and the game thread kept ticking, but the code was never being run. I set breakpoints and everything I could think of and the load function was not being executed.
    After two days of this I finally threw in the towel on that approach as the sprint wasn't slowing down. I found an article from Ben UI showing the use of a class called FRunnable (I also found a video showing the same thing). In theory this is supposed to pop open an new thread, run some code, and stop when asked or the task is finished. I say "in theory" because it just didn't want to work with me. No matter what I tried I could not get it to play nice. Sometimes it crashed, sometimes it would get stuck, and sometimes it didn't even run at all.
    At some point I realized that it was going to have the same problem as the first attempt with calling back to the game thread and all that. It was here that I put bullet point 2 on the back burner once again and moved on out of necessity. I could do some very minor async work by calling Save/LoadFromSlotAsync() instead of Save/LoadFromSlot(). This keeps all the big calculations and memory reads on the main thread and only offloads the read/write to file to a different thread which in the end is barely noticeable :/
    Moving on to bullet point 3. I had a solution for this already but, as I mentioned, it was on the verge of unreadable. I cleaned it up by offloading all that code to a separate namespace. Although still in the same files, it is way easier to understand. The generation of the terrestrial planets is the last stage of loading, and when that is reached what will happen is as follows:
  1. A planet's OnPlanetGenerated delegate is assigned to function NewGeneratedPlanet().
  2. That Planet is generated.
  3. When generation is finished, NewGeneratedPlanet() checks if all planets have been generated.
  4. If all planets are ready to go, the game is unpaused.
  5. Otherwise another planet will be generated.
    That's basically it. This week was a lot of learning and trial & error. I am not quite satisfied with the state of saving/loading and so I am now a day behind schedule as I did not get a chance to do a UI facelift as I had planned to. I have also found a video by Unreal on async loading screens so I may give it a try but no promises.

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