Dissonance Blog Week 14

This is the final weekend to work on the game. The code lock is this Monday, April 24. We may not have completed everything that we wanted to accomplish. But I believe we achieved so much. I have personally learned Unreal Engine and working with the Vive. I am truly grateful to be working on Cosmic Beep. It wasn't always a smooth ride but it was a fun, interesting and educational journey.

Going into this final weekend, we still have one huge bug to try to fix. The bug is that the game crashes when a player touches the radio, cassette or piano. It doesn't always happen, so it is difficult to tell what causes it. The only consistent thing about the crashes is that the player has to spend a long time, 5 - 10 minutes, in the previous level. Then the game has a higher change of crashing. This is confusing because it crashes when the game talks to the API. The three things that make the game crash are special functions that use blueprints to talk to the C++ code. The API shouldn't care how long the player takes in a previous level. Since it only cares about updating the puzzles. The last message in the debug log on the Unreal's crash report is "assert size >= 0". The game crashes when the Puzzle API doesn't initialize the puzzles and the code is trying to access the puzzle list. I'm confused why the game crashes when the game is doing a safety check.

I was contemplating for a while how to fix this or why this was happening. The fix that I put into the API was checking to see if the puzzle list had a last index greater than zero. If it doesn't the blueprint will reinitialize the puzzle manager and puzzles for that level. This technique might work or it could just crash when it tries to initialize the puzzles for a level. If this doesn't fix the game, then I have to rethink what is causing the problem and implement it extremely fast.

After Implementing this technique and testing it multiple times, it works.

Dissonance Blog Week 13

The time left to work on the game is almost over. With the senior show in 2 weeks, we have a lot of work to finish.This week I was working on making everything make sound when they collide with other objects. This is to give the game a more realistic feel when two things collide.

I also was looking into two levels that were crashing on loading. In these levels the execution lines were just messed up. The game was crashing because an array was out of bounce. After fixing these issues I thought the game would be more stable. It is more stable when I tested it without the Vive and never crashed on those levels. But when the game is at QA, it seems to break most often when a tester touches the piano or radio. We have always tried to fix this issue but nothing worked yet.

Some fixes that I will try, when I get a hold of the Vive, are instead of putting the puzzle API in the base level. Since we are using level streaming and the levels are swapped in and out. I will try to put the puzzle API in each level. This way if it isn't found the game won't crash because no puzzles will be inited. The next thing that I want to check is to see if on the puzzle API blueprint the lifespan has been changed from infinity. If these two things don't fix the crashing issue. Then the crash has to do with the actual piano or radio object.

Dissonance Blog Week 12

Three weeks left til the game has to be complete and we have a long way to go. The major issue that we still have is sometimes the puzzles aren't being initialized. This crashes the game when a player then touches the piano or the radio. We think this bug has something to do with the level streaming but we are having trouble fixing it right now. I suggested that instead of putting the puzzle manager blueprint in the default level, put it into each level. It might then always initialize correctly.

This week I was working on the tape recorder and modifying sequence puzzles. In the tape recorder I fixed it so that the tape can't be pulled out of the tape recorder. This was done by just setting the tape to have no collisions. In the sequence puzzles I added an integer identifier so the game can have multiple sequence puzzles in the same level. Only the sequence with the same identifier will update. This will fix any problems with multiple sequence puzzles updating.

Dissonance Blog Week 11

This Saturday, April 1, our game is going to QA. The QA sessions contains the normal time at 5:30, where the testers are students, but also at 10:00 am, where the testers are accepted students. So we made the game as stable as we could. The only things that crash the game are touching the radio and touching the piano but it only happens sometimes.

This week, I was working with the other programmer and we modified a lot of little things in the game. We mostly worked in improving the puzzle API. We changed it so that the designers can specify when a puzzle is complete a message doesn't have to send. Added an early out for when the a touch puzzle is complete to return out, if it is ever updated again. We also changed it so in the Object in Zone puzzles can make all the hidden actors appear when the puzzle is complete. All these little changes just makes the API more flexible for what the designers have in mind.

Dissonance Blog Week 10

Systems lock is coming up fast, Wednesday March 29. The team still has some systems that have to be fleshed out.

These include:
-Hands
    -Drawer Cabinet
    -Breakable Objects
-API Puzzle Logic
   -Sequence - needs to be tested
    -Cassette - needs to be tested
-VCR - needs to be tested
-Phone Calls
-Phone Settings Menu - minor tweaking

I was tasked with making the VCR. The VCR is a type of special collision that checks to see if a tape is interacting with it. If it is, the VCR will play an animation of the tape going into it. Then the player can control to play, stop or eject the tape. When the player plays the tape the material on the television's screen will change to the material stored in the tape blueprint.

Right now most of the major systems are in progress or just need to be tested and tweaked.  If we keep working as fast as we have been these last couple of weeks. The systems lock shouldn't bother us.

Dissonance Blog Week 9

This week was spring break. During spring break, students can either relax or work. I was the latter, I worked at my job, Koby Environmental. Then I came home and either hung out with my family or did personal work. So I didn't get a chance to work on the game at all this week.

So I will just reflect on how the game is coming along. The game has had its shares of troubles, with everything being broken. Right now the only things broken are sequence puzzles in the puzzle API and the lighting. This is still a major improvement than what it was before. Once the sequence puzzle is fixed the puzzle API should be close to complete and the designers can start completing levels as fast as possible. The game right now is behind schedule but soon it should be in an excellent position. The team will make as much as possible in the limited amount of time we have left.

Dissonance Blog Week 8

This week was actually coding the sequence puzzle base code. The way this is implemented is different than the way I said last post. The way that it is programmed now is when a button object is pressed. The button calls a custom function in the blueprints. That function calls updateButtonSequence(int index). In the update function, the index parameter is checked to see if it matches the m_sequenceAnswers[m_sequenceIncrement]. If they don't match then the m_sequenceIncrement becomes 0 and the sequence will reset itself.

This week we also encountered a weird bug in Unreal. In the game, the editor would crash every time a player would touch the radio. In the radio custom blueprint, there were two nodes that wouldn't compile. This is because it connected a FName variable into node that needed a FString. Somehow a conversion node was deleted but the two nodes were still connected. All the programmers had no idea how it happened because the engine shouldn't have allowed it.