Progress Update #34

  UI Left, Right, and Center


    This sprint was comprised almost entirely of UI adjustments and improvements. I fixed up the loading screen so it looks and functions smoothly and I tweaked lots of UI elements in-game with a new font and more consistent styling.


Loading Screen

    For the last few sprints I have mentioned a video by Epic Games as my blueprint for making a loading screen based off the action RPG demo. When I tried this approach though I couldn't manage to get the game to build with the extra module. So, a bit defeated by not being able to do something so simple I went looking around the internet for something else.

Approach 1: Plugin

    Pretty quickly I came across the Async Loading Screen plugin. From the outset it looked very promising. It seemed to have lots of customization, did exactly the same thing as the RPG demo, and seemed pretty simple to use. I will say that getting it up and running in my project took literally minutes, but that's about where my praises end.
    To cut a day's worth of work down a bit, there were lots of stability issues (granted this could very well be a result of the source version of the engine as the solution I ended up with also crashes on occasion for no good reason), the way that you can customize it is very clunky, and there isn't as much granular control as I would like. Due to these reasons I went back and gave the action RPG demo another shot.

Approach 2: RPG Demo Module, Round 3

    With a fresh mind, I went beck to trying to get the module to build and within about half an hour I got it. I don't even remember what did it, but I just followed the official documentation on modules and it worked like a charm. It took me a while to learn Unreal's Slate UI but eventually I got the hang of it and made a simple loading screen with a temporary game logo, a throbber to see that the program is still doing something, and even a little gameplay tip at the bottom. And now with direct access to the loading screen code I was also able to set a different loading screen on startup which is currently the built in test widget (created with FLoadingScreenAttributes::NewTestLoadingScreenWidget(), very handy).
    I still faced one last problem though. My loading system works a little different than the usual use case. See, when the level itself is done loading, that is when the terrestrial planets can begin re-generating their meshes. The problem then is that once the level is loaded, any input from the player will remove the widget from the screen and if a player were to do this they would be able to see the planets generating which is not ideal. I flailed around for longer than I'd like to admit trying to solve the problem by trying different ways of disabling input (I did learn about how Unreal handles input though) but to no avail. I then used Advanced Debugging Strategies™ (a.k.a. using a breakpoint and following the call-stack into the engine's source code) to find exactly where the input was being picked up.
    There is a DefaultGameMoviePlayer class that has two methods that get called if any input is detected, OnLoadingScreenMouseButtonDown() and OnLoadingScreenKeyDown(). Both methods redirect to OnAnyDown() which will remove the widget from the screen if the level itself is loaded. So all I had to do to solve the problem was completely gut OnAnyDown() of everything it contained except for the return statement.



UI Changes

    On the roadmap this point was labeled as "Main Menu Face-Lift" but in the end it included changes to basically every widget.
    The main change was a new font. I started out with Renogare because I liked the way it looked in Celeste and just went with it. Eventually I realized that you do need to buy a licence for commercial use and I didn't really see too much benefit. If I was going to localize the game then it would be worthwhile as Renogare comes with support for 27 languages, but I don't plan on it.

    I landed on octarine for the main font and astro for the title font. Because of the font change I then had to go through every widget manually and make sure that everything was still readable. I was also changing most text to be the light variant and most title text to be bold.
    The next improvement I saw necessary to make was UI sounds. I used a few placeholders from Unreal's source folder, just some clicks and clacks for buttons and the like, to give the UI more tactility. Eventually these will be replaced but that will be a problem for future Soren.
    Another goal of mine was to have a homogenous style for the buttons. For regular buttons I settled on using my checkbox filled texture and then switching to the unfilled texture when hovered. For the combo and spin boxes I used a simple black/transparent background with white text. I am currently quite pleased with this aesthetic but am definitely open to suggestions in the future.

    The final change that I needed to make was being able to use the escape key to go back in menus. I noticed that, in most games I play, I will use escape to go back a menu instead of hunting for the back button wherever it might be. However in most of the games that I have made (especially game jam games) I have not implemented this and it's about time I learn to make this quality of life improvement.
    The main problem that I had with getting it to work was getting the widget to consume the input and not let it get to the player controller. The second solution from the second comment in this thread is what I went with. All you have to do is override the on key down function and make the widget focusable and you can handle input directly form the widget. I then used this implementation on the credits screen, the main menu settings screen, the in-game pause screen, and the in-game settings screen.

(Note I'm only using the escape key to go back in the video)


Looking Ahead

    I think that the 1.0 release is going to be coming soon. My very optimistic plan is one month: next week I will do testing & fixes by myself, the next week will be a closed beta, one week for fixes, a one week open beta, then release. I really hope I can hit this by September 6 and it will really depend on how broken I find out the game is in the closed beta. 😬

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