One of the most powerful opportunities with Hive Mechanic is to respond to live events, such as:

• Weather – such as starting the game when snow first falls, or giving different dialog if it rained earlier in the day
• Pollution data – like if the particle count today is higher than usual
• Bus and city data/smart city APIs – like starting a game when the bus is just about to come, or giving a different clue after the bus departs, or giving a different line of dialog if foreclosure rates have recently gone up
• Yelp and business reviews – so that a game might challenge players to name the nearest Thai food restaurant, or agree/disagree with a recent review of a new business
• Home automation and Internet of Things APIs – like having the game give a different clue if the motion sensor in your home/library has been active in the past 10 minutes, or a light is off, etc.

Our demo: a weather game

We created a game to showcase how Hive Mechanic can respond to live data such as the weather. For example, what if your game dialog was cheery on sunny days but used more muted language on rainy days. Short answer: our “Data Query” card can check a 3rd-party API for the weather, and then we can use the “Variable Branch” card to branch our story in two directions.

Technical walk-through for the weather game

Below we use the Data Query card to look up the lat/long of our zipcode… and then use that to look up the weather in an open API. Note that this is a somewhat advanced example of using Hive Mechanic.

The Data Query card relies on third-party servers. First, we need to select a processor from a list of available services (to add an entirely new service or API, you will need briefly need ‘admin’ access to the Django backend of Hive Mechanic). To get the weather, we actually need to do 2 data queries, the first one to the Geocoder, and the second one to Open Weather, which actually gets us the weather. The data is stored in a variable, which can be 1 of 3 different scopes. Session scope only lasts for the duration of the game, which is good if you only want to use the information temporarily. Player scope is permanent for the phone number used to play, and Game scope stores the variable for all players.

Lastly, we’ll look at the Variable Branch (formerly Process Variable) card. This is similar to the Keyword Branch card, but instead of taking what the player texts, it looks at a variable, like the one we got from our data queries. Some cards let you decide the variable name, but data queries provide one themselves, which is openweather_weather_0_description for our example. You can add multiple patterns with this card just like the Keyword Branch card. For example, we give hint message 1 if the weather mentions rain, and hint message 2 if the weather mentions clouds.

That’s all the cards we want to showcase in this demo. If you run into any difficulties using data queries and variables, make sure your spelling is exact, and that the servers for the data queries are working.

How to ask people their location using zip code

_{Note: Game Over card now called End Session}

First up is the Keyword Branch (formerly Process Response) card, which determines which card to go to based on what the player texts. The format [0-9].* for our pattern is how you look for a number, since we want to know a zip code in this example. Each pattern can link to a destination card. For this example we only use one pattern, but you can add as many as you’d like to account for various player texts. There are also 2 special cases in this card. The pattern not found link is for when the player does not text anything that we expect. In this case, we ask for the zip code again if the player texts ‘banana’, for example. Finally, we have the timeout parameter, which happens if the player doesn’t interact with the game. A message card letting the player know of the timeout followed by a end session card can be a good choice for this.