Corona-cation (Day 23)

Refactoring... yay


    Today I felt the full impact of all my impromptu decisions during the jam. Every, "oh, this'll do for now" had to be cleaned up and thoughtfully reworked. The majority of it had to do with the communication between buttons and the objects they activate. I had originally planned for there to be one or maybe two plate/button per stair/door. I was very wrong.
    Today I was sent a screenshot of a prototype for level 6, and well, it speaks for itself...
Credit: Destin LeClear
    It became apparent I had to prepare for multiple buttons per object. I thought that it would do nicely if I had an array of buttons that could activate a door or something. Then I realized that to do that I would need to rework the activation/deactivation system, but then I would also need to be able to generalize activation objects, and I'm sure you can see where this is going. 
    I settled on the following system. One parent class for buttons (the things that do the activating) and one for doors, stairs, etc. (the things that get activated). This way I could see base activation stats that were universal to any object without having to copy/paste the same code every time. It also allowed me to change the activation/deactivation system from earlier. 
    The reason it had to change was that for example: if a door was closed and two buttons were able to open it, if both were on but one turned off the door would close. Basically the activated object would go with the most recent command. What I wanted though was for the open state to take priority. This was now easier with the new system as I could just get the activation state of every object and as long as one is on then it will not close. 
    This refactor did mean that I had to go through all the current levels replacing object references, but I'm glad I did it now and not later. 

    I also fixed a smaller bug that had to do with the pressure plates, similar to the one described above. The problem was that if you put a box on a plate (activating the plate) but then stepped on and off the plate yourself it would deactivate the plate; because again it would respond to the most recent command. This was solved in a similar way in having an array of objects that are on the plate so only when the array has no entries will it turn off. 

    Last fix had to do with the box-fly bug I thought I had solved yesterday. I found a way to break it again. It was slightly harder than the original box-fly but it was still possible. I fixed it (for now) by replacing the check if the player is looking down to a check seeing if the box is below the player, then it will force the player to drop the box.

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