The Show

The game is finished. We had our Senior Show this weekend. The presentation went off flawlessly and the crowd really seemed to enjoy the game. While there is always something you wish you could add in hindsight, our build was as close to complete as we could have hoped.

After the show it was time for the demos. Our demo was a huge hit. The president of the college was the first to come over and play it. He really seemed to enjoy playing. We also had a couple industry recruiters who were very impressed with the game and our progress. We were easily one of the most popular demos at the event and there wasn't a single person who played that did not enjoy it.

The game also ran beautifully throughout the demo session. There were a couple bugs we were afraid might show up given the difficulty we had getting the controllers to work on the computer earlier in the week, but they never did.

It was a fun ride. Many of the team members have expressed interest in continuing development, myself included, should we be able to. For now, this chapter of Dan Shredder has closed. Hopefully the next will open for it in the near future.

The Home Stretch

It was the last week of development. More polish was necessary and the designers wanted a couple additions added for clarity.

The one problem the game has had for the longest time, is that when using a controller or the arrow keys on a game menu, you only had this tiny dashed border to figure out which button was currently selected. We had previously tried to fix it by making the buttons swap out for a different color version when selected, but it wasn't working. Instead, I made an invisible image next to each button that revealed itself when the button was selected. This worked perfectly and game the game a little more flavor.

I also finally figured out the puzzle of making the video quit out by pressing any key. It was such a simple solution, I was kicking myself for not finding it sooner.

PAX was also this weekend, and while we did not bring the game to PAX many of the members attended the convention, myself included. We ended up putting a build lock on the game before the convention since half the team would not be available over the weekend and our build was due the day after. The whole team did a fantastic job and we are all happy with where the game ended up going into the weekend.

Now We Polish

Feature lock has come and gone and we are entering the final weeks of development. Everyone's main focus is finishing their last tasks and polishing what is already in the game.

Kiosk mode is pretty much done but we have been having some issues getting the video to actually link correctly. We also got a real video now instead of my temporary one. I also ended up finding a couple random bugs while checking over my implemented features.

When the boss battle was added it added sets of notes that would be hit at the same time. In the keyboard controls, this would cause you to either miss one of the notes or over strum. It was an unforeseen problem since we didn't have those notes at the time, but it was a simple enough fix once I found it.

I also discovered a bug in the pause menu, where the kiosk mode timer was not actually stopping when you left the menu. Again, another easy fix but something that would have been game breaking if left in.

The last bug was with the main menu again. My fix for the second main menu accidentally made it impossible to use the guitar to navigate the main menu. I just swapped around how the game dealt with the extra menu and guitar functionality was restored.

Menu Bugs and Kiosk Mode

With controls mostly done, it was time to work on my next feature, kiosk mode. We wanted the game to play a video from the main menu if you idled for too long, and if you idled in a game menu it would return you to the main menu.

The pause menu portion was surprisingly easy. However, I did need to create my own timer system since the one present in Unreal does not run when the game is paused. The tough part was running a video from the main menu. Unreal barely supports videos in 4.10, but there was enough present to make it work to what we needed. By turning a video into a texture and applying that texture to a material, you can create a menu widget with an image displaying the video. Then you play the video's sound file in time with the material. This has it's own host of problems associated with it and getting them synced, but it works most of the time. It's the best in engine option currently available though.

The rest of my time was spent on bug fixes. The game had been plagued by a bug for a long time now, where if you used the guitar and returned to the main menu, choosing the medium difficulty would close the game. It turns out that there was no bug breaking the game, but somehow a second version of the main menu was being created. For some reason the guitar controller was hitting both the difficulty button and the quit button on the second menu, causing the game to close. I removed the second menu, fixing that strange bug. 

Control Success

My keyboard controls from last week were a huge success. We took them to QA testing and they performed very well, with some players preferring that option over the guitar and pad. It also made testing the game significantly easier going forward for the other team members, because now anyone can simply load up the game and use the keyboard instead of having to go to the labs and plug in the guitar and dance pad to test a simple change.

