A few years ago, while at university I woke up early just after it had snowed heavily and decided that it would be a good idea to go out for a cycle. Quite what possessed me, I’m not sure, but before I knew it I had set out on a 12 mile round trip in the snow across Windsor Great Park.

I took quite a few good pictures that day, but this one is one I’m most keen on – I like its composition and the striking contrast between the black of the tree’s bark and the white of the snow. The smallness of the tree in the scene adds to the overall effect.

A couple of years ago, towards the end of a holiday in France, we stayed in a hotel in the Loire valley. As I was wandered through the gardens of the hotel after breakfast, I was surprised when a hedgehog came snuffling its way across the path. I pulled out my camera and followed it while alternating between filming and photographing it.

It seemed completely unfazed by my presence and was intent on searching for mirrabelle plums that had fallen from the trees growing in the garden. It would take a bite from each plum it found, then move on, sniffing its way to the next one.

I noticed what looked like an ant evacuation in progress, up the wall of my parent’s garden last weekend. A long line of ants was running up the wall carrying eggs and another long line was running down the wall to collect the eggs. They seemed to be pulling the eggs out of a small crack in the wall’s render. They managed to keep this process up for a good few hours before they had finished.

I read that sometimes ants steal other ants eggs and raise them as their slaves, but that seems unlikely. I’m assuming the ants had found a better home to move in to - perhaps the idea of there being so many children about to be born made them realise that it was time for them to move up in the world.

It was hard to photograph as getting the focus correct was a pain, and they were running fast which led to quite a bit of motion blur. The actual march up the wall was more dramatic, but the focus and motion blur got the better of me.

Continuing the theme of herons behaving oddly…

While on our way to the Open Air Theatre in Regents Park to see the pretty well acted and very well staged play of Lord of the Flies, we came across a pair of Herons nesting on the top of a Weeping Willow in the middle of the lake.

Early last Summer, we had a few days camping in Kettlewell in the Yorkshire Dales. Kettlewell is a lovely village in the middle of the Yorkshire Dales, at the bottom of a deep valley. We were camping in a fairly basic campsite in a field at the top of the village, which was popular with the Duke of Edinburgh groups. The loos and showers were a 5 minute walk down the road in the middle of the village, but this seemed fine – perhaps if it was pouring with rain we may have thought otherwise.

Kettlewell has a fantastic general store that sells food and souveniers as well as some interesting local cakes. The highlight of our stay were the bacon sandwiches we had for breakfast each morning prepared at the shop!

We managed to get there by lugging our tent, air mattress (a luxury!) and general paraphernalia from London on a train to Leeds then another train to Skipton, then a bus to Kettlewell. This included a mad dash between the two trains, across Leeds to get to an outdoor clothing shop to buy a raincoat – having never visited Leeds before, this was not a great start to our holiday.

Luckily no raincoats were required – we had beautiful sun for the four days we were there.

I’m not sure what the insects are, or what they’re up to but they look like they’re having a good time!

Putney Heath must have once been part of Wimbledon Common, but is now separated from it’s much larger sibling by a dual-carriageway road, Roehampton Vale (the A3).  My girlfriend, Steffie, lives a few minutes away from the heath, so we’ve spent some time exploring it. It’s small and for the most part densely wooded, with a few open areas and a medium sized pond. It’s odd really that it’s called Putney Heath at all, as it’s far closer to Roehampton.

It was on this pond that the heron below was spotted. I’ve seen a number of Herons acting oddly recently, at least in a way that seems odd to me. More pictures of these to come later in the week!

Getting started

A free limited simultaneous connections version of Photon can be downloaded from their website http://www.exitgames.com.

A separate Unity SDK is downloadable from their website as well.

Documentation

Documentation seems fairly weak. Their best introductory documentation that I’ve found is the Photon-DotNet-Client-Documentation PDF file included with the Unity SDK. They also have a CHM that covers the code, but this has nothing that’s not in the code itself as comments.

Applications

Photon is built around Applications, which are C# libraries that provide server-side logic.

It comes with an application called Lite which they suggest deriving from. It provides some basics that they expect you to want, mainly the concept of Rooms that players can join. It adds ‘properties’ (see the bottom of this page) which is data that is automatically synced between client and server and either can update. It also comes with a sample called LiteLobby that extends this to allow you to join Lobbies, then join rooms from those lobbies.

LiteLobby gives you a good idea of how to extend Lite to add extra features.

There are some other applications I’ve not looked at, such as MMO and NetSyncObjects. The later is designed for use with Unity, but is higher level than you may want. This document looks at the lower level systems

Principles

Photon has a two core concepts – Events and Operations.

Photon provides some things to make these easy(ish) to deal with.

Events

Events are sent to clients by the server. Clients can’t send events to the server.

The Lite application blurs this a bit by providing an operation (see below) called RaiseEvent that lets a client instruct the server to send an event to all other clients (but not itself). It would seem this provides convenience (as it allows you to avoid writing server-side logic) but may not actually be a Good Thing (security-wise etc).

Each event has an event code to identify it, which is a byte, along with a Hashtable that stores the data that goes with it. Events can be sent reliably or not.

Operations

Operations are essentially the reverse of an event. The client sends them to the server.

Photon considers these to be RPCs, but they’re not as automatic as you might expect RPCs to be. An Operation is a message that the client can send to the the server, and again the type of operation is represented as a byte, called the opCode.

A key difference between events and operations are that operations are able to return a result to the client.

When you trigger an operation from the client, you’re given an id that is returned to you in the result, to allow you to link up your request with the response from the server.

Code

Unity

Implementing Photon in Unity is pretty easy. Put the PhotonUntiy3D dll that came with the Photon Untiy SDK in your Assets directory somewhere, and Unity should load it and add it as a reference in the Visual Studio project.

You’ll notice the reference to LitePeer below. This is because the Unity Photon library includes support for the Lite server-side library. I believe it’s optional whether you use this. Functions like joining rooms (below) depend on this though (but of course, you could write your own system for doing this instead of relying on Lite).

You then need a class that implements IPhotonPeerListener, this is a reasonable outline I think:

This is the way you interact with Photon.

You should create an instance of this class from a component. They recommend attaching this component to something like the camera that’s always around, though this likely doesn’t really make sense in a real project. You should also set Application.runInBackground = true somewhere otherwise Photon will get disconnected when the application isn’t focused. You should also call the Update function of the PhotonListener class periodically, i.e. from a MonoBehaviour’s Update function.

This code should be enough to get you connected to a server. If you’re using Lite as the base, you’ll want to join a room once you connect.

You can do this by adding this to the PeerStatusCallback:

This joins a room named ‘GameNameGoesHere’ when the Peer successfully connects to the server,

OpJoin is an operation, and results of operations are (unsurprisingly) reported to the OperationResult function. You’ll receive a call to this if the join is successful or unsuccessful. You could add something like:

If you just run the server at this point, clients should be able to connect. You can now use OpRaiseEvent to send messages to other clients, and receive events in the EventAction callback. You can use OpCustom to send arbitrary Operations to the server.

Server

Running the Photon Server

Photon comes with the Lite application, which allows clients to communicate without the server doing much more than forwarding messages between them. Lite also has other functionality that’s explored later.

You can now run the Photon server and make Unity connect to it.

• Open the deploy directory in the Photon server directory
• In the bin_Win64 directory run PhotonControl.exe
• An icon should appear in the system tray
• Right click on this and select Photon -> Start as application
• Now you can run your unity project and it should be able to connect and exchange data using OpRaiseEvent.

Server-side applications

Of course, part of the point of using a server rather than peer-to-peer is being able to write server-side code.

The server-side code is in C#, though ‘real’ Microsoft C# rather than Mono. You write what Photon calls Applications that are essentially plugins that the server runs.

Server-side there’s the Lite and LiteLobby applications that extends the basic system.

The basic principle is that we create a class library that contains a class that derives from Photon.SocketServer.Application and override it’s methods as necessary. We then place that in the server’s deploy directory and add it to it’s config so that it loads it.

Once you’ve derived from Application, you can do whatever you want.

Starting from scratch

• Create a new Visual Studio project, selecting a C# Class Library as the type. I called mine PhotonTest.
• Add the Lite project to your solution
• Right click your project and add a reference to the Lite project
• Add references to the following DLLs in the server’s lib directory: ExitGames.Logging.Log4Net, ExitGamesLibs, log4net, Photon.SocketServer and PhotonHostRuntimeInterface.
• Create a class that derives from LiteApplication. I’ve called it PhotonTestApplication:

  using Lite;

  using Photon.SocketServer;

  namespace PhotonTest

  {

  class PhotonTestApplication : LiteApplication

  {

  }

  }

• This should be enough to get your application running inside Photon.

Running it

We’re going to get this very simple application running on Photon. This involves setting up the directories for it and adding a reference to it to Photon’s config file.

• Open the deploy directory of the server
• Inside you’ll see a directory for each build of the server – bin_Win32, bin_Win64 etc.
• You’ll also see directories for Lite and LiteLobby (and Mmo). These are the applications that the server can run. We want our newly created application to build to here.
• Create the directories for it, following the example of how the Lite and LiteLobby directories are arranged. So, this should be PhotonTest\PhotonTest\bin. I’m not sure the double PhotonTest is required, but that what’sLite and LiteLobby have.
• In visual studio, set your project to build to this directory. Go to the project properties, select Build and then set the Output Path.
• Build the project

We need to tell Photon about our application by adding it to its config.

• In the deploy directory, open the the relevant ‘bin_’  directory for your platform and open PhotonServer.config in an editor
• Scroll down to the bottom and you’ll see an <Applications …> section. We need to modify this to point to our PhotonTest application. This should be fairly self-explanatory.
• Remove the sections for MMODemo and LiteLobby.
• Modify the Lite section changing all the Lites to PhotonTest. Make sure the Type field refers to the class you’ve made that derives from LiteApplication correctly, so if you’ve followed my names, this would be PhotonTest.PhotonTestApplication.
• Modify the Default application field to PhotonTest.
• The Applications section should look like this:

  <Applications Default="PhotonTest">

  <!-- PhotonTest Application -->

  <Application

  Name="PhotonTest"

  BaseDirectory="PhotonTest\PhotonTest"

  Assembly="PhotonTest"

  Type="PhotonTest.PhotonTestApplication"

  EnableAutoRestart="true"

  WatchFiles="dll;config"

  ExcludeFiles="log4net.config">

  </Application>

  ...

  </Applications>

• I’m not sure if the server automatically reloads the config when you change it, if it doesn’t, restart it using the PhotonControl system tray icon.

Watching it

Photon writes logs out to a file, and comes with a program called BareTail for reading them.

You can right click on the PhotonControl icon and select Open Logs to see them.

All the logs live in the log directory in the deploy directory.

You won’t see messages you log out from your program in the logs that PhotoControl opens by default. These are written out to a file you have to specify in the log4net.config file in your bin directory. You should open this file, then modify the File parameter under for the LogFileAppender to be something like “log/PhotonTest.log”. You can then open this log to see the output.

You can change how much is logged to this log by changing the logging levels from INFO to DEBUG at the bottom of the log4net.config file.

The way to log to this file is to use LogManager.GetCurrentClassLogger() which provides various functions such as Debug, Fatal and Info etc. You’ll need to add a using ExitGames.Logging. There are examples of this in the Lite and LiteLobby projects.

Adding some server-side logic

This is where it gets a bit complicated, and depends on whether you’re using Lite or not.

At it’s most basic, we need to add a new class that derives either directly from Photon’s IPeer or with Lite’s derived version LitePeer.

This class needs to handle incoming operations from clients. LitePeer handles a number already for us – the join operation for example, so if you derive from it, you need to work within in it’s framework.

I’m going to assume we’re using LitePeer - deriving directly from IPeer is simpler though you lose the useful features it has.

Creating the OperationRequestDispatcher

Lite has a class called OperationRequestDispatcher which handles all the operation requests each peer makes. To add our own operations, we need to derive from this and override its DispatchOperationRequest method.

• Implement a class called OperationRequestDispatcher
• Override DispatchOperationRequest

  using Lite;

  using Lite.Operations;

  using Photon.SocketServer;

  namespace PhotonTest

  {

  class OperationRequestDispatcher : Lite.OperationRequestDispatcher

  {

  public override bool DispatchOperationRequest(LitePeer peer, OperationRequest operationRequest)

  {

  return base.DispatchOperationRequest(peer, operationRequest);

  }

  }

  }

Creating our own Peer class

We need our own peer class to handle the operations received from each peer.

• Create a new class called PhotonTestPeer which derives from LitePeer.
• Override the OnOperationRequest method. Leave this blank for now.
• Create a static instance of OperationRequestDispatcher called operationDispatcher

Your class should look something like:

Using the Peer class

We’ve got the basic outline of the PhotonTestPeer class, now we need to use it to represent each client that joins the server.

• Open the PhotonTestApplication class
• Override the CreatePeer function from the base class
• Make this return an instance of our PhotonTestPeer class.

You should have:

Fleshing out the PhotonTestPeer class

Your OnOperationRequest function will be called every time a peer requests an operation is performed.

You could just handle the operations here, but you’ll break Lite’s built-in operations. We need to use the OperationRequestDispatcher here.

Add the following to your OnOperationRequest function:

This will use the OperationDispatcher instance we have to try to handle the operation. Because this is derived from Lite’s OperationDispatcher, the basic Lite operations should now work.

Notice the call to PublishOperationResponse. This method is provided by Lite and is used to return the result of an operation to the client that requested it. OperationResponses can be semi-automatically generated as we’ll see later.

Testing it

You should now be able to test your application.

• Build the project
• Photon detects when an application changes automatically and reloads it – this happens 10 seconds after you build.
• Watch the PhotonInstance(…) log file to see when it’s done it and see any errors
• Try connecting with Unity – everything should still work

The Game

This gets a bit complicated…

Lite has one area we’ve not explored – the Room class. This is basically a named group of peers that can communicate with each other. Lite handles the joining and leaving for us, and provides us with some convenient methods for getting at this group of peers. It wraps these peers in a class called Actor - an Actor is a LitePeer that’s in a Room.

Room allows operations that a peer receives to be queued up and handled by using the EnqueueOperation function.

Lite has a class called LiteGame which is a derived version of Room that uses receives operations delivered with EnqueueOperation by the OperationRqeuestDispatcher and uses them to add Actors to the Room.

LiteGame is the class we’re interested in – I’m not sure there’s a good reason to derive from Room directly.

The LiteGame class’s Actors list is protected, so we need to derive from it.

• Create a new class called PhotonTestGame
• This should derive from LiteGame
• For now, just implement a constructor that logs out that it has started so we can see if it works.

Here’s the code you should have:

PhotonTestGameCache

Lite has a class called RoomCacheBase. This class is used to create rooms by name – if a room of that name already exists, the existing room is returned. It also handles reference counting rooms – removing them when they’re empty.

We need to create a derived version of RoomCacheBase which will create PhotonTestGame instances. If we didn’t do this, Lite’s LiteGameCache would be used instead which would create LiteGame instances.

• Create a new class called PhotonTestGameCache.
• Implement CreateRoom
• Make this return a new PhotonTestGame instance
• Add a public static Instance variable initialized to a new instance of PhotonTestGameCache.

CreateRoom is called by the RoomCacheBase code when it hasn’t found a room with the matching roomId in it’s cache.

Joining these bits up

Finally, we need to join these bits up – so that we’re using the newly created PhotonTestGameCache when the player wants to join a room.

To do this, just override GetRoomReference in OperationRequestDispatcher and call GetRoomReference on the PhotonTestGameCache the Instance variable returns.

This works because the code for handling joining rooms etc is in the base class of our OperationRequestDispatcher. It uses this GetRoomReference function each time it needs a Room.

You should now be able to test this works. You should see “PhotonTestGame created” output in the log when the player joins the room if it does.

Events

We’ve not actually made the client and server interact yet!

Events let you tell clients to do things.

Client-side

Create a prefab in Unity and put it in your Resources directory. I’ve used a Cube called CubePrefab in this example.

Let’s handle an event in the Unity code:

An event is a code plus a Hashtable. The Hashtable contains three values – the x, y and z position of the cube to spawn.

Notice that each item in the hash table has a number – 100, 101 and 102. These are the IDs and are bytes (despite some things suggesting they’re shorts, this was a change that was made in a recent Photon version). You can use strings in hashtables, but Photon strongly recommend that you use bytes for performance reasons.

Photon has some predefined IDs for things, as does Lite. It seems numbers greater than 100 probably don’t have pre-existing meanings.

Server-side

Server-side, Photon has some fairly clever support for Events (and Operations) that’s missing in the client-side Unity code.

The event class

• Create a new directory in your project called Events
• In this directory, create a new class called CreateBlockEvent

We use this class to construct events to send to the clients.

Each of the X, Y and Z are stored separately. Photon claims to support any data type, but I’ve not looked into this yet.

Note how the Code for each parameter matches the codes used client-side.

Using the event class

Now let’s hook this up server-side by creating a thread that repeatedly spawns these cubes on all the clients:

• In PhotonTestGame create a new thread with a function called CreateBlocks, and start it.
• Create a CreateBlocks functions

This could should be fairly self-explanatory. Of interest is the use of the Actors property to specify who to send the event to. This class provides a number of useful ways to get at the actors in the room, and subsets of them. We’ll see that later.

Give it a go

That should work. Make sure your camera is near to and looking at the origin, then run it and see what happens.

Operations

Operations are the reverse of events – clients can send them to the server.

Client-side

Let’s make it so that clicking on the screen spawns a block there.

In your Update function, add:

This looks similar to the event code. Again, we have an ID and a Hashtable.

We use peer.OpCustom to send the event. A better approach would be to override the peer class and add a method for each operation that wraps this code up.

Server-side

Server-side it’s again a bit more complicated.

The operation class

• Create a new directory in your project called Operations
• Create a class in this directory called CreateBlockOperation

As with the event, we need to create a class that matches up with what we’ve got in the Unity code:

Using the OperationRequestDispatcher

We’ve finally got a real use for the OperationRequestDispatcher!

• Open OperationRequestDispatcher
• Add the following to your DispatchOperationRequest method

In real code, you’d replace that 150 with an enum, but it’s left as a number for clarity here.

Notice that we’re checking the validity of the request – this checks if all the required data is there (i.e. everything marked as ‘IsOptional = false’ in the Operation class).

Then let’s implement the CreateBlocks function:

This sends the event to all the players except one (the owner). We specify the player that triggered the operation as the owner, so the player won’t get told about the block they created (they’ve created it themselves locally).

Notice the use of GetExcludedList and GetActorByPeer.

Other things

Debugging

You can debug with Visual Studio by attaching it to the ProtonSocketServer.exe process. If you record a macro of this, you can add it to the visual studio toolbar which makes it very easy to do.

Channels

Photon supports channels so that you can prioritise operations and events separately. I’ve not covered them here, but the event and operation sending functions have overriden versions that allow you to specify a channel number.

Data is always sequenced in the same channel – so sending reliable and unreliable data in the same channel seems to be a Bad Thing. If reliable data is lost (and resent) then the unreliable data that was sent after the reliable data won’t be received until after the reliable data has arrived.

As such, if the reliable and unreliable data aren’t required to be processed in-order, then they should sent on separate channels (e.g. chat and position updates).

Lite’s Properties

Properties are added by Lite to games and peers/actors. Any peer can change any actor’s properties. Only the peer who created the room can change that room’s properties (though it’s not obvious if there’s a way to know if you created the room.)

When you join a room, you’re sent the properties of all the actors in that room.

When a property is changed, an event is raised to tell all the players (though only if the ‘Broadcast’ flag is set on the operation from the client).

This obviously means that players can have different views of the properties depending on when they joined, as they’ll have whatever was set on the actors in the room when they joined + what properties were set with the Broadcast flag set. The result of this can vary depending when you joined. Presumably you’d be ignoring properties that are set without the Broadcast flag though.

Because anyone can set properties, they seem not a good thing to use in the real world. They could be developed further to improve them though.

Retlang

Photon doesn’t really mention it, but it includes a renamed version of a library called retlang. This is a threading library that lets you pass events between objects. It’s used heavily in Lite to link up the different components.

Well…

That’s it. Assuming I’ve not made any silly mistakes, that should all work and you’ve got a great networked game working.

A few years ago, I had a fantastic walk along the East Sussex south coast from Eastbourne to Seaford, before I moved down to Brighton. The walk started in Eastbourne, up to Beachy Head, along the Seven Sisters cliffs, through Cuckmere Haven and then into Seaford. I started late in the day, but managed the 12 mile walk before it got dark – thankfully!

The walk started at Eastbourne station. Eastbourne is not an exciting place – it is much like many other medium sized towns on the south coast. It has a pier and a long sea front – more steep than Brighton’s. It’s a popular place to retire to, and you can tell that by the feel of the place.

A short walk and a long climb from Eastbourne is Beachy Head, the renowned suicide spot, with it’s picturesque lighthouse perched on the rocks below. It, like much of this walk is fairly exposed to the elements with little tree cover, and it has always been incredibly windy whenever I’ve visited. Most importantly, it has a pub which has some good views across the valleys.

The Seven Sisters cliffs make up most of the walk to Seaford. The footpath travels across the grassy tops of the cliffs, across a series of named ‘hills’ and ‘bottoms’ – including Rough Bottom! This makes for tiring walking, but offers some great views of the cliffs and far out to sea. These cliffs frequently are seen in dramas standing in for the ‘white cliffs of Dover’, as they’re far more picturesque than the real thing!

Seven hills, and seven bottoms later, you’ll reach the western end of the cliffs and find Cuckmere Haven, a beach and estury of the Cuckmere River owned by the National Trust. This is a nature reserve with plenty of wildlife. Sadly, it is at risk of flooding and the current plan seems to be to allow the valley to flood into a salt marsh – visit it while you can!

Anyway, the memorable moment and the reason for this entire post was that I stumbled upon a Badger in broad daylight, while walking down the eastern side of Cuckmere Haven. It quickly ran off, but not before I managed to get a picture!

So, my blog kind of fell by the wayside. Since my last post 3 years ago, I’ve worked for, and stopped working for, Black Rock Studio, currently part of (but not for longer) Disney, in Beautiful Brighton. I’ve just started working for Mind Candy in Sunny Shoreditch.

Inspired by my new colleague Cat, I’ve decided that my blog really shouldn’t be quite so terrible, so I’m going to post some of my wildlife photographs – not as good as hers, unfortunately! Some of them date back a few years – some I’ve posted on Flickr before, some I’ve never got around to posting anywhere.

This is a simple experimental game, coded in XNA, that I’ve been working on for the last few days. I’ve been using it to experiment with physics, collision detection and some simple lighting shaders.

It’s main feature is a green glowing ball that squelches around a level. The ball is made gooey using a few hundred particles at each vertex on it’s surface. Each particle is physically simulated and tied by a virtual spring to every other particle. This gives the ball bounce, but is pretty computationally expensive.

Pictures do not give much of an idea of how it works, so have a look at this pair of videos:

Both these videos can be downloaded in much higher quality here (9.33MB) and here (19.4MB).

This is, of course, work in progress and I’m going to be adding more to it over time.