Progress Update #26

 Alpha Bug Fixing


    This week I have polishing the alpha. This includes multiple bug fixes, some small new features, and some automation with getting builds of the game uploaded to itch.io.


Bug Fixes:

   UI Bugs 

    Most of the bug fixes came in 0.1.3 and had to do with the celestial mode UI. The first of which was an issue that has persisted since the celestial planet highlight was first introduced. The issue in question happened when the focused planet went out of view and the highlight would position itself at 0, 0 on the main canvas. This was fixed simply by reading the return value of the ProjectWorldLocationToWidgetPosition function and if the position wasn't within the player's viewport then the widget is hidden. 
    The next problem I set out to fix had to do with the curve of the HUD. Because the celestial planet highlight also had this curve applied to it, the further it was from the center of the screen the less accurate the positioning became. My temporary fix for this was to remove the material effect from the widget. I could theoretically reverse the math done in the material to correct the position, but I thought that it really wasn't worth the effort for the minor effect that would be applied. Additionally, without the effect the text was easier to read, thus I rationalized my decision to remove the effect at least temporarily. 
    The next bug came as a result of the previous fix. In order to remove the effect from the highlight widget I had to make it a child of a different canvas panel. But because of this, it now wasn't hiding when switching from celestial to overview mode. Fixing this involved showing/hiding the master canvas instead of a child canvas.
    The final UI bug to fix was multiple celestial highlights being created. This was happening because the highlight widget was being created on construct of the celestial HUD which also happened every time the player switched from overview mode to celestial. A simple DoOnce node fixed this but in the future I would like to find a better solution.

    Niagara Fix

    I also finally got around to fixing the Niagara systems. The first fix came in increasing the size of the fixed bounds so that the asteroid systems wouldn't disappear right in front of the players eyes. 
    The second fix was pausing the systems in overview mode. This was pretty simple, I just had to get all actors of class ANiagaraActor, get their Niagara component, and set paused to true. This one fix surprisingly makes the overview mode feel way more real and overall more polished.

    Fixing Build Warnings

    When I packaged the game I noticed some there were some warnings in the output log. I prefer to have nothing but messages in the output log so I set out to fix them.
    The first three of the four warnings I got were to do with plugins that I have installed. The warning read: "LogPluginManager:Warning: Engine version string in [PluginFilePath].uplugin could not be parsed ("[SourceEngineVersion]")". I managed to get the warning to disappear as per this thread that suggested changing "EngineVersion" to "EngineAssociation" in the plugin file.
    With three of the four warnings resolved I moved on to the last which was complaining about not being able to find a file. The warning said that there should be a file called ICelestialObject (my celestial object interface) in the blueprints folder but that it couldn't be found. I didn't know why this was happening as I had never had a file like that in the blueprints directory, but whatever I created the file it wanted. The next time I tried packaging though it threw another warning that the file wasn't a child class of tutorial. What??? No clue what happened here but when I created a tutorial blueprint with the name ICelestialObject in the blueprints directory the warning was finally resolved. 


New Features:

    Moving Celestial Bodies

    I have wanted to be able to move planets at runtime for a while now and I finally got around to doing it. My initial idea was to have a mesh with three axes (like the one in the Unreal editor) that you could drag around and position a planet with precision in a 3D space. However this idea was too involved for me to attempt at the moment with the two biggest hurdles being getting the mesh and finding which axis the player is clicking on. I fully intend on pursuing this method in the future, but for the time being I needed a quicker implementation.
    The quick fix that I came up with was to basically override the panning input of the overview pawn. Essentially I would have a toggle button that, when enabled, would switch the panning input from panning the overview camera to panning the selected celestial body. A nice side effect of this approach is that you can move multiple bodies at once if you want to keep their same relative positions. 
    Here's a demonstration:

    In-game Orbit Debug Editing

    Another thing that I want to be editable at runtime is the orbit display. As you saw in the video demonstration, the orbit visualizer already updates in real time with updates to planet locations. However up until now, the length of the visualizations and other settings were unable to be changed while in-game. 
    My solution to this is similar to the info panels of the planets. I would have a widget that when spin boxes are updated, so too would the orbits. The only difference is that currently the only way to get access to this widget is through a console command.
    Here's what that looks like:

 Saving the Game

    Saving is a feature that is quite vital, but for one reason or another I have put it off until now. The bright side of this is that Unreal makes it quite easy to implement. The hardest part is just specifying all the properties that I want to save inside the save game class. Currently I only have saved the positions and velocities of celestial bodies, as well as position, velocity, rotation, and throttle of the celestial player. I will also want to save other properties about actors like the overview player, orbit visualizer, and possibly even asteroids. 
    As I write this, command for saving the game are only available through the console, but this too will change with time. 


itch.io Publishing Automation:

    While making the itch.io page for the game, I noticed under the upload section a little paragraph about an automation tool called butler. So this week I spent some time looking into how I could automate the process of building and publishing the game. 
    Looking through the documentation and looking at a tutorial I was able to automate the process of zipping up a build of the game and publishing it to itch. This is done through a batch file that I will walk through right here:


    Starting at line 5 we set the directory of the most recent build. Line 6 is the username of the account to which the game is published, slash the game name, colon any tags (in my case this is a windows build so the tag is win). Line 12 we use 7-zip to zip up the project into a file SpaceGame.zip. Line 16 is the actual butler command: we are pushing the zipped up project (%pathToBuild%\SpaceGame.zip) to the game page (%butlerName%) with the version number stored in the file GAME_BUILD.txt. 
    To get the game version to work I had to make some adjustments to the Target.cs file so that GAME_BUILD.txt would store the entire game version string not just the build number. 
    In the future I would like to automate the build process as well so that I can build the project from Unreal and once it's done building it will automatically push to itch.io. This probably isn't too hard; I'll just have to look into it more.


The current (very unfinished) game page is available at: https://setg2002.itch.io/space-game?secret=aLViVqrE6f7dLYB6FRFMQ7Pddgo

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