Creating Asteroid.Ventures (Cosmosium) and Seeking Help to Expand!

A week ago, on Thursday April 10th, I was digging through the internet looking for material for a lengthy blog post  about creating distributed grid simulations with a hierarchical federated architecture. (Still working on it, the concepts aren’t all super new, but the combination of several different concept might be a powerful method.)

During this search, I came across a world-spanning competition called the NASA Space Apps Challenge. After reading a few of the mission goals, I knew then and there that this could be the time to shine. There were two primary challenges for which I thought would be worth applying to, both within the #asteroid category.

The title of our project was Cosmosium, inherited from a label I a mockup last summer. However, I later noticed that there already exists a French organization of the same name. It might be more fitting then to change the final m to an s, and to call the git page “Cosmosius.” This remains TBD. Later on however, I checked availability on the new gTLD, “Asteroid.Ventures,” and bought it immediately. It’s the perfect name for our little experiment!

Now before you read any further, go check out our WIP demo, Asteroid.Ventures or go straight to the github page and clone a copy. Give the demo time to load, the WebGL can be taxing. Eventually we will curb load time on the non-game pages by making a simpler scene and modularizing the JS libraries.

Now, here’s the story about how we came to create our work of art!

Picking a Challenge

• Asteroid Mission Simulator: Building an HLA compliant mission simulator with an active RTI for realism of scale and physics. Using an existing 3D graphics engine to handle the modeling. (Judged by 
• Asteroid Prospector: Develop a game to travel across the solar system going from asteroid to asteroid. The strategy is to decide which asteroid to visit and mine next, given a field of asteroids that vary in location, composition, size, and more. (Judged by Phil Metzger)

It had only been one week since I had revisited the concept of building an asteroid mining game in WebGL, as I discussed in this previous blog article. Already, my mind had been whirling on what a game like this should look like. It could function as sort of a meta-game, or empire builder, but focused on speculative science and hard science-fiction.

I also had been working with Magnetar Games on the start to a massive HLA compliant virtual world platform, also based in WebGL. However, progress on the Magnetar technology platform wasn’t yet sufficient to publish any result in the short time frame. So instead I had to go solo. I decided to trust in the power of  Reddit and recruit an open source team to rise to the occasion.

Gathering a Team & Picking Technology

Crowd-power worked! I found a group of talented and willing compatriots to help set about creating a web application out of nothing. All it took was a post on /r/Simulate and /r/Futurology to raise a few heads. I am deeply grateful to the volunteers who helped shape and lead this project with me. Foremost, I want to thank Tylar Murray for his work in getting the web framework operational, and Daniel Andersen for building such a beautiful WebGL render!

We started with a discussion thread but quickly moved to live chat. It was paramount to start the discussion early enough to have a technology strategy.

Our initial plan was to take bits and pieces from several existing libraries in hopes of finding compatible layers for our application. Like most other teams competing, we were all enamored with the Asterank API, but soon found direct query access to JPL Small-Body Database. For the web platform, we had initially been considering using the MetaSim Component libraries found in WebHexPlanet.

The ideas was that we could use the SailsJS MVC to build up templates and host on a NodeJS server, then concurrently we would run a Python based server which had the barebones of Asterank running, but using Bottle.py to write a mirrored MetaSim API to pass asteroid data to the NodeJS server. The architecture in question would function as:

MPC_Data =API=> Asterank_Cloned_Server(No graphics) <=MetaSim_API=> WebsiteMVC <=RESTful_Client=>Your computer

Then we unfortunately lost our dedicated SailsJS architect, but between our group, we had enough modular web experience to take an alternative strategy with Python as a webserver. We stuck with Bottle.py instead of Flask or Djiango since we already work started with Bottle and the routing capabilities seemed nearly the same in terms of capability. There are a ton of Python frameworks to choose from!

 Solidifying the Expected Product

Before we had even decided on our final stack or library choices, we needed to determine what the overall scope of the product would be. We were still undecided as to whether we would strictly build a game, or if we would instead try to create an HLA compliant simulation. What it boiled down to however, was whether or not our PhD student team member could get university level access, and if we would even have time to incorporate those IEEE standards into the project. We decided to leave it as a secondary concern which proved wise.

Then at 4 PM EDT / 1 PM PDT, there was a Q&A session with the Expert Panel on the Asteroid Challenges for the SpaceApps system. I got on early, and made sure to ask a deciding question to determine the scope of the project. At around 27:00 minutes, Daniel O’Neil and Phil Metzger were able to answer some of the questions we had.

Brainstorming and Getting Started

On Friday night, the eve of battle, we held a Google+ Hangout to try and decide the best approach for crafting this dream-game of ours. We started discussing who knew how to do what, and envisioned what the final scope would be. We determined that we wanted to stick to the game concept and use WebGL for visualization with a Bootstrap admin theme for the front end.

Things got a little animated for a bit though when Collin of the StableOrbit library put on a full body Viking costume and challenged he would be parting ways, that he would “meet us on the field of battle!” Alright, we liked the guy and his amazing n-body work, but we had already spent time planning a WebGL deliverable based on Keplerian data with real world orbital elements. I would love one day though to use his work to model procedural solar systems! It would be an amazing component library for the MetaSim Framework!

Kick-off!

Saturday morning finally rolled around. To culminate the fruits of our discussions, we created a Google Docs folder and drafted a Project Roadmap. I drafted some initial mockups while Daniel got the webGL scene initialized. Before we started laying the framework for the technology, we would need to determine the function and gameplay elements of the overall product. Here’s some of the initial designs we had to work from.

Early Implementation

Without our web expert handy, Tylar and I took to getting an instance of the server up and running. Our first line of decision making was to determine the best development environment possible. Would it be better to do live edits together with a service like Cloud9, or should everyone make independent commits on local copies, then pushing to the repository?

We toyed with Cloud9, but ultimately had little use for it. It was much faster to throw a backbone routing example up for “app.py” and then start adding new segments to the production as needed. We stayed in constant contact on Google chat, to make sure no redundant work was undertaken.

We had by this point settled on Bottle.py for the reasons mentioned above. It might not have been the smartest decision, but for first time Py-web work, it would get the job done. (I had used Bottle once before, but only for static routing on a basic SPA.) So as our work flow progressed, I worked on getting setup on AWS-EC2 while Tylar put together some design specs on the build we would create. Here’s his rough model of how the asteroid server was planned:

WebGL & Orbital Mechanics

Daniel jumped quickly into the process of creating the webGL scene in ThreeJS, our favorite library on r/Simulate! We took most of the orbital element mechanics from Asterank, but added a ton of new visual components. What we found to be rather tricky at first was the math involved in calculating the orbits. Of course, we all had some experience in astronomy, I myself had been digging up old textbooks the night before. What was tricky was getting the conventions and variable names right between the various data sources and the physical equations. The hardest parts to tell apart between sources and the Asterank model was the differences between Mean Anomaly, Mean Longitude, longitude of periapsis, and argument of periapsis.

Fairly quickly however, we were able to model the Keplerian orbits with the same functions used in Asterank scene, but reworked a bit to handle data in the way we wanted it to. Also, we had expanded on the display by adding spherical models for asteroids,  planets, and later for large moons. Initially the asteroids were all spherical, but then Daniel created ellipsoids with 3-axis values and added size and brightness constraints based on diameter and albedo data provided from the MPC. Then he threw in a GLSL shader that sat on top of the JavaScript which added Gaussian noise to the vertices of the asteroid spheres. This is what gave the asteroids their “popcorn” style appearance, albeit at the  cartoon style scale we were aiming for initially.

(Here’s a picture of the asteroids before given the noise shader.)

Headache with Templating

It was about this time I realized that the site pages themselves would need to have page templating added in order to be resuable. I had a theme picked out prior to everything, but realized on the day of production that we couldn’t use any of the themes I’d paid for because we needed to develop a project under open license in order to compete. So after considerable digging I found one under MIT license called AdminLTE by Almsaeedstudio.com. Go check out his stuff, I love his work! He even had the fake user as “Johannes Kepler!” Coincidence?

In any case, it was best that we found a theme which didn’t have templating. Most templating takes place in PHP, something that neither myself or Tylar felt up for learning on such a short basis. Not that I have anything against PHP, version 5 has really added quite a lot of features. My blog runs on it, I just find it a tough language to immediate jump into and pickup what’s going on. I think it’s mainly due to how functions are scoped, and just a lot of static syntax I don’t quite get.

After some time, Tylar figured out how to get the templating working such that the navigation menu could be reusable and have variable data inside. There’s still a ton of non-routing restful work that needs to be done to imitate anything approximate to an MVC… But hey, our project needs so much custom work to integrate with the WebGL scene that it’s probably best to start with something clean and easy to understand with a simple framework like bottle.

Early Quick mockup of what the site UI could look like based on an older template.

The Purpose of the Game

I almost feel like I will need to create a separate post at a later time to describe all the intimate design mechanics we’d like to throw in to the game. However, I’ll give a quick synopsis. Firstly, the player would be acting as the leadership team of either a single division within NASA, FKA (Russia), or ESA, or as a private space company trying to establish an asteroid mining presence and to build space infrastructure. The WebGL scene would depict missions and zones of control based on a user assigned color.

If it were entirely possible, we would have the game split up into several different phases:

1. The NEO capture phase: where players invest in detection equipment to find NEO’s, then develop rendezvous+capture technology to retrieve the asteroid either robotically or with a manned mission. Rare metals are transported back to earth, but the remainder is kept in space, and the player will then get to create infrastructure in LEO, lunar orbit, or on the lunar surface.

2. Expansion into the Main Belt (and past it): After building up surplus of material and infrastructure in the Earth-Moon system, the player can then launch missions to either retrieve material or establish bases in the main belt or Mars. The goal here is to have enough manufacturing presence in the Earth system to be able to send manufacturing to the Main Belt, Mars, and the Jovian Moons.

3. Seeking Victory: After establishing robotic colonies across the solar system, players could then invest in building human habitation. Or they could focus on science missions to search for new discoveries or to setup shop in the outer solar system. (Saturn, Uranus, Neptune, TNO’s and Kuiper Belt). Or they could focus completely on gathering enough anti-matter to power a trip to another star system.

The Player Interface

The players would be able to push through these phases using the command interface available to them. It would be similar to the text based space empire games from 10 years ago, where a player would make decisions in the pages available, but now they’d be able to see their strategy unfolding in real time WebGL. Each of the pages could have it’s own set of responsive elements and crafty JavaScript interactive components. Here are the menu elements we had currently brainstormed:

• Dashboard: The overview page, with “sit-rep” (situation report) and as many active measures as possible. It would list an overview level of your active resources and current research.
• Solar System: This page shows the visual depiction of the solar system and all detected asteroids. This might eventually cover the hundreds of millions of objects, but for now our volume is in the tens of thousands. We will eventually offer two views, “real scale” and “fun scale” and possibly a dat.gui slider for ranges in between. We also will eventually have space probes depicted  with planetary rendezvous shown. Lot’s of features yet to add! This is the primary visual  game engine.
• Missions:
  • Mission Control: An overview page of all active missions in the solar system. It will offer tables for tracking status on individual missions, and will show available new mission “challenge” to accept in whatever order seems most reasonable to the player.
  • Launchpad: Here the player will configure either generic missions, challenge missions, or science missions. Configuration will include number of phases, location of launch (either Earth based or otherwise), types of instrument packages, types of space propulsion, and other varieties of mission components. (We might later split Launchpad and Mission Design into two pages.)
  • Observatories: The player would need to invest in observatories in order to detect new NEO’s. This would include robotic optical arrays, space based optical and Infrared, large observatories with medium range spectrographs, radio arrays, or buying time on existing observatories. We might even eventually add observatory controls so that the player could simulate an observation run.
  • Timeline: Missions take time to run. The player should have an interface to plan their launches based on optimal orbital alignments to make sure the change in velocity has lowest energy requirements. Moreover, it would let the player plan multi-mission development strategies.
• Targets:
  • NEO’s: The player would have a set of tables, filters, and visualizations which would let them decide on what NEO’s would be optimal targets. The number of available targets on NEO’s would increase based on the actions performed in the observatories section.
  • Main Belt: Less likely to be impacted by observation. The Main Belt would be sort-able by asteroid family, expected asteroid type (chondritic, achondritic, stony or iron), or by estimate metal or water abundances. The player could target different types based on necessity, or else go after larger asteroids to establish a more permanent presence.
  • Planetary: Long term it would be awesome to add planetary targets as viewable regions within the main scene or as separate scenes based on Cesium. For now though, we would like to have the moon, Mars and other planets/moons be accessible as either targets of industrial or science missions. Build a lunar space elevator for easy slingshot missions to the rest of the solar system. Or start sending colonists to Mars. Start a base on Io and then launch a fleet of drones to collect anti-matter for your interstellar mission.. Etc.
  • TNO’s + Kuiper Belt: Create quiet outposts in the deep, bringing the secrets of fusion with you to make sure you never run out of energy. Set up shop on Pluto, Charon, Sedna, or any number of hidden objects in the far reaches of the solar system. Why? Tons and tons of science points! You’ll likely find a lot of presolar volitiles and other useful stuff!
• Research: (Tech-Tree components)
  • Space Industry: More or less self explanatory. One of the biggest challenges of material recovery in space is going to be the engineering problems. Spaced based material centerfuges, volatile plasmagasification, 3D printing, in-situ parts manufacture, space elevators, solar energy collectors, asteroid capture techniques.
  • Propulsion: Getting from point A to point B is harder than it sounds. Should you use hydrazine, ionized xenon, hall effect, VASIMIR, solar sails, directed beam momentum transfer, or just straight up liquid hydrogen+oxygen? Players will need Earth launch engines, interplanetary engines, and engines easy enough to build from material found in space
  • Human Habitation: Living in the irradiated vacuum of space is crazy challenging. Lots of life science and ecology study is required in order to setup colonies on the moon, Mars, or any number of artificially constructed outposts. There are two sides to the research, the biology part and the space engineering to create false gravity.
  • Robotics & AI: Humans won’t conquer space alone, most of the grunt work is robotic. Self-navigation like Deep Space 1 or the Curiosity rover should be studied in depth, but applied towards truly automated industry. For reconfiguring a massive asteroid in the main belt into an actual habitat, players will need nearly self-aware robots to act autonomously to bypass the speed of light problem. Imagine swarms of insect like microships ferrying raw material towards processing centers and hauling away large sections of livable habitats.
• Economy:
  • Launch Systems: (Maybe rename to Aerospace Market): This is where the player gets to manage the relations with component vendors necessary to build the space missions. In the early game, most components will be bought from a list of vendors using earth based currency. As the game progresses, players will be able to purchase components directly with the materials in their possession, (or barter with other players once MP is added.)
  • Resource Market: The rudimentary Buy/Sell/Trade section of the game. For the early game, the player will need to have capital to spend on Earth launch fuel. Or they may need certain metals to produce custom components. Once asteroids have been captured however, players will use this page to sell their recovered resources from space to pay off their debts.
  • Fuel Network (in space): This screen would be used to show the flow of resources throughout the solar system. How much material of different sorts is flowing in/out of each outpost, object or colony. Is Rubidium being transported from 2001 HA8 to the the moon? Should it be sent to Mars instead? How much fuel is needed to shuttle cargo between different orbits? The player should optimize for minimum energy cost.
  • Space Tourism: Easy to understand, and easy to make money in the early game. In the later game, investment into space tourism may help spur the development of more colonies which will boost research points.
• Policy:
  • Outreach: This is where the player needs to create events and programs to communicate the benefits of their space ventures and the science resulting from it. Invest in school programs, hack-a-thons, museums, science centers, film/multi-media. This page is super-meta…
  • Government: How does your organization work with the government? If you are playing as an agency, you need to influence politicians by incentivizing to create jobs in their districts. If you are playing as a mining corporation, you need to lobby or bribe congress to have superior tax breaks. Tread carefully though, poor choices in this screen could potentially end the game or cause the player to relocate to a different country. In the late game, the player might have to deal with the possibility of your rogue AI establishing an independent state in space.
  • Organizational: Also depends on whether you play as government or a company. You either have agency charters or corporate policies which will boost either research speed, production values, or spacecraft component costs. Choose wisely, these “cultural” decisions will impact a players speed at different phases in the game.

 

State of the Project & Expected Future

My collaborator Tylar put’s it best: “Don’t underestimate the power of Galton’s Ox!”  That is to say, don’t underestimate how much amazing work can be accomplished by a few driven people in a short amount of time, even if a few set of skills needs to be learned on the fly. Amazing things can happen!

Our project in it’s current state can of course be seen on asteroid.ventures, but of course if you’re reading this months from now, hopefully things are improved a bit from when I wrote it. Currently we have page templating and a really good WebGL start. We have data handling but not much yet in terms of storage. We are working towards having integrated DOM controls for triggering events within WebGL, but first need to restructure the scene into component modules in order to have different pieces get dynamically called.

It might also be awesome to incorporate Cosmosium with the MetaSim API. Aaron Santos’ work on the RESTful client between simulation components would be amazing to add if we had the time. The downside on this is that all of the work and the entire WebGL scene created for WebHexPlanet was crafted for a NodeJS project. Which means either we would need to rebuild sections of the API to work in Python, or else migrate all of the templating work we’ve done into the existing Node Project and forsake Python.

Now it’s tough to tell where the application will move from here. That depends on the resources which are opened up to us and the amount of time Tylar, Daniel and myself will be able to commit. If we can get other Python, Javascript, HTML5+CSS devs interested in shaping our repository, things will move more quickly. If we are able to find a grant to expand this project, it will be easier to commit to full time, and we can hire an awesome artist to help with fleshing out the technology tree or any 3D modeling of spacecraft/stations.

Irregardless, it’s been a fun run! Look forward to seeing some more posts on this soon, from me and from Daniel on rSimulate.com or on Asteroid.Ventures directly. Lastly, I leave you with the 30-second video of our project which I had to throw together in 2 hours on Sunday the 13th. Enjoy and happy hunting! Don’t forget to share and retweet this blog to help the project!

http://ift.tt/1jvRq3R http://ift.tt/1jvRoZV Asteroid Mining, Blog, Futurology, Gaming, Project, Projects, rSimulate, Science, Simulation, Space Science, Space Travel, Technology, WebGL, asteroid, asteroid mining, asteroids, astronomy, AWS, bottle.py, browser game, cloud9, collaboration, daniel, EC2, educational, futurology, game, game design, github, HLA, international, ion propulsion, javascript, Kepler, metasim, mongodb, NASA, open source, orbital mechanics, python, rsimulate, RTI, space science, spaceapps, spacecraft, strategy game, tylar, virtual team, webgl