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.

Dissonance Blog Week 7

This week was about merging the puzzle API optimized branch and the current branch that everyone is working in. Once the merge was complete. I had to make sure the API was working as intended. This took some time to make sure that the API works with the current build. New issues emerged when the merged happened, the first was changing the variables to work correctly. The second is that in the API branch the main level was level 1. Now in the merged branch the main level is actually level 2. So we had to make sure that the puzzles were inited and updated properly.

I also designed the sequence puzzle outline for the API. In the third level of the game there is a puzzle that the player has to press the correct piano keys, in order, to complete it. So I planned out how to program it using pseudo code.

Dissonance Blog Week 6

Since last week the puzzle API was implemented in the build and two puzzles work. This week was spent on making the other puzzles work in the API. The puzzle that worked were putting a painting on the wall and putting keys into a piano. The ones that weren't working were lighting a fire and turning on the radio. The radio worked as it stood but it wasn't in the API.

The piano and the paint ones are are simple check to see if an object is in a zone. If one of the puzzles worked the other one was most likely to work. The fireplace is checking to see if an actor is activated. In the API it was checking to see if the actor was activated. What it had to do was check to see if the specific blueprint's isActivated variable was true. T accomplice this and to have the API be generic for all cases. I made a base class to hold the variable isActivated, then the specific blueprint inherited from it.

The radio puzzle wasn't put into the API because it was in its own blueprint. So that code has to go into the API. This is a little tricky because the radio has to interact with the players hands. Right now it isn't registering as a collision. This is probably because the API isn't getting the player hands from the tag.

Dissonance Blog Week 5

This week was about testing the puzzle API with the Vive. The lead producer, designer and programmer wanted the API working last week. The API was inside the game but it couldn't be tested because of existing issues in the game. The grabbing mechanic and level loading was not working properly.

Once the hands and level issues were fixed the API was tested. It was initing and updating the puzzles but wasn't calling the collision function. The lead programmer told me to change it so that the API will just check to see if two objects are inside each other. Right now the API is using IsOverlappingActor() to check if two actors are overlapping. Once that was changed, the API was tested and the game crashed. So we have to fix this asap.

We know where it crashes, it crashes when it goes into the function that checks to see if two objects are overlapping. So the reasons that it is crashing is either: IsOverlappingActor() is messing up for some reason, the arrays are going out of bounce, or it's deleting an object that doesn't exist.

