TBF #15 – Turbo Turn Part 2

This blog post is a two-part series about the design and development of what we call Turbo Turn. Check the previous part right here.

Recap From Last Week

Last week, we discussed how Turbo Turn should massively improve your experience in Make A Pair. It should give you faster play, a better experience, and a more responsive game overall.

This week, we'll focus on the implementation of the system in depth and look at the limitations we faced during development. Keep in mind that this is a first version of Turbo Turn. We expect it will improve over time with playtests.

Let's dive in!

Implementation Details

The main element for the implementation has been input buffering. The moment you click on a card, instead of discarding it as we were doing before, we try to compute that information. In the past, if the card was "occupied," nothing would've been done.

A card would be considered "occupied" if any kind of animation or computation was occurring. For example, a Shark that is moving means that all cards are considered occupied by the system and no clicks would be registered.

With Turbo Turn, we never have this kind of state management. We process all inputs that are transmitted to the system. It's done in a two-pass process.

  • First, we check if we can process the click immediately. If there's no resolution in progress, we immediately do the click logic as it was done before.
  • If there's a resolution happening, we'll buffer the input for that card.

The buffering is a bit more complex than it looks. We buffer clicks in "pairs." For example, if you click card A, B, C and D in quick succession, we'll pair those like (A, B) and (C, D). This is done for two reasons.

  1. First, the game starts a resolution when you make a pair. This mapping naturally fits the game. You could also click just one card during a resolution, and only that card would be revealed.
  2. Second, it also means you can cancel your move in the buffer without impacting the whole flow. For example, if you click on A or B after you've selected them, this would undo the pairing of (A,B) from being revealed while keeping the pairing of (C, D) active. This kind of undoing is a must. As we discussed last week, new information collected during a resolution can and will modify which card you intend to reveal next.

We don't stop there. We also must visually distinguish these pairs if you're doing more than one pairing. (A,B) should be visually different from (C, D) in a way that, as the player, you know which is paired with which. This is why we assign a unique colour pairing each time you make a selection in advance, with a rotating buffer for colours. Eventually, you'll come back to the first colour, but by that time it'll have been a while since you've seen it. No problem!

The end result of all that work can be seen in these videos right here.

Here is the result of all that work.
Here, you can observe the cancellation of a committed reveal in action.

We think this makes a nicer experience, and it works remarkably well.

Improvements

Even if we're confident in this system, we think there are clear improvements to be made. We know that in some cases, we can start revealing some cards while a resolution is happening. As an example, when you have four cards left and you've found one pair out of two, you could immediately start revealing the next pair if you've already clicked on it. This would reveal the four cards immediately. It's not the only place: some cards, or sets of cards, have a low amount of impact on the game resolution, in a way that we can genuinely speed up the play.

This will be carefully studied, because it might fall into a case-by-case status and that would be too complicated to implement.

Another place where we can do a better job is the animation speed and length. Some animations are simply too long to communicate what they do. We'll shorten them and make them snappier while still transmitting all the information they have to send. This will improve the game feel and the pace of the game.

This was Turbo Turn V1: our first implementation of a faster way to play. What do you think? Do you find it helpful? Any comments you'd like to send us? Let us know on Discord!

RSS Feed
Previous Post Blog List