This week I made the toggle system. I had to work through it a bit since the challenge was sending the players choice to the player class from the menu widget. Since the widget is destroyed before the player is even created, I had to create a variable in the game instance that can be edited, tracked, and retrieved from anywhere. This variable is passed into a simple switch statement the turns on and off the different controls. I also added a kill button for easy testing for the team, so they can just kill the enemies they target instead of playing each riff.

Unfortunately, it does not look like keybinds will be possible. Blueprints just do not support that option. It could be done in C++ but we already moved away from that.

My challenge for this week if to make the gamepad controls. They are different from the keyboard controls in that, where the keyboard binding are completely different, the guitar is already considered a gamepad. I need to make sure they not only work separately from the guitar, but that they do not conflict.

Back to Business

After a week long break, the team is back in action and ready to finish up strong in the coming weeks. This week was lighter on work as everyone gets back to normal after our week long break.

I was at a bit of a loss for work this week, so I decided to finally officially tackle a task the team has talked about a lot but never committed to, alternate controls. Starting with keyboard controls, my main goal is to get multiple sets of controls working nicely together and be able to toggle which ones you would like to use. I will continue making bug fixes as well since that is the bulk of what we need to finish in the game as we go into feature lock at the end of next week.

The keyboard controls themselves are pretty simple but also flavorful. 1-5 on the keyboard correspond to the order of the colors on the fret bar. The arrow keys are how you target enemies. There is no button for strumming, simply hitting the correct note will also simulate the strumming on the guitar controller. Having a strum button was just too clunky. Now, the flavorful part of this, is due to the location of the buttons on most keyboards, you can actually pick up your keyboard if possible, and hold it like a guitar to play the game. A nice little touch that matches the nature of our game, but it's not at all required and a player can just play like normal.

Going forward I want to make a toggle system so only one set of controls is active at one time. Then I will look in to making a set of controls for use with a Xbox or Playstation controller. Finally, time permitting I will try to create a keybind system for the player to customize the alternate controls if they don;;t like them.

Bug Fixing Round One

This week was a big change in direction. As I mentioned in my previous post, the team has decided to abandon the C++ port. It was taking too long and we were getting too far behind on the new features. Every one working on it was reassigned, and I moved to bug fixes.

I focused on one main bug, the Skizzard spell disappearing if any enemy was killed in a pack. I was happy to be working in blueprints again, so I started by looking through the enemy ones to find where the state changes happen. Finding the spot, I went through and setup a conditional statement to check if the creature that died was a Skizzard if it's spell was active. As I went to test, I discovered a completely different bug. Sometime earlier in the week a targeting bug had been introduced and it was impossible to actually beat the Skizzard and test the changes. This bug was given to a different team member to fix.

The other bug I looked into was the random game crash. It only seems to happen when playing on medium and restarting after you play through the level once. I looked through the blueprints to see if I could find the culprit, but I'm still not sure what could be causing it. Unfortunately I wasn't able to test any potential fixes because of the Skizzard bug, but looking them over they wouldn't have had the intended effect anyway.

I also looked into adding keyboard controls so I could test the game without needing access to the peripherals. The Guitar portions work as intended, but I didn't get the dance pad controls to work yet. I think it has something to do with the fact that the dance pad is considered player two. I'll have to get it to recognize my keyboard presses somehow or just turn off targeting when the dance pad is not connected.

Change in Direction

This week has been much more productive than those previous. I finally cracked the problem of a function I've been working on the past couple weeks. I stumbled a bit with forward declarations because I've rarely used them in previous projects. I usually just avoid situations were they are needed. I worked my way through it though and came to a working solution.

Then there are the quirks of Unreal. Unreal is not very consistent with how you access member variables, with some being behind a get function while others are just free to call directly. In blueprints these all look the same, further increasing my confusion. Once I figured them out though it was easy to slot all the pieces in where they belong.

I then moved on to the next unclaimed function that needed to be moved over to C++ from blueprints. Using my new found knowledge, this was much easier to go about and I completed it in short order, which the code necessary to expand it's functionality commented out until the necessary class was also moved into C++.

However, after all this was done, we have decided to scrap the C++ re-write. The team realized it would be a constant uphill battle to not only move over the current code base, but also keep up with the new features. It is better for everyone to go forward with what we have, optimize the game in other ways, and stick to blueprints and scripting.

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.