//breaks in update somewhere
for( i = mp_start.Num() - 1; i >= 0; --i)
{
    for(int j = 0; j < mp_end.Num(); j++)
    {
    //should break here
        if(mp_end[j]->IsOverlappingActor(mp_start[i]))
        {
            UE_LOG(LogTemp, Warning, TEXT(In collision!\n"));
            if(mp_OtherObject.Num() >0)
            {
                mp_start[i]->SetActorHiddenInGame(true);
                mp_OtherObject[mp_OtherObject.Num() - 1]->SetActorHiddenInGame(false);

                delete mp_start[i];
                
                //actually breaks right here, i could be out of index should be 
                //delete mp_OtherObject[mp_OtherObject.Num() - 1]; 
                //not
                delete mp_OtherObject[i];

                mp_OtherObject.RemoveAt(mp_OtherObject.Num() - 1, 1);
                mp_start.RemoveAt(i, 1);
            }
            else
           {
               delete mp_start[i];
               mp_start.RemoveAt(i, 1);
           }
        }
        //should break abouve here
    }
}

Dissonance Blog Week 4

This week was longer than I hoped. The lead programmer and the lead designer wanted the puzzle API working in the game this Saturday. The API was done, and just needed testing on Wednesday. When we tested the API nothing could be worse.

At first the Code crashed the engine. This was because the game was trying to access an element of an array that didn't exist. This was fixed by keeping the array of puzzles inside the puzzle manager class. Then call the array in the blue prints.

The second issue was the puzzles were never initialized. My lack of Unreal blueprint knowledge caused this mistake. I never connected the execution pins to call the functions. Solving that problem lead to the game crashing. The base puzzle class is type UObject, this is so they can be created during run-time and don't have to have an actor component. In the init functions an iterator is being used to find all the actors with certain tags.

TActorIterator<AActor> actorItr = TActorIterator<AActor>(GetWorld());

I was using this function to search through the game to find all the actors with the tags that were passed in as parameters. Since the puzzle class was an UObject, it doesn't have a world location and will always return null. To work around this. The puzzle manager is passed into the class, the puzzle manager is a AActor. The puzzle class also needed to get the puzzle manager to notify the manager when the puzzle was complete. So it wasn't a waste that the manager was passed into the class.

This week has been filled with problems and hard work. Overcoming these obstacles made me understand Unreal more. I am glad not just because the API is working but because I became a better programmer.

Dissonance Blog Week 3

This week was the first week of working on coding the puzzle API. It was also my first time coding C++ for Unreal Engine. I had an idea of what the puzzle class should contain from the following week. I know now that my class outline was not clear enough. I needed more functions and more variables to make the class more robust.

Once I had an idea about what functions and variables were needed in the class. I had to look up the specific Unreal syntax. Even though the code is in C++, one has to learn the Unreal library just to program. It wasn't difficult to make sure the code builds and that there are no errors. It just takes time to look up how to accomplish the specific task. One task that took a while to figure out was how to detect a collision. Numerous people said to use "OnActorHit.AddDynamic()", but this doesn't exist in Unreal Engine 4.14. I had to find another way. Right now the code is using a delegate, so the code can call the collision function.

During my team's production class this week, the other programmer and myself started combining the puzzle manager and the puzzle class together. I am glad that when we did this the code still gave us zero errors. I am a little worried that the puzzle class won't actually work when the API is used by the designers. Although there is only one way to actually test the puzzle API, through testing.

Dissonance Blog Week 2

This week was the first week of working on the game. The first task I was given was to make a puzzle API. The game dissonance has a puzzle element. The game right now has multiple puzzles but they were all written by the programmer and is spaghetti code. So the API is designed to make all the code well written and so the designers can make all the puzzles not the programmers.
 
The programmers on the team designed the API to be designer friendly, self containing and well written. The API is going to have a puzzle class manager and a puzzle class. I am working on the class while the other programmer is working on the manager. This is the outline for the puzzle class.

Puzzle Class
{
    Datatypes:
        Enums
            PuzzleType - Values: [ Piano/Button Sequence, Object in Zone, Conditional, “Use” Puzzles]
            Button - Char Array, “Answer”, Timeout Condition [ time based, only correct inputs matter ]
            OIZ - “destination” (Puzzle Trigger), Object to be in zone [these are by tag]
            Conditional - reference to the boolean value(s) that must be true
            “Use” - will just take in a call to a generic interface function and execute a referenced function
            Optional - see if the puzzle is optional or not      
            Active Level:

        Other variables:
            Array - Text messages
            Array  - When the message is played
            Bool - is the puzzle solved

    Functions:       
        InitPuzzleDataTypes(); //pass in the puzzletype, maybe pass in all the starting values
        CheckStatusOfPuzzle(); //checks to see if puzzle was started, in the process, or complete
        UseFunction(); // the “Use” function
        Update(); //updates the puzzle
}

Dissonance Blog Week 1

This was the firs week with the new team, Cosmic Tonic, and their game Dissonance. This week was introductory to the game. During this week I finally played the prototype that was created last semester. After playing it, the Unreal project made more sense.

This week the programmers will have a meeting on friday. During this meeting we will go over using Unreal Engine 4 and the code base. The other new programmer and myself have never used Unreal Engine. The lead programmer will also show us the code base and answer any questions.

Saturday will be the first full team work meeting. During this meeting we will go over the most important tasks that must be first.

Senior Game Development Reflective Analysis

This semester has been a hectic 15 weeks. During this time the team made multiple games/prototypes.

 The first game that we started to make was called Fake Out, a reverse stealth game. After a couple weeks, we decided to revisit the idea to make sure it was viable. Sadly it wasn't viable as the idea stood.

Then we switched to make DJ Clone, a rhythm beat-em-up game. We worked hard to make this game the idea that we wanted, but it was morphing into a different game. It started as a beat-em-up game where you fight clones of yourself. If you attacked on the beat the attack did more damage. After working on this idea for a few weeks. We needed more rhythm mechanics. So I worked on some audio feedback and different gameplay mechanics. This included an infinite runner style game where the player had to hit a button. The button they pressed determined what happened. Another one was where beats fly in from all over the screen and the player will have to click the button when the beat is on the collider. After working out these ideas, we came to the conclusion that this game wouldn't have been good enough to go on to next semester.

We switched to our final idea called Robotley Crue, a rail based shooter with rhythm mechanics. We made this game in 5 weeks, but even it went though multiple changes. It stared as a Kinect game using guitar hero controllers. It also had controller support for testing purposes. Then I worked on converting it to Wii guitar hero controllers.  I worked on the enemy AI in this game. The enemies spawned and moved on the beat. The movement kept changing to complement the game style, which kept changing.

Sadly we didn't present to go to next semester. We probably would have been far enough along to present if we started with this idea sooner. Even though we didn't go though to the next semester, I am proud of how many games and game concepts we made in the 15 weeks.

The largest downfall of the team was our lack of communication. We started with a slack team to talk to each other but nobody used it. After about 7 weeks we started to get into the habit of using it. Once that happened the communication problem started to dissipate.  

Since the team didn't go through to next semester, we split up. I am gonna be working on the game Dissonance, a VR escape room game. I am excited to work on this game because it is a new game that I can make and improve. The only downside is that it is in Unreal Engine, a game engine that I do not know yet. It is a little scary being on a team using an engine I don't know, but I will try my hardest to work to my fullest potential.

Senior Game Development Blog Week 11

This is the last week to work on the game. The presentations to continue next semester is on Monday, 11/21. Even though this is the last week we are still going to present to try to challenge into Vertical Slice. Vertical Slice isn't the last stage. The last stage is Final Iteration and Presentation Pitch.

This week I was finishing up everything that wasn't done. I converted the position from the Wii pointer into a UI reticle. Then converted it to have x positions and y positions in screen space. This way the other programmer could rotate the guitars using this UI reticle and his code form before.

I also modified the enemy movement code to be more like what the designer wanted. We had it so that the enemies move in specific patterns in a grid movement. Then we changed it to have specific movement that wasn't a grid movement. Now we are back to the grid movement but the enemies have different patterns than before.

I also fixed a small problem where the music in the level would skip a couple beats when it would go from the intro audio clip to the looping audio clip. I have a script that plays an audio file. Once that audio file is finished it plays another audio script and repeats it. It turned out it wasn't waiting the whole audio clip's length. It was coming in like 1.6 seconds too soon. Now in the code the new audio clip won't play until a certain amount of time has passed, the audio clip's length plus a constant number. I don't know why it was messed up because the script worked on another game. If I were to take a guess. I would say the first audio clip was messed up.

Senior Game Development Blog Week 10

The team has been thinking about trying to use the Wii for the motion controls. So this week I was in charge of trying to get it to work. The Wii sensor bar can be bought with a USB cable. The Wii controller can connect to a computer through a bluetooth dongle. The other programmer found an API so that Unity can interpret Wii controller/sensor input.

Since all it is possible to use the Wii controller/sensor, modifying the code to work using them shouldn't have been difficult. I was wrong. I had a lot of difficulty. First getting the the controller to connect to my pc took longer than I imagined. The software cd that came with the bluetooth dongle actually made the controller not connect.

I took the method of copying code from the API and putting it in the game, then removing all the code that I don't need. I didn't have one line of code, so it wouldn't read any Wii controller inputs. Once I figured that out, everything went smoothly until I worked on the aiming.

In the API the code gives you where the Wii controller is pointing. but it gives it in a Vector2 from 0-1. So I have to find the best way to interpret that into where the guitar will aim. 

Senior Game Development Blog Week 9

We challenged to get out from Deep Dive into the nest stage, Proof of Concept, and passed. Although we have to work hard to make the game feel more like a rhythm game. Our teacher wants the whole world to feel like the beats are pulsating. We need more audio and visual feedback.

So this week I was modifying the enemies, trying to get the Kinect to work better at closer ranges and Audio feedback. The game was too difficult so I modified the enemies. Instead of shooting every two seconds. The enemies will have a 25% chance to shoot every 2-3 seconds. I also was tweaking the Kinect script to try to get it to work better. Since the other programmer did most of the work with the Kinect. I was just reading though the code. Then I would see what I could modify to improve the Kinect reading movement.

The largest tasks that I was doing during the week was improving the music in game and trying to get the enemies to not stack. I added audio feedback for when the player strums offbeat, that wasn't that difficult to implement because I already had code for when they strummed on the beat. I increased the volume of the guitars and fixed a bug where only one guitar would make sound. I also lengthened the time that the guitar would play when the player strummed on the beat.

The enemies stacking has been a problem the whole time I have been working on their movement. The enemies stop 10 units away from the player. So I was trying to fix them overlapping. At first I tried to keep track of all the enemies and just modify the closest they could get to the player. That didn't work. I tried to add in OnTriggerEnter and OnCollisionEnter functions to see when they hit. I would then just place the enemy in the last valid location. It just made the enemies move strangely. I didn't figure out what to do yet, but I will solve this problem.

Senior Game Development Blog Week 8

This week was a big week for the team. We came together and discussed modifying the game from a straight rhythm game to a rail shooter rhythm game. This new game uses a Kinect for aiming and a guitar hero controller for shooting. The object of the game is to shoot the colored enemies with the correctly colored bullets. The player can only shoot on beat and the enemies can only move, spawn and shoot on beat as well. This game started as a side project that the other programmer and myself made in two weeks.

This week we tried hard to try to complete everything so we could challenge deep dive and finally go into the next stage. The team wants to present at the senior show. We have to be in the next stage to request to be in the show.

This week I was working on the enemy AI. I worked on enemy movement and shooting. There are four types of enemies and four different x positions. The closer the enemy gets to the player the closer the enemies x and y converge. When they are as close as they can get to the player, they are touching an form a "wall". This way the enemy actually stays in view so it will be easier for the player hit the enemies.

The four enemies all have different movements. The green enemies move straight at the player. The red enemies move across the row then moves forward and repeat. The yellow ones move diagonal towards the player. The blue ones move two steps forward and one step back.

The enemies shoot every 6 secs. Since this game is two players The enemies aims at the closest player.

Senior Game Development Blog Week 7

The team is still in deep dive, we plan to challenge next week to be in proof of concept. This week we were refining the prototype and getting all the documentations done.

During this week I was working on getting my beat pattern editor working in the game. I had to modify it so that I was saving the local positions. I also had to modify the locations of the beat spawns. This way the beats would be spawned in the right spots so they fall into the correct collider. I wanted to change it, so the local positions are saved to a file not the world position. This way in game it can spawn the beats as child objects. Then I don't have to worry about modifying the positions. I could just load it up as a child object and then it will be in the correct positions by itself.