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

Multiplayer refined

JP McMullan

IMG_2158.PNG

I started integrating the Photon Cloud networking solution and after some rework of the current build, I had a networked game going.  To keep overhead down I'm triggering RPCs at the end of each move.  The inclusion of another player adds a surprising sense of tension, always in your periphery just beyond the cube.

As immodest as this is, it was a neat achievement to get this running.  I've had many past and current projects that have brought me to a place where this could be done, I'm glad it's Brick Block.

Up to this point, every component had come together exactly as I had hoped. Naturally, the first speed bump would attempt to alter the course, but, this one I feel has put me on the right course...

Limitation

Somewhat of a surprise was a limitation in the Photon solution.  A registered device can see all open Rooms when in the Lobby (after the Room data is received, use OnReceivedRoomListUpdate() to list Rooms as OnJoinedLobby() doesn't have the data yet), however cannot see or get a list of other players in the Lobby. Once in a Room, there is no access to other Games in progress. Originally I had intended on putting the player into a local Game (not networked) and present the potential opponents represented by their rank. After looking at this from every angle, the current solution does not allow for this design and expects the integration of another match making service.

The effort required to add in an additional match making service was not the issue, it was the added steps for players (see previous post). As much as I like the iOS platform, not many people I know understand GameCenter and I have many devices registered against my AppleID, which would dilute the rank and match experience.  I wouldn't want a family unable to play against each other on devices with the same AppleID, and equally wouldn't want to expect them to understand difference. 

After battling against each other with this rough functional version of Brick Block, my wife suggested, "Why not just do what you already have, where it puts you in a room?", I had a build running with PhotonNetwork.JoinRandomRoom() at the time. At first my instincts were to continue researching these how others may have achieved my original design, and I wouldn't shy away from the added work if it achieved what I wanted. I began to look outside the PhotonNetwork solution to assess to best alternative to network Brick Block. 

After not too long I thought,  "I am searching for something based on the predicate that my Multiplayer design was right, but what if it wasn't?" What if it needed just a little bit more or as my wife happened upon, maybe a little less.

Could I refine this even more? It was already so minimal, less would simply be, "Joining a game". It dawned on me that now the battle was more primal, you could no longer choose to fight or flee, you had to fight. Whilst I kept looking, this idea became far more real.  Heavy Rain held more meaning because characters only had one life.  It was time to take the opportunity and redesign around this idea.

Redesign

The genesis was start local, and as quickly and easily as possibly, battle another player.  Here is a recap of the original design:

Start with a potential opponent (1) and a skip button.

Start with a potential opponent (1) and a skip button.

Opponent 1 received a challenge in battle, from the player (42)

Opponent 1 received a challenge in battle, from the player (42)

Opponent accepts and the battle begins

Opponent accepts and the battle begins

If we take away rank (at least in opponent consideration), we are left with, "I want to play someone".  With that in mind, the UI message should indicate: "add someone", and to execute that sentiment, here is the newer, more refined design.

Simply, add a player to battle

Simply, add a player to battle

While you wait, the + rotate to x to Cancel

While you wait, the + rotate to x to Cancel

Then an opponent appears, time to Battle.

Then an opponent appears, time to Battle.

I honestly like this more for so many reasons.

  1. I didn't like the idea that the people who loved playing, and were best, would be skipped in the old design out of fear.
  2. I didn't like the reality that there were people willing to battle, enough to match up and play, yet they wouldn't through the skip feature.
  3. I like that you are not offered a battle when you want to play solo, this design let's the player control when they battle and when they don't.
  4. I like that this design matches the infrastructure resource instantiation design perfectly, at most only one player in one Room will ever sit in waiting.
  5. It's less, and less is more.

Also keep in mind that I am showing an additional state in this design over the original.  A truer comparison is 2 screens.

This feels much closer to my original ideals.  When I want to play against someone, I summon them.  If no one is available, I carry on playing while I wait.  I'm always able to play this way.  Now, back to work.