Categories
Uncategorized

Lockstep in a Nutshell

Try it here: http://whiffpunish.com/rollback/index.html

Video Presentation of Lockstep in a Nutshell

With this unorthodox semester coming to a close, I’ve made my final push of capstone project progress. Initially this project was titled “Rollback in a Nutshell” since that was the form of fighting game netcode that had originally hooked me into the topic. But in my efforts to explain the depth of rollback, a form of lockstep netcode built on many other layers, I found that there was a substantial amount of additional breadth that needed to be covered first.

While rollback may not have been able to be explored, lockstep in general proved to be a substantial topic on its own. This underestimation of the work required combined with the academic restructuring that took place mid-semester due to the corona virus pandemic turned out to be a combination that substantially slowed my progress.

That said, I am still pleased with how it turned out. This project has shown me that the combination of educational interactivity and literature is one that I feel still has plenty of room for exploration. Perhaps in the future it will become more standard and tools will exist that bring it away from being somewhat of a programming exercise and makes it a more accessible prospect for teachers and professors in non-STEM fields.

Categories
rollback

First demo, first playtests.

In preparation for the first round of playtests that happened yesterday I created a basic website using a creative commons CSS template (Spatial), and I also made the site’s first interactive sketch.

Here’s what the page looked like…

…and here’s the interactive sketch, so you can reference it as I discuss its issues.

The sketch itself is somewhat opaque, as every playtester required at least a small amount of explanation to even interact with it in the first place. There are two aspects of the sketch that made it difficult to work with.

  • Issue 1: The sketch can’t read user input until it has been clicked.

This wouldn’t be an issue if there was some sort of indication that it needed to be clicked (I did provide text instructions, but these shouldn’t be necessary and I don’t fault the user for skimming past them). Some kind of feedback once the sketch had been successfully clicked would’ve also been beneficial. That said, I don’t plan to attempt either of those changes because I’d rather just remove the need to click the sketch altogether. If hitting the keys provides obvious feedback the first time the user attempts to use them, then I expect most of the confusion to clear up.

  • Issue 2: The sketch only polls for input a couple times per second.

When users would attempt to hit keyboard keys, it was likely that the sketch wouldn’t poll for input while the keys were down. This resulted in many users trying to hit keys, seeing nothing change, and concluding that the sketch was just a weird GIF. Similarly to the first issue, the lack of consistent feedback to the intuitive option of just hitting keys is what prevented most users from even realizing there was something to interact with.

The reason it polls so slow in the first place is because it only grabs input when it transitions from the “get input” state to the “change state” state. This transition can’t happen too frequently, or else reading the diagram at all will be difficult due to the speed at which everything updates. The solution I have in mind is to not have it constantly cycle through the states, and instead have it wait on the “get input” state until the user provides input. Once that happens, it will cycle through until it again reaches “get input”, at which point it will again wait for input. I believe this will result in consistent visual feedback that will ensure to the user that they are successfully interacting with the sketch when they hit a valid key.

Categories
rollback

Outline

The outline for the site has been established:

  • initial premise: for the game to generate a frame, we need inputs from both players
    • demo 0: shows how each state is a function of the previous state and the new inputs
  • problem 1: the remote player’s inputs take time to arrive
  • solution 1: wait for the remote input before creating a frame (naive solution)
    • demo 1: shows how this works, but fails (increases frame times) as latency increases
  • problem 2: every frame is now delayed by the amount of time it takes for the remote input to arrive
  • solution 2: delay local inputs (build a buffer)
    • demo 2: shows how a buffer allows for smooth gameplay at high latency, but also how this results in unstable input latency
  • problem 3: bad for learning precise input timings (delay is based on inconsistent latency)
  • solution 3: “rollback” netcode
    • demo 3+: rollback demo, potentially in multiple parts to decrease complexity dump

Categories
rollback

Rollback in a Nutshell

a work in progress