Problems and Pause Menus

This week was an interesting one. I was tasked to make a pause menu. So far I had only edited existing menus, not made one from scratch, so it proved to be a fun application of what I had learned. The pause menu itself wasn't too difficult, but the logic to get it working and switch between menus was new ground. I was able to get it in and working as intended, but getting it to return the game to the main menu proved to be much more difficult. Not only that, but my second task interfered with this one, causing myself and my team mates to lose valuable time.

Now, my second task was to move one of the blueprint functions on out fretboard to the C++ class. I picked it up fairly quickly, but ran into trouble finding out how to retrieve the target enemy. After I was pointed into the right direction, I set about making the needed function to use it in the fretboard. It was at this time I was asked to make the pause menu return to the main menu instead of closing the game when you hit the quit button. Not seeing any errors in my build, I commented out the changes just in case and committed the build so I could pull the changes our designers made before changing the pause menu logic. I thought I had it figured out and went to build, only to run into a very vague and useless error message. Somehow during my commit or the merge, I'm still not sure which, this very nasty bug appeared. It completely broke the build for myself and others. We spent a couple hours trying to fix it, each of us who were effected testing where it could have appeared and possible solutions. Kyle was the one to finally figure it out and fix the issue, but by then the damage was done and we all lost a lot of valuable work time. Neither of my tasks were able to be completed for the new build, putting us behind when we are already trying to pull it all together in the C++ classes.

Fortunately there should not be much left to either task, so they can be completed quickly barring unforeseen issues. I'll have to work harder this coming week, and hopefully we will be ready to move onto new content by the end of next week.

UI Shenanigans: Week Three

This week I had a change in focus. Being weak in Unreal I moved to a slightly easier task, changing over to the new UI assets and fixing any bugs that were there. For something so simple however, I had the hardest time just getting the assets in. Turns out I was going it the completely wrong way, so once I was set back on the right path it was easy to get everything in.

Now, in proper Unreal fashion, it couldn't be simply left at that. In Unreal's menu widgets, there is a display option for buttons called hover. When your hovering over a button it will change to a different asset, which we have so you know the button is selected. However, this only works with a mouse, and not the controller. The controller selection is not considered hovering, so another workaround is needed.

To do this, I had to manually change the default image to our selected image and back again when your on another button. This is done in blueprints with a function that breaks apart the button style and rebuilds it using the desired image. However, we ran into another couple problems. The first, and most important bug is that the game completely locks up due to the button constantly switching every frame. We need to either find an event that will rarely be fired, or set it up related to inputs. The other bug, is that it's not actually using the images correctly, and just setting the button back to default values. This is less important though because it doesn't break the game, like the previous bug.

Hopefully next week we will have these bugs squashed. I am also going to start trying to combine some of the separate menu widgets into one.

New Semester, New Game: Week One and Two

An new semester, and a new game. After the end of last semester, unfortunately the game my team was working on wasn't chosen to continue development and we were moved onto other teams. The team I ended up on was Legitimate Studios, and their game is Dan Shredder in Hellzone. It's a game that uses a Guitar Hero controller alongside a DDR Dance Pad to fight and defeat enemies. Fairly innovative and very fun, they chose to make the game in Unreal 4, an engine I had little experience with up until now.

The first week was very low key. We had our first couple official team meetings, where everyone got to meet each other and we began planning what we would need to do within our disciplines. Myself and the the other programmers decided the most important thing to do was to move all the blueprints into C++ classes. Blueprints are significantly slower and use up a lot of resources, so this switch would improve the game's performance by leaps and bounds. We also decided on the various roles each programmer would cover. Dan and Kyle would work on systems, Cody would work mainly on gameplay, and I would fill in where needed with a current focus on the gameplay side.

As I mentioned at the beginning, I had not worked much in Unreal 4 before joining the team. Much of my time these past few weeks has been learning not only about the systems in the project, but also learning how to use Unreal. My current two tasks are focused around the blueprints, which gives me ample time to learn how to use them and how to move the game away from relying solely on them. It hasn't been easy at first, but very rewarding. This is a great first step for myself and the team, and I cant wait to see where our efforts will take us.