The Code Behind Time

When programming Isochronal Panic! one of the most important design concern was how to make the time copies. Let's take a look at how we did it:

Time copies work in a fairly simple and straightforward manner. Essentially, the player avatar always has a recorder object in it. The recorder keeps track of two lists of variables, the location the player is headed towards, and the current time whenever that location changes. When a hop occurs, the record is handed over to a new entity, which has almost the same code behind it as the player avatar, minus the control input. The copy then follows the steps layed out by the record exactly, by traveling in the direction specified for the the amount of time specified. Do this over again a few times and soon you've got a room full of yourself!

Let's take a look at some code:

this.recorder.recordObject(new Coordinate().startupCoordinate(this.destX, this.destY));

This line in the player object is called every time the coordinates of the clicked mouse, this.destX and this.destY, changes. A new coordinate object is created on the spot, and then sent to the recorder object that the player is holding onto. The recorder puts the new coordinate and a time-stamp into an array.

if (this.tick === this.record.duration[this.count]) {
 this.activateMovement(this.record.direction[this.count];  this.updateRequired = true; this.count++;}

This little block in the update function of the copy class is what reads the record made previously. Movement works the same as in the player, but instead of being controlled by coordinates from mouse input, it is controlled by coordinates stored in a record. The third line tells when the animations should be updated. The last line increments a simple count variable, so that when the time comes, the next coordinate in the array is read. This method is fairly simple and works pretty well under normal conditions. There is a major problem with it though: lag. It doesn't particularly cause lag, but when playing over the browser, especially on a phone, lag will happen. The first line of the above code is an if statement that will let the rest of the block run when the current moment in time, or tick, of the game matches the time-stamps in the record. If the game lags, then often times the tick variable will skip ahead a little bit, causing a few chunks of time to go ignored. If this happens near when the above code block should be executed, it might not get past the initial if statement. For instance, if an action is supposed to occur at tick 12 and some lag starts up at tick 10 and lasts till tick 13, then there's a good chance that ticks 11 and 12 will be skipped over entirely. The change in direction never happens, and the naughty copy just keeps walking in the same direction. We are already working on possible solutions to this problem.