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.