contact us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right.


123 Street Avenue, City Town, 99999

(123) 555-6789


You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.



JP McMullan

I have transitioned from player to keen observer for the last few days and watched a few friends and family playing Brick Block. 

The control of shifting blocks is really everything with this game, so I want it to be universally right.

At the moment, when the player touches I track that initial point then continue to measure their distance of drag from the initial point each frame until they let go, then snap to the closest 90 degree interval. As they drag, I vary the speed of the rotation by distance, thinking that people would like the ease of doing multiple 90 degree jumps. Knowing this, I take advantage if it constantly however I am not certain this is intuitive.

Observation 1: Flick

People will flick a plane. The current code won't give them what they want because invariably the minor flick distance is not enough to overcome the required threshold. What's interesting is that they will keep flicking. I might even delicately explain how it works, but they keep flicking. They interact with the cube in the exact way Apple has taught them to use the inertial scroll of a Table or Slider.

So people want to flick, and this was unexpected as I had built the control based around the perception of a physical cube, one which a flick would do nothing. As such I've taken time to reconsider the control and here's what I'm thinking now:

  1. Return to a 1:1 drag to rotation movement, essentially use the delta distance as opposed to the distance from initial drag. This will keep the player's finger in line with the shift. 
  2. On release, apply a velocity from the delta drag to determine whether a drag and stop or a flick is in vogue. If a flick is happening, finish the move with a dithering momentum to a lower threshold that will snap as it does now. 

These two changes should provide the expected behaviour for those expecting inertial scroll, which seems to be prominent on first play. 

Observation 2: Go back

Given the learning curve of a 3 dimensional interactive experience, as expected, players make mistakes as they condition themselves to angular drag control. 

It is very much like riding a bike, at first it's a little awkward but once you get it, you're away.  That sentiment does not stop people becoming frustrated. People want to undo their mistake, which won't be of issue as I will track every move made by the player to verify they won or lost at the server. So a natural solution is an undo button, but I don't want to do that as I feel it breaks the experience of the game.

After some thought, I was thinking the following could be a good alternative: 

  1. Now with a 1:1 touch to shift movement of the block plane, it would potentially be more natural to snap back if you continued dragging back to the initial touch point. I currently have a minimum distance before I start dragging as I want to ensure enough distance to cause a true angle of intention. This minimum distance could be repurposed into an 'undo' zone. This could let the player drag back if the in intended plane were selected and without lifting, drag out along a different angle to achieve their intention. It also offers safety, whilst they hold down, they can always go back.
  2. If this control method is in play, the current multiple + faster rotation would disappear. The primary benefit of that control was an ease to rotate multiple 90 degree intervals without lifting and requiring secondary actions. This benefit could be retained by a continued hold at the end of the rotation, where a short amount of time is measured, then the same rotation is triggered again, then repeated on a continued hold.

However, I have just finished implementing 1:1 control with reverse actions, and it seems to be all I need.

Ultimately implementing an intuitive solution trumps my ego or exhaustion. I would rather that than convincing people and myself that it takes some time to get used to it.  This feels good, and may be extended for the continued hold to undo then launch along another plane.


I feel my first pass provided the controls closer to that of a speed boat rather than a race car, and in this case, the preference appears to be the race car.

Time to make a pit stop and swap in a new steering wheel.