Newtonian Boxes moving in diagonal lines when pushed right or left, but in straight lines when pushed up or down.

• This perplexed me to the point that I had to reach out for assistance in understanding what was going on. The issue was complicated by the fact that the first lab assistant that responded to me stated that my script looked correct, and they also had no idea why the box would be moving diagonal instead of in straight lines. I struggled with trying to correct this for a couple of days, and was almost ready to give up when the instructor was able to identify where my obstacle was: when generating the level map, the tiles on the “y” axis wrap to the next side of the map to a new “x” location to build the next row. Because pushing the box left or right caused my pathfinding function to test all tiles along the directional axis until it found one that could not be entered, my test continued into the new “x” rows until that condition was met. This resulted in the box moving diagonally “down” when pushed left and diagonally “up” when pushed right as the pathfinder followed each row end to the next “y” box in the array. 

• The instructor suggested using the generated tile map’s width and height as limiters for my pathfinding function, and implementing this suggestion instantly fixed this issue.

Implementing Newton’s Second and Third Laws of Motion

• This was more of a minor hiccup that involved me not completely understanding how the tiles detected their neighbors at first. The initial logic used the player pawn’s tile as the test, and set the movement direction to be opposite from where that pawn was located. I really spent some time in learning how these direction tests worked, and thought I had fixed my issue, but the initial box still would not pass on the movement. My “AHA” moment came when I realized that I was still testing for stamina before applying movement to the new box, and of course, the Newtonian Box does not use stamina, so this was always testing as false. Once I removed that bit of code, it worked beautifully.

Activating tiles between originating tile and final tile

• In my initial concept, the Newtonian Box was supposed to activate each pressure pad it passed along its route. I had included this in the concept because I did not understand how movement worked in this system yet, and was used to using collision boxes, so had assumed that the tiles would simply detect the box as it passed by and trigger the plates. But after learning that the box doesn’t actually move through any of the tiles between its origin and destination, but merely creates the illusion of movement, I became stymied on this functionality and removed it from my plan. Looking back now, I know that I could have built an array within my pathfinder function, and used that to activate the intermediate tiles accordingly, but you live and you learn.

Clone tile had no tile

• When I first accepted this mechanic through click-up, the creator had not been able to implement a tile functionality to spawn a clone, and had circumvented this by placing both the player pawn and the clone pawn on a map, and then switching between the two, and in order to switch between the two, they had hard-coded references to the two pawns in the level blueprint. I knew this would not work for me, because I wanted the player to be able to spawn multiple clones and have the ability to destroy existing clones, so I needed a more dynamic approach. While building the mechanic, I chose to limit the clones so that only one could exist in the level at any given time. This allowed me to have the “Switch Entity” function only look for the existing clone/player when transferring possession. To facilitate this in later levels requiring multiple spawn, the clone tile looks for an existing clone, and if it finds one, destroys that clone before spawning a new one. I also limited the tile functionality to only be usable once per level.

Having only one type of pressure plate resulted in puzzles that were too easy to solve.

• Because the way the tile system is set up, using my Newtonian Movement mechanic means that my box needs an open path to be usable. This was not so much a problem with just my one mechanic, but once I added the clone tile to my project, the issue reared its ugly head. During level design, I found that it was nearly impossible to design a puzzle using both mechanics in the solution because the player could just skip using the boxes altogether by manipulating the player entity and the clone entity to navigate the puzzle and completely bypass having to use a Newtonian Box. I solved this by implementing new tile mechanics in which one pressure pad only responds to the player, one only to the box, and a third responds to either. This allowed me to really control the flow of my puzzle designs.