The Grid Tool

Before fully immersing myself in the project, I decided after careful study, to create a tool within unreal with the aim of simplifying as much as possible the creation of the game grid and the objects to spawn on it (giving full control to the designers thanks to the documentation of how to use and modify it).

The tool is also based in such a way that new objects to be spawned on the grid can be implemented in the future without having to disrupt all the logic behind it (adding a new object to be spawned from the tool takes about a minute).

Within the tool, artists will be able to choose which mesh and which orientation to apply to each individual object that will be generated in the grid, so as to avoid the random generation of several identical objects.

Thanks to the tool, implementing a new level takes less than two minutes. 

Inheritance Logic

After the creation of the tool, thanks to the updated GDD documentation, I carried out a study that would determine the future creation of all game mechanics.

I was able to determine that within our project there would be five generic fathers who would help me and simplify the creation of all the mechanics.

What are these objects?

Generic Father

In the generic father, I went to insert logic or even small events that would be needed in all the mechanizations

Movable Father

Inside this parent, we find everything basic that the object needs in order to move within the grid, including verifications.

Not Movable Can Be Activated Father

Inside this parent, we find the basic information for non-moveable objects that have activation and deactivation logic.

Movable Activable Father

This father is the union of two logical fathers seen earlier, the moveable object with the ability to be enabled and disabled.

Not Movable Father

Inside this parent, we find practically nothing, except some verification methods for mesh change or transform.

Why did I use component blueprints and not interfaces?
At first, I thought that using blueprint components would give me more control over what I wanted to do, but after months I realized that in this case, it would be more appropriate to use interfaces, so that I could optimize the design more while also saving some unnecessary verification.

Mechanics
I will now introduce three mechanics, where each one has inherited from a different father (into the game there are thirteen mechanics).

What logic is applied? How does it work with all mechanics?
Questions
The main problem I have is, how do I make sure that each mechanism, once the button is pressed, returns to it's previous state? How can I undo the changes I have just made? Duplicate objects ? The objects on the conveyor belt ?

Answers
Initially, I had tried to save a variable inside each object that would keep track of every change to it, initially it even made sense until the problem arose that once the player made a move and came right back, this led to problems within the level, e.g. the object kept going on the conveyor belt, the duplicate object was not destroyed, the lasers no longer activated once they were switched off, etc.

After several days of trial and error I arrived at the solution, which was that within the scene, every object and every change is only made if the player performs the action of moving, so I thought I would save the state of the level every time the player moves and then once I press the back button one move, I go and change all the cells with the previously saved state, reference and position. 

This solution saved me a lot of time in the checks to be made in the mechanics because the Command Manager calls up the rewind moves method within the generic parent, where it goes to check in its HistoryCell variable which cell it was previously in, so as to make the checks where they are needed.

Narrative Tool  (Data Table)

This very simple tool was created to enable the narrative designer to quickly and easily implement the dialogues that will appear at a given level.

Within the data table we would have the opportunity to change the name, sprite and context for each dialogue, we can introduce multiple characters and we can add the respective sounds according to the pitch the pg is speaking in, we can change the speed at which the text is printed, and finally we can give the player the opportunity to answer questions and change the pg's answer according to the answer given by the player.