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

email@address.com

 

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

Development

First: Three colours solved

JP McMullan

Early in development, I encountered 3 colours, it was crazy hard.  It is a fantastic feeling solving a Brick Block, but I had to learn a new move to solve three colours.  Amazingly the symmetry speaks to you, well it did to me tonight.

For that, as a pure indulgence, here is my victory screen shot:

Push

JP McMullan

Coming up with defensive and offensive mechanics is easy.  Judging the impact of the these mechanics and their effects on the game was a greater undertaking than I had predicted.

I am certain the Wild block has it's place in the game.  It will be the perfect way to get over the line in the heat of battle.  This device is really something you add to your own Brick Block.  I felt there needed to be something push at your opponent.

Shove

The more I thought about it, the idea of a shove to throw them off balance felt like a good way to interact with your opponent.  The Shove would be less rare than the Wild block, so as you play and win these special blocks, a few shoves won't be too hard to have in your inventory.

With the shove, I wanted to provide a sense of disorientation, so in the span of a few seconds, the opponents screen will be randomly colour shifted and will apply 3, possibly 5 random moves, like a shuffle move.  

Here are a few screens of what this looks like, although a real-time live example is far more intense.  From an art style perspective, I am happy to say this reconciles with the rest of the Brick Block visual identity.  I'm not sure why, but that focus on cohesion has become very important throughout this process. 

Here is what it looks like when your opponent shoves you!

Performance

This distortion effect is performed as a post process after each frame is rendered and as such takes a slight performance hit to achieve.  At this moment, the player cannot interact with their cube, and once the shove has finished, performance is back.  

When you push your opponent, the performance hit is far less as it only impacts their cube's render, so overall I am comfortable with this effect.  

Gameplay

For gameplay, I couldn't be happier, when you see your opponent getting close, this is great to keep the game going, when you are pushed, it does disorientate, but it's not too bad, and make you want to push back, evokes a retaliatory emotion. It feels worth the push, knowing what it's like to be pushed.

Control

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.

Summary

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.