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.