Spatineo Blog and Knowledge Base Odysseus – A story about survival (using GIS)

“This is an automated broadcast on every frequency. The planetary senate has initiated emergency protocol ALPHA. Last night at 04:50 Ellarion Standard Time The Machines attacked. Every major city in Ellarion, Caelena and Osiris has been destroyed. The casualties are innumerable. Unfortunately, among the deceased is the honored Emperor, forever may they shine. On this day of sorrow, we have no time to mourn. We fight for our very survival. All ships: maintain radio silence and follow emergency protocol. If you are trapped on the surface, proceed either to the nearest shelter or spaceport. Use extreme caution. May the wisdom light your way. End transmission.

This is an automated broadcast…”

This is how the story of the Odysseus live action roleplaying game (LARP) began. ​Odysseus was a Finnish LARP for 104 players set in a world inspired by the TV show Battlestar Galactica. The larp was played in Helsinki in summer 2019 and consisted of three separate 48 hour runs.

Odysseus was the largest LARP production done in Finland by three main organizers: Laura Kröger (main organiser, story), me Sanna Hautala (software, story) and Antti Kumpulainen (practical, building the set) and over 160 volunteers. It had a budget of 80 000€ (mainly from the player fees) and it was done entirely as volunteer work. The idea first sparked in October 2016 and a year later the core team recruit began.

In the beginning we had wild ideas for set design and IT systems and we ended up executing everything we dreamed of and much more. We built (almost) a fully functioning spaceship in a school with a bridge, engine room, canteen, brig and security room, hangar bay, medbay and science lab with fully operational IT, sound and light systems.

  • A map of the ship (photographer: Henry Söderlund)
  • A corridor by the sleeping quarters (photographer:  Mira Strengell)
  • A mess hall (photographer: Minttu Hopeasuo)

In this blog post I will concentrate on how we used geoinformatics in this project, but first I will give a small introduction to the IT systems of our ship the ESS Odysseus.

The core was an open source spaceship bridge simulator called Empty Epsilon  (https://daid.github.io/EmptyEpsilon/), which took care of the close range travelling and space fights. All our self coded IT systems as well as the lights and sounds were integrated to Empty Epsilon through our backend. If the ship took damage in Empty Epsilon all our systems knew it – the lights and sounds would react accordingly and the engineers would be running around fixing the ship by performing small tasks which in turn would increase the health of the ship systems in Empty Epsilon.

  • Bridge (photographer: Ami Koiranen)
  • Info screen (Mira Strengell)
  • One of the engineering boards” (Mira Strengell)

Here is a short list of all the IT systems:

  • Empty Epsilon (https://daid.github.io/EmptyEpsilon/) for close range travelling and space fights (including customised mission scripts and custom ship 3D models)
  • The engineering system for fixing the ship and following the repair tasks (partly based on Open Source Mission Control Software by NASA, https://nasa.github.io/openmct/)
  • Digital and manual ship repairing games/tasks/control boards using NFC tags and Raspberry Pis
  • Reactor simulator by Helsinki Hacklab integrated as optimal jump configuration tool (https://wiki.helsinki.hacklab.fi/Reaktorisimulaattori)
  • LORA Science Voyager, a long range space jump and area scanning system
  • EOC DataHub, an application for communication, news, voting, ship/captain’s log, databases for personal/security/medical files and scientist artifacts with hacking possibility
  • SIP phone system for calling between rooms, calling integrated to EOC DataHub
  • Starmap used in LORA and EOC DataHub
  • HANSCA, a hand scanner (phone application) for medics/scientists/engineers for scanning injuries, artifacts as well as assist in the repairs of the spaceship using NFC tags
  • Mission tracker to track location during the land team missions
  • Discord (https://discordapp.com/) for real-time video broadcast system for land team missions
  • Info screens for distributing news, information, and warnings
  • Security room live video surveillance
  • Sound board for ship wide announcements
  • 2 airlock doors, one to hangar bay and one to outer space
  • 2 body scanners for medics
  • Light and sound integration
  • A tool for game operators to easily manage ship’s systems
  • A common backend for all the systems to ensure smooth integrations
  • Other small integrations

The planning and coding of the systems began about one year before and there were approximately 15 volunteers total. Setting up and testing was all done during the last few weeks before the games began. The most amazing part was: IT WORKED! Almost perfectly. Only a few small bug fixes and additions were made during and between the games. Hundreds of hours of blood and sweat went into the project and we are so proud of all the volunteers who made this possible.

For more information, visit our github page: https://github.com/OdysseusLarp

The starmap

Technologies used:

  • Spatial data creation – FME Home Use edition by Safe Software
  • Spatial data storage – PostgreSQL with PostGIS
  • Distributing and visualising the starmap – Geoserver

What would a spaceship be without a starmap? The only question was if we should use a known starmap or generate our own. Since the world was created by ourselves we ended up using an imaginary universe. We also realized that it would require an enormous amount of knowledge and time to recreate the known universe in a satisfying way.

The first task was to select the technologies to be used in creating the map and distributing it to the other systems. Because of the experience from PostgreSQL/PostGIS and Geoserver it only felt natural to use them in this project. EPSG:3857 projection was chosen because of the rectangular shape and because it would be easy to transform it into a grid of quadrants and sectors where the ESS Odysseus could jump from sector to sector.

  • Scanning celestial objects in a sector Alpha-5-C1-82 using LORA Science Voyager (photographer: Santtu Pajukanta)

All the spatial data was generated using FME Home Use edition by Safe Software since it was an easy to use and fast way to generate random spatial data. 

Here is a list of the spatial datasets which were generated:

  • The grid of quadrants and sectors with sub-sectors
  • Background stars “the stardust”
  • Stars, planets, moons, asteroids, comets, and black holes
  • Ship location (changed after every space jump)

The background stars were a set of random points all over the map area. For each star (point) a color, radius, and brightness was randomly generated so they would all seem a little bit different from each other. The attributes were used in geoserver styles to determine the appearance of the stars.

The background was the easy part and came what you first thought would be just more random dots on a map but when you really start to think… no, it isn’t like a sunny walk in the park. All the celestial bodies are somewhat tied to something. The moon orbits the planet and planet orbits the star and sometimes there’s multiple bodies orbiting multiple bodies. 

The key was to first generate the stars, then randomly select how many planets the star had and how many moons would orbit the planets. The orbiting distances were randomly generated but they did take into account the possible realistic distances (in relative measurements, of course). 

When you start to take a road towards the “almost realistic” you end up noticing the small wonders of the universe. The stars cannot be any color they want for example: they can only be from the range blue – white – yellow – red and they are classified according to their color. Also the other properties such as radius, mass, and temperature are dependent on the class.

  • Starmap inside EOC Datahub for all the players to explore (photographer: Mira Strengell)

Even planets, moons, asteroids, and comets have different categories which are determined by their properties. To be at least a little bit closer to reality all these had to be taken into account when randomizing the data. If I would do this again would I choose to generate all these different properties: category, color, mass, radius, surface gravity, temperature, atmosphere, atmospheric pressure, orbiting distance, orbiter count, orbital period, rotation time etc.? Yes, I would since it enriched the world for the players. It made it more real for them. 

Everything was designed to be proportional with each other and therefore some of the properties could be calculated, such as density and if the planet was located in the habitable zone. Geoserver styles could use the properties of the celestial bodies to determine how to visually show them on the map.

Long range space jump and area scanning system (LORA Science Voyager)

Technologies used: 

  • Application – Angular frontend, Node.js backend
  • Map component – OpenLayers

When you have a map, you usually want to track your location, plan your route, and explore the surrounding areas. LORA Science Voyager was designed to show the players the vastness of the universe where they were travelling. The smallest unit was one sub-sector, which was also the maximum range the space ship could travel during the space jump. The size of one sub-sector was about 2 – 3 light years – big enough to fit one solar system and its surroundings into it.

  • Planning the next jump with LORA Science Voyager, on the right Empty Epsilon Science Station (photographer: Mira Strengell)

There were three main functionalities in LORA: 

  • Showing the location of all the ships in the fleet (ESS Odysseus included) with accuracy of one sub-sector
  • Scanning the properties of the nearby celestial bodies (range one sub-sector)
  • Initiating the space jump (choosing the destination sub-sector) and engaging the jump after the engineers of the ESS Odysseus had finished the jump preparations

Basically LORA Science Voyager was designed to be the Google Maps of the future enhanced by long range space scanner probes and space jump capability. 

In technical point of view LORA was a very basic Angular application with an Openlayers map component showing the base map (starmap) and dots on a map (the fleet). All the data was stored in PostgreSQL/PostGIS and accessed via Geoserver and the custom Node.js backend used by multiple systems.

Why did we create all of this?

It all started with a dream to do something that had never been done before in Finland. We wanted to create a LARP where you could actually feel like you were on a spaceship (360 scenography) with working technology and practicals, not to forget meaningful story arcs and functional characters.

I have to admit that I never realised how big our dreams were and how much work we put into it until I saw a fully working spaceship set in action. At that moment you start to wonder, did we really do all this?

For me creating a good LARP means offering memorable moments and emotions you wouldn’t normally feel for the players – to create a perfect moment where you forget your everyday life and step into someone else’s shoes for a second. You get to see the other side of the coin and feel the hard choices you had to make to end up there. You can safely be anything you want. No bounds restrain you or your choices. You can see how your (character’s) choices affect the other players around you and shape the story of the game. It is a joy to provide all these possibilities for the players.

Here are a few of my favorite pictures and a video from the game:

Actual video footage from the first international game (the video is produced, filmed and edited by Valtteri Niskavaara)
  • The Machine boarding (photographer Tuomas Puikkonen)
  • Help! (photographer Tuomas Puikkonen)
  • Surgery (photographer Tuomas Puikkonen)
  • Fixing the jump engine (photographer: Ami Koiranen)
  • The engine room (photographer: Minttu Hopeasuo)
  • Creating new innovative ways to enrich “Araknium” (photographer Henry Söderlund)
  • Ship announcing system (photographer Henry Söderlund)
  • Miniature 3D model of the ESS Odysseus (photographer: Mira Strengell)
  • Ship status critical (photographer Henry Söderlund)
  • Technical problems, Windows update (photographer Henry Söderlund)

Additonal links and material:

A blog posts from the players: