A day in Coltsfoot Vale

Interactive map

by Emily Allbon, Simon Goulding, Howard Richardson, Adam Doughty.

Coltsfoot vale is a happy place but its residents are having more than their fair share of legal disputes. Explore the interactive map and try and figure out answers to their land-law problems.

Online interactive map game

This is a custom-built Javascript online map with light game elements. The user is encouraged to explore the map and self-test their land law expertise in a variety of legal scenarious.

Visuals and narration play a large part in making these otherwise static scenarios come to life in the student's imagination.


After being inspired many years ago by Paul Maharg’s simulation work and his virtual town of Ardcalloch, I have hankered after my own space to tell stories from. Students often find land law one of the more challenging subjects, partly because it is so legislation-heavy but also because they find it a bit alien…most of them won’t have bought a house, many won’t even have rented as they are still at home with their family. The issues we cover aren’t familiar to them in the same way as contract, tort or criminal law.

I have a minor obsession with maps (especially after going on a course run by the fantastic Helen Cann) and saw them as a great way to share stories.

Creating something which was detailed, engaging and interactive was always going to be more than I could achieve alone and so I teamed up with Adam Doughty, a wonderful illustrator whose style I admire tremendously, and Howard Richardson, my fantastic long-term Lawbore collaborator and web programmer, who would bring the map alive and make the content dynamic.

Using characters helps us get the students to think about land law in a less sterile way

Emily Allbon, writer

Using characters helps us get the students to think about land law in a less sterile way; considering the importance of home and having some empathy for the characters who face sometimes traumatic upheaval. It's a small detail, but even just giving them portraits and full names elevates a problem question from the abstract into the imaginably concrete.

Materials and creative process

The materials to create this map came from three main contributors and included specially paid-for commissions. The map itself we had drawn by a professional illustrator, whom we supplied with the spec for all the buildings and places it should contain. After several weeks of work he was able to give us a giant photoshop image with multiple layers. There was one background layer, containing all the scenery, and then all the hotspots (buildings mostly) were separates layers on top. The image was drawn in sufficient detail to allow the user to zoom in and out, as not all of the scene and detail needed for the map would be possible to fit on screen all at once. We asked our illustrator to draw each inhabitant too, to give them a better sense of being real people.

To go with each hotspot building, I wrote a scenario which encompassed a land law problem, added a portfolio of those who lived there and provided commentary and integrated questions and answers. For some of the buildings I also recorded a video presentation explaining the overarching legal principles involved in that area of land law.

After an initial few buildings, I recruited my colleague Simon, who is City's land law specialist. He agreed to write many of the commentary sections and also to provide much-needed critique on anything I'd written. His expertise has been invaluable to this project. We completed six buildings ready for launch and will work gradually on adding new ones. We're also hoping that academics and practitioners outside of City will consider getting involved too #AdoptAColtsfootValeHome.

Armed with the background, illustrations of the buildings and their inhabitants, and the story and support materials, I took these to Howard and he combined them into a online game of sorts – there's no "winning" involved, but the playing field can be interactively explored in a non-linear manner, and the students can self-test their understanding and knowledge of the matters with quizzes.

Although it may sound like straightforward, many of these phases overlapped in actuality. Being the first time we'd attempted anything on this scale, there was some trial and error involved, and much communication and revision between the writer (me), the illustrator and the programmer.

Having completed this project now, we're all in a much better position to know how we would set about another similar project. Planning what was needed for each of the stories was key, as was making sure the illustrator was kept appraised of the evolving stylistic and technical requirements by the web developer. Ultimately it was an incredibly rewarding process to work with creatives who were responsive to our needs.

Technical development – in the words of the programmer

You can skip this section if the technical details of developing the game aren't of interest to you!

We hope that there will be quite a few programmers visiting this page too, and for their benefit here is an overview of how I built the game.

My original intention for building the map was to try to make it as close as possible to a re-usable generic module into which lecturers could drop their own materials. We fell short of this in the end, because the technical demands of creating and assembling all the story materials made a web-developer-less product impossible anyway. Having said that, the final product is still customisable enough that a lecturer working with a web developer knowledgable in Javascript (and possibly some PHP and MySQL) could adapt it to their own purposes.

In the early days of development I did test and consider learning and using existing Javascript game development frameworks or professional animation packages to make the map, but without enough experience in this field I was scared of ending up in a dead-end. What if I spent some weeks making progress only to encounter a feature we absolutely needed which the package was incapable of fulfilling? In the olden days we'd have made a game like this in Adobe Flash, but the modern equivalents of HTML5 and Javascript aren't quite as one-size-fits-all as a Flash virtual machine. Instead we opted for a roll-your-own approach, combining JQuery and plain Javascript with existing animation and multimedia libraries, to achieve exactly the results we needed.

There is a deceptive amount of material required for a project of this scale

Howard Richardson, developer.

There is a deceptive amount of material required for a project of this scale. This diagram below illustrates what we needed:

This data was mostly split between config variables in the Javascript and individual JSON files, one per hotspot, which were loaded in as and when each hotspot was clicked. (Basically the hotspot names, coordinates and image filenames went in the config variables and everything else in JSON files.)

After I got the map working correctly, I swapped the static handmade JSON data files out for dynamically generated ones, using PHP and a MySQL database. This allowed for the stories and people to be easily stored and edited by Emily from a web back-end. I rustled up a super-quick administration for this using XCRUD. This is something which we already had a paid licence for, and as such, I can't share the code for the whole of the back-end. The licence costs $13, so if you're interested in the really basic code I made, you can purchase a licence and drop me a line and I'll send it to you. This database- driven and web administrated back-end for the JSON is totally optional however. You could just as easily write plain JSON data files by hand.

One of the limitations of the map in the end, which we initially hadn't planned for, was that the hotspots could only be rectangular. This allowed us to use simple HTML images inside linked anchors, instead of more complex options, such as SVG polygons or HTML image maps. The first prototype of the map handled the hotspots as SVG polygons, which allowed for a bit more flexibility but made defining the hotspots and making them respond correctly across all desktop and mobile platforms more complex. As a trade-off we opted instead for purely rectangular hotspots, which just needed an X and Y location on the map, and then the illustrator just needed to be careful to make sure than the bounding boxes of any clickable areas didn't overlap much. The code could probably be easily adapted in the future to support polygon hotspots, were this to be needed.

All the interaction in the game is driven by the GreenSock animation libraries

Howard Richardson, developer

All the interaction in the game is driven by the GreenSock animation libraries. These allowed us to do many things, including script an opening zooming introduction with a time-synced voiceover, and to make the map itself draggable - and using the extra (paid) ThrowProps plugin to have inertia. The opening and closing of the windows each time you click a hotspot is also done with a GreenSock animation.

It probably isn't apparent on first glance, but when you click a hotspot, you're playing back a GreenSock timeline. The zoom-in to the building and the "modal" window that overlays the playing field is all defined in TimelineMax. On a click we calculate a centre position for the building and move the map into this position, and from there the visibility of the modal dialogue layer is switched on. This together with zooming and "popping" effects on the images and window itself creates a lively, animated feel. The timeline then pauses while the window is open, and resumes when the close icon is clicked, basically undoing all the the animations which made the window appear in the first place, until it's all invisible again, at which point the timeline is finished.

The game was written to work for both touchscreen and mouse pointer

Howard Richardson, developer

The game was written to work for both touchscreen and mouse pointer. Initially I had wanted to make the code work the same with no special cases for mobile, but the click and hover handlers were causing problems on iPads, such as needing to click some links twice and introducing delays to touch response, so in the end I wrote the game to have two modes - a touchscreen mode and a mouse mode. Depending on how the START button is pressed - with a touch event or a mouse click -  it then selects the appropriate mode for the game.  Once you are in touchscreen mode, the links respond immediately when you lift your finger from the screen because they are bound to "touchend" events instead of "click" events.

I added audio to the game using the Howler.js library. We recorded voiceovers as MP3 files and then they were played and stopped at the appropriate points in the timeline or on the relevant click events, as appropriate. Because we also had some embedded videos, it was necessary for the videos and the narrations to communicate, so I programmed each one to stop, pause or fade-out as appropriate, so that you never got multiple voices playing on the top of each other. We also had some background music at the start to play behind the introduction, which we took from the creative commons music library that goes with Youtube. Having that music in the background really gave it a professional touch.

In the end, workflow constraints have meant that we have been unable to include audio voiceovers for every story. The stories are in a state of flux often, as they get refined and added to, so we will wait until the whole map is completed and things have settled down before attempting to record voiceovers for every single story.

Future sound improvements to the map might include options to fade out the background music if this proves to be irritating, and adding in some village background sounds, like people, cars and birds. I think that would add a lot to the atmosphere of the map.

I'm open to people contacting me with any technical questions they have.

Howard Richardson, developer.

Naturally I'm open to people contacting me with any technical questions they have. I'm happy to help explain the code or the preparation of materials. The easiest way to contact me is from my website.

Additional credits

  • GreenSock animation libraries. These are freely licenced, but we did make use of their extra paid "ThrowProps" plug-in which enabled inertia in scrolling and dragging. This is optional. Without ThrowProps dragging and scrolling just stops dead when you let go.
  • A wonderful piece of music from the Youtube royalty free music library: Lazy Afternoon Sun by Dan Lebowitz
  • On the back-end XCRUD to allow simple input and generation of JSON data from a MySQL database. XCRUD costs $13 for a licence but its use here is optional. You could input the data into MySQL with whatever other tools you have to hand, or generate JSON records yourself in other ways.
  • Howler.js library provided audio support, freely licenced under MIT licence.


Go back