Windows Mixed Reality users seeking to play the “Snapshot VR” SteamVR app using Reverb G2 / HP Motion Controllers will be able to locate the functional bindings profile I created using the following guide:

Step 1: After launching into SteamVR and starting the “Snapshot VR” application, open the SteamVR ‘Settings’ menu and select the ‘Controllers’ tab

Step 2: From the ‘Controllers’ tab, select the “Manage Controller Bindings” button

Step 3: Toggle the ‘Active Controller Binding’ setting to “Custom”

Step 4: Select the “Choose Another” button

Step 5: From the ‘Edit Controller Bindings’ screen, select “Snapshot VR”

Step 6: From the ‘Change Bindings for Snapshot VR’ screen, locate the ‘HP Motion Controllers’ custom bindings profile and select the ‘Activate’ button

These bindings will become the default for Snapshot VR in the next WMR SteamVR Bridge update. We’ll also be receiving a dev kit for the HP Reverb G2 so that we can test any further customizations. Thanks to our impacted players for being patient as we sorted this out!

Join us in Discord to let us know how it works!

Guide: HP Reverb G2 Motion Controller Support for Snapshot VR was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

It has been a heck of a year for Snapshot VR. We transitioned from alpha to beta to early access, and have now been live on both Viveport and Steam for just over 4 months.

We gathered data from our kill metrics datastore, which is stored in AWS DynamoDB, as well as from Github, Discord, our Changelog, and various other sources to put together as comprehensive of a lookback as possible for the previous year. Some of the numbers that we pulled are still shocking to me and Tanner. It has definitely been humbling for us to see our passion project become what it is today.

Let’s start with our beloved Community

We started 2020 with just over 200 Discord members, and today our community is 870 members strong, a growth rate of 335% over the year. That’s pretty cool.

We’ve seen over 1300 Snapshot accounts created and our daily active user base increases by about 10% monthly. It can be a grind to build a community for an early access game, especially a VR early access game, but we’re fairly happy with the pace so far.

We also entered the esports scene as the 6th game to join the VRML with a 9 week pre-season. There are currently 13 active teams of 3–4 members each going into our 7th week and the standings are as follows:

1st — Underdogs
2nd — Birthday Snatchers
3rd — Serial Chillerz

We, of course, couldn’t manage any of this without our mods. Thanks to Shiva, TickleMeElmo, Chillswitch Engage, Albifons, and Bushido for keeping this thing alive.

Tournaments

We saw 2 community-organized tournaments take place in 2020, each with their own format and rules, and with their own version of a prize pool. All in all we gave away roughly $500 in prizes this year to tournament participants.

Viveport Open
August 5th
3v3 Format
7 Teams
1st — Underage Ballers
2nd — Eastbound & Down
3rd — Blaze

Steam Open
October 3rd
5v5 Format
7 Teams
1st — Mod Squad
2nd — Team Breakfast
3rd — Blaze

Marek’s 1v1 Tournament didn’t make the cut by just 2 days, but we’ll make sure to include that in the 2021 recap.

The game changed…a lot

I think most of our alpha and beta players would agree that Snapshot is a different game than it was a year ago. A year ago Joystick Locomotion didn’t exist, players were getting stuck above the field, guns disappeared from your hands or holster randomly, players could keep shooting after they died, and there were only about 5 hand-crafted maps in the game.

Scrolling back through the git history, I counted 31 significant features that made their debut in Snapshot this year. I won’t list them all, but here are some highlights:

• Stat tracking with Snapshot accounts
• Custom maps with the 2D Paintball Field Creator
• A complete netcode swap, taking 3 months of dev time
• Voice chat
• Competitive mode
• Spectator cam, with all the bells and whistles
• Bots
• And so much more…including the all-knowing Ref Bot

Tanner and I released 56 versions of Snapshot (starting at v1.2.4 and ending on v2.2.15). We made 705 code commits, adding or changing 13,047 lines of code across 274 files. The game systems with the most changes this year were:
1st — The Game Server / Game Loop
2nd — Bot Infrastructure
3rd — Voice Chat

Arenas

We released support for user-created maps in March. Since then, we’ve seen matches on over 150 custom maps, including revisions, settling at 116 maps currently playable in the game today.

NXL Spain 2020 is by far the most popular map, home to 539 matches and 15,767 kills. NXL World Cup 2020, MPPL Event 1 2020, and GZ’s own “Holidaze” 5 Man maps were all in the top 5 of both categories as well.

The Gameplay Data

Very early on we started collecting basic player and position data for every kill that took place on Snapshot servers. We added to this data over time, which has let us pull some pretty interesting metrics from 2020. We’ll explore some of this data here and hand out some superlatives as well.

Let’s start with the high level. In 2020 our players logged 197,555 total kills within 7,572 matches. Our Top 5 Killers (not including bot kills) are:

Shiva — 7408
Foxkru — 5837
Marek — 5558
Bushido — 3409
Chillswitch Engage — 3127

Bots

We introduced bots to the game in October. While we filter these out from the SnapshotVR.com leaderboards, we still have the ability to include or exclude them from our ad-hoc queries.

Bots have had quite the run in the few months they’ve been alive. Bots have been killed 41,219 times by players while racking up 14,055 kills of their own. We also see plenty of bot vs. bot violence, where bots have killed each other over 50,000 times. Our most dangerous bot is “Bot 5”, who has over 7,000 kills by itself.

A lot of players practice or just spend some recreational time in the game playing bots, so we have to honor our Top 5 Bot Killers as well:

Marek — 2319
Fab — 2281
Leybron — 1479
gzinthehood — 1355
Uncle Randy — 1266

These players are the ones starting rooms and getting games going, so we really appreciate this crew.

Backstabbers

We started penalizing Team Kills this year, and it wouldn’t be a complete recap without acknowledging the worst offenders of Ref Bot’s favorite penalty.

Thankfully, we only saw 2978 team kills this year, about 3% of total kills excluding bots. Our Top (or bottom?) 5 Team Killers were:

Foxkru — 133
Chillswitch Engage — 103
Bushido — 85
Marek — 76
Uncle Randy — 64

Headshot!

In November we started tracking which collider was impacted to trigger each kill. This was to support the on-field and on-body hit visualizations that we released, but it also allows us to pull metrics about which parts of the player are hit most often.

The Most Often Hit Areas are:

Chest — 38.97%
Head — 12.52%
Left Thigh — 8.9%
Gun — 5.72%
Right Thigh — 4.87%

Our Least Often Hit Areas are the feet and, hilariously, the ball ends of the headbands that give the headbands physics , which were hit 59 times between the two tails. Notably, the pumpkin head Halloween cosmetic got shot 513 times.

The player with the most confirmed headshots so far is Czechmate with 390 headshots. Excluding bot kills, Marek leads with 214.

This is what we’re able to take away from our 2020 data. Again, we’re very happy with these results, and just pleased that we have the data to understand our game at this level. Have ideas for what we should track in 2021? Let us know in Discord.

Thanks for an amazing year!

• Jesse and Tanner

P.S — Blue team best team. Blue team accumulated over 30,000 more kills than the Pink team in 2020. So that’s settled… ;-)

Snapshot VR Year in Review — 2020 was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Setup

This tournament was made up of 7 teams of 3 playing a double elimination bracket — all matches prelims through finals taking place on the same day. We got it done in just under 4 hours.

For each match, teams played a best 2 out of 3 maps, where the first team to win 5 rounds claimed the map. We saw everything from 5–0 2 map blowouts to 4–4 clutch points on the 3rd map.

The full VOD is up on Twitch, and will be reuploaded to Youtube soon.

The Maps

All maps were custom made by our community member and mod Shiva Soldier. He put special blocking walls at each pit as well to eliminate ghosting from the dead box.

Map #1 — Xball

Map #2 — Super Lanes

Map #3 — Offseason

Prelims

The prelims had a few surprises in store.

Blaze, a group of our newest members (friends from the VRML) had a strong showing in match 1, barely losing to team Tri-hards. Blaze would go on to perform very well in the losers bracket, making it all the way to the losers bracket final, where they lost but secured a 3rd place spot and a share of the prize package.

NashGameDev, a personal favorite, is made up of other game developers in or from the Nashville scene, including SirCrocketz who made the sound effects for Snapshot VR. They dropped 2 quick matches but tell me they had a good time along the way.

Finals

The real story here is with our finals teams — Eastbound & Down and Underage Ballers. Each playing very well in prelims until facing each other — where Underage Ballers was able to scrape by and put E&D in the losers bracket. These teams have good stories. Underage Ballers, as their name might imply, is made up of some of our younger (but most experienced) Snapshot players and has players from the US and Norway. E&D has players in the US, Japan, and Australia. Shout out to our international players for playing at very odd hours and at less than perfect pings, but still making it to the finals.

E&D winning the losers bracket means they needed to beat Underage Ballers twice to secure the championship. And they nearly did just that.

You can watch both finals matches on Twitch here.

The first finals match had Underage Ballers taking map 1, E&D taking map 2, and it coming down to a 4–4 on map 3. Eastbound & Down was able to take the last point and reset the bracket — setting us up for a second finals match.

The second finals match was nearly the same story, all the way to a 4–4 on map 3. Check out the final moment of that 4–4 point:

Final Standings

1st. Underage Ballers
2nd. Eastbound & Down
3rd. Blaze
4th. str8shooters
5th. Pod Chiefs
6th. Tri-hards
7th. NashGameDev

Prizes

3rd Place — Each team member received a variety pack of Snapshot VR and Giant Scam stickers.

2nd Place — Each team member received their choice of a Giant Scam or Snapshot VR t-shirt

1st Place — Where the real money (figuratively speaking) is at. Each team member got to choose between a custom printed Savage Paintball board or a VR gun stock.

What’s next?

Join our Discord to be the first to hear about our next tournament. We’re announcing the dates this week!

Thanks to all competitors for a heck of a first event. Looking forward to many more!

Snapshot VR Viveport Open Recap was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using our integration with 2D Paintball, you can now add both moving and stationary targets to training maps in Snapshot VR. Use these bots to practice laning and snap shooting in single or multiplayer.

This implementation is a stepping stone to fully functional bots, and we hope you find it useful for practicing in the meantime.

For more information on creating layouts for Snapshot VR using 2D Paintball’s Field Creator, see our previous guide.

To get started, you have two options.

1. Create a new layout in the 2D Paintball Field Creator
2. Import an existing layout into the 2D Paintball Field Creator by pasting the contents of any2dp_layoutname.arena.json file in the StreamingAssets/ directory of your Snapshot installation into the Map Data field under Advanced Options in the Field Creator

Once you have the bunkers arranged to your liking, you can take advantage of the Bot Positions feature of the Field Creator.

Selecting Bot Positions gives you similar options as when placing a bunker. You can set the position on the field, set it to mirror, and set some other basic parameters. This option will place a small green object on the field to represent the bot position.

Placing these on a layout created in 2D Paintball and importing into Snapshot VR will set the positions as expected, as long as you adhere to the following:

1. Any map with bot positions must have the file name formatted like so:
   2dp_trn_layoutname.arena.json
   Where ‘trn’ here stands for ‘training.’
   This will guarantee bots to spawn appropriately when the layout is loaded, and will show the map separately from standard maps in the in-game UI.
2. The type parameter is extremely important for bot placements.
   A type of Crouching will create a stationary bot for practicing snap shooting. This bot will spawn in the set position and stay there throughout the round.
   A type of Stand up (the default) will create a bot that will break out from the start station and move to that position as similarly as possible to a real player. This is ideal for practicing laning and shooting off the break.

If all goes well, you will now have your training layout listed in the Training Layouts UI after you’ve created a new Room.

Your training bots will respawn each round. For moving bots, they’ll reset and make their breakout move repeatedly throughout the round. So, you can get a full practice session in without ever pressing the buzzer to change the round if you’d like.

Shooting a bot will give you feedback in the form of the classic bell ding you hear when you get a kill in a normal match as well as the kill flash effect at the position where the bot was hit.

And that’s it! Let us know in our Discord if you have feedback or suggestions!

Training Mode — Adding “Bots” to Snapshot VR Custom Maps was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

This means you can register with your email address and set your Player Nickname and Icon in your Snapshot account. This account will be accessible regardless of which VR platform you are on, so you can have all of your tracked stats, cosmetics, etc… in one place.

Today, we are only launching the Nickname and Icon features, but this account will be the destination for all new features going forward.

Registering and Logging In

www.snapshotvr.com now has a login button:

This takes you to a login/register form:

Where you can set your email, password, and default Nickname. This Nickname can be changed any time by logging in to your Snapshot account.

Registration can also be completed entirely in VR. We have a VR-compatible keyboard now to make that easier:

Note: You can still use your PC keyboard once you’ve clicked into these form boxes. This makes things like pasting a complex password much easier.

Enter your email and password, press Login, and you’ll be connected to our network. This will let you view/edit your selected cosmetics, change your Nickname, view the server browser, etc…

If you encounter issues, let us know in our Discord! Thanks!

Snapshot VR Registration was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

Through a collaboration with the creators of 2D Paintball, you can now export fields created with 2D Paintball’s Field Creator into Snapshot VR. The field formats between the two games are very different, so we’ve created this guide to help you choose the right settings and set the right parameters on your 2D Paintball bunkers so that they load in Snapshot correctly.

If you’re interested in playing Snapshot VR during our Alpha (which is free) or just following along — join us in our Discord, which you can find a link to on our home page http://www.snapshotvr.com. Also join us on Facebook, Instagram, and Twitter @giantscam.

Using this guide, I was able to take the 2020 NXL Spain layout:

Map it in 2D Paintball, which took me about 30 minutes:

And immediately upload into Snapshot VR:

2D Paintball is a web-based 2D multiplayer paintball game. You can also support the 2D Paintball developers by buying their game on Steam.

It has a built-in 2D Field Creator that you can access like so:

1. Go to http://www.2dpaintball.com/
2. Create an Account
3. Log In
4. Click the green Field Creator Button in the 2nd header bar next to Leaderboards

Check out this video demoing the Field Creator to learn more about how it works.

Using 2D Paintball’s Field Creator with the specification in this guide will give you a field that is compatible with Snapshot VR.

Exporting from 2D Paintball

When ready to test your field, do the following from within Field Creator:

1. Click Advanced Options near the bottom left of the Creator.
2. Copy the text in Map Data.
3. Save text to a file named 2dp_<filename>.arena.json. The preface 2dp_ is what tells Snapshot to use a different format than our usual Snapshot arena file.
4. Move the file to the SnapshotVR_Data/StreamingAssets/ folder as if you were installing a typical custom map. The file will be converted on load.

2D Paintball Field Settings

Field Size: 1500x1200 — This will get you the NXL grid as well as Snapshot’s (50x40 size) grid.

Name, Turf Style, Colors, Darken, Dest: Any, these are not used by Snapshot VR

Team Size: 5

UPDATE: Thanks to our community mappers foffles and Fab we now have an NXL template that you can paste into the Map Data field in the 2D Paintball Field Creator.

That will populate a 2D Paintball field with the default set of bunkers for an NXL layout.

Which translate to these bunkers in Snapshot

2D Paintball Bunker Settings

Mirror Bunkers

In the creator, Mirror Bunkers will create two objects mirrored across the two sides of the field going left to right. It will store both bunkers individually in the file, so creating with or without the Mirrored Bunkers setting should work fine.

Snap Bunkers to Grid

This is recommended to be ON, as it standardizes the possible positions of the bunkers in the file. You can experiment with this setting off, but it may have undefined behavior.

Note on Axes

The width axis is the x axis that goes across the field left to right.
The height axis is the y axis that goes across the field bottom to top.

Note on Starter Bricks (Spawn Points and Buzzers)

Snapshot will add a Starter Brick automatically at the position that fits 1500x1200 (50x40) arenas for 2D Paintball arena files.

Bunker Mapping

This mapping is compatible with Snapshot VR Version 1.2.5 and greater.

This mapping may be tweaked based on community feedback. Mapping will be updated here as necessary.

DEFAULT values are the initial values per bunker type in 2D Paintball. They are called out to indicate which values can stay the same after placing the bunker in 2D Paintball. We had to use a lot of parameters to go from the default set of 3 2D Paintball base bunker types to our full bunker set in Snapshot VR.

A more readable version of the mapping is kept in this Google Sheet.

Can

2D Paintball Parameters
Type: Barrel
Radius: 20 (DEFAULT)
Standup: Checked (DEFAULT)

Pylon

2D Paintball Parameters
Type: Barrel
Radius: 10
Standup: Checked (DEFAULT)

Column

2D Paintball Parameters
Type: Barrel
Radius: 10
Standup: Not Checked

Box

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 35 (DEFAULT)
Size(height): 35 (DEFAULT)
Standup: Checked (DEFAULT)
Rounded: Not Checked

Small Box

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 20
Size(height): 20
Standup: Not Checked
Rounded: Not Checked

Brick

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 15
Size(height): 100
Standup: Not Checked
Rounded: Not Checked
Note: This is typically what we use for snake beams since they are a bit taller for our avatars

Giant Brick

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 35 (DEFAULT)
Size(height): 100
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

Brick 2022

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 40
Size(height): 60
Standup: Checked (DEFAULT)
Rounded: Not Checked

Brick 2022 Upright

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 40
Size(height): 45
Standup: Checked (DEFAULT)
Rounded: Not Checked

Snake Beam

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 15
Size(height): 100
Standup: Not Checked
Rounded: Checked (DEFAULT)

Large Temple

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 35 (DEFAULT)
Size(height): 35 (DEFAULT)
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

Small Aztec

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 35 (DEFAULT)
Size(height): 35 (DEFAULT)
Standup: Not Checked
Rounded: Checked (DEFAULT)

Giant Wing

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 45
Size(height): 45
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)
Note: Giant Wing and Giant Wing Flat have a default rotation to where the lower tapered side of the bunker faces the dorito side (top of Field Creator box) of the field. Rotate in Field Creator as necessary.

Giant Wing Flat

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 45
Size(height): 70
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)
Note: Giant Wing and Giant Wing Flat have a default rotation to where the lower tapered side of the bunker faces the dorito side (top of Field Creator box) of the field. Rotate in Field Creator as necessary.

Wing 2022

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 40
Size(height): 60
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

Wing 2022 Upright

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 40
Size(height): 45
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

A

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 35 (DEFAULT)
Size(height): 140
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

W (Wall)

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 35 (DEFAULT)
Size(height): 135
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

Mini X

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 20 (DEFAULT)
Size(height): 50
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

Mini W

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 20 (DEFAULT)
Size(height): 50
Standup: Not Checked
Rounded: Checked (DEFAULT)

Mini A

2D Paintball Parameters
Type: Box/Rectangle
Size(width): 20 (DEFAULT)
Size(height): 45
Standup: Not Checked
Rounded: Checked (DEFAULT)

Cone

2D Paintball Parameters
Type: Dorito
Radius: 20 (DEFAULT)
Standup: Checked (DEFAULT)
Rounded: Not Checked

Large Torido

2D Paintball Parameters
Type: Dorito
Radius: 20 (DEFAULT)
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)
Note: Our dorito size is a bit larger than 2D Paintball’s, so leave some space

Small Torido

2D Paintball Parameters
Type: Dorito
Radius: 20 (DEFAULT)
Standup: Not Checked
Rounded: Checked (DEFAULT)

Cake

2D Paintball Parameters
Type: Dorito
Radius: 15
Standup: Not Checked
Rounded: Checked (DEFAULT)

Tall Cake

2D Paintball Parameters
Type: Dorito
Radius: 15
Standup: Checked (DEFAULT)
Rounded: Checked (DEFAULT)

Prism

2D Paintball Parameters
Type: Dorito
Radius: 15
Standup: Checked (DEFAULT)
Rounded: Not Checked

Special Bunkers

Button / Buzzer

2D Paintball Parameters
Type: Barrel
Radius: 5
Standup:
- Checked = Blue Button that Pink Team can hit
- Not Checked = Pink Button that Blue Team can hit

Creating Snapshot VR Maps with the 2D Paintball Field Creator was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve worked hard to make importing of your own songs and beatmaps into the My Tracks feature of Chop It simple and accessible. Today we’ll cover the basic features in the VR beatmap editor, which we call the Mapping Station, as well as explain the basic directory and file structure for importing your content.

Along with this article, we’ve made a quick start video that shows how to set up the directory for a new song to be imported.

[2018–09–14] Update: We now have an external 2D mapping tool that runs in your browser. It’s in beta, but you can check out the latest stable build here. It offers tap along mapping as well as converters for MIDI and Beat Saber tracks.

File and Directory Format for Imported Content

When you install Chop It, we include Terror Pigeon’s song ‘Chamber of Secrets for 1’ as an example for you to copy or reference.

You can find this example in the StreamingAssets directory within Chop It’s local data. On Steam, this should be at ‘steamapps/common/Chop It/chopit_Data/StreamingAssets’. You can quickly navigate to this directory by selecting Chop It from your Steam Library, going to Properties, and on the Local Files tab clicking the ‘Browse Local Files…’ button.

Within the StreamingAssets directory you’ll find the ‘TerrorPigeonChamberOfSecretsFor1’ folder which contains all of the files necessary to have a playable song in Chop It.

ChamberOfSecretsFor1.wav — the audio file to be played.
SongInfo.json — a json file containing the artist name and song title that you’d like to be displayed in-game.
ChamberOfSecretsFor1_beatmap_standard.txt — the beatmap file, which contains a json object describing the gameplay associated with this audio file. We’ll explain the file format in more detail below.

Some useful notes about the imported files:

• The audio file must be of format .wav. This is due to a restriction with Unity around importing external audio files. A quick and easy solution for other file formats is to download the free audio tool Audacity and convert the file to a .wav. You can find a tutorial on how to do this conversion here.
• The name of the folder containing your files does not matter, as long as it is in the StreamingAssets directory.
• SongInfo.json contains information that is solely for display purposes. Edit this file in Notepad (or similar) to set the display artist name and song title to whatever you’d like.
• Beatmap files must be of type .txt or .json and the file name must contain the word ‘beatmap’ in order to be imported. This file can be generated in-game when using the VR Mapping Station to create a beatmap.

Importing Songs

Following the Terror Pigeon example, we can quickly get to mapping our own audio files.

The first step is to make a new directory in the StreamingAssets folder. For this example, my folder will be named ‘ConBroChillPowerHappy’.

Copy your .wav file into your newly created ConBroChillPowerHappy folder.

In order for our song to appear in-game, we need to set some display information.

Create a new text file named ‘SongInfo.json’, or simply copy the existing file from the Terror Pigeon example directory. Within SongInfo.json we simply need this string:

{“artistName”: “Con Bro Chill”, “songName”: “Power Happy”}

Set the values of artistName and songName to be whatever you’d like to appear in-game.

If you’ve created and populated this file successfully, you will now see your song the next time you load the My Tracks menu in Chop It.

If you navigate to your new song in Chop It and select it to be played, you’ll notice that it displays the song information but is not playable because there are no selectable beatmaps.

That means it’s time to create a new beatmap!

Creating Beatmaps with the VR Mapping Station

In that same song information screen, you can hit the Create/Edit Beatmap button. Since no beatmap is selected, it will take you to the Mapping Station with a new empty beatmap. Once you have a beatmap created, you can always come back and edit the beatmap by navigating to the song information screen, selecting the beatmap you wish to edit, and hitting the Create/Edit Beatmap button.

The Mapping Station is built to give you total control over the player’s experience during the song.

On each hand, you will see an object in front of your fingers that looks like a small version of a board with a white sphere in the middle. We call the fullobject the Mapping Tracker and the white sphere is the Control.

This Mapping Tracker is built to give you a preview of exactly what type of item will be spawned, as well as the final rotation of the item, when you map a beat. As you rotate your hand, you’ll see the item locking to the supported rotation closest to the rotation of your hand. Similarly, if you hold the trigger to make a fist you’ll notice the board switches to a cinderblock.

In front of you is the array of Target Boxes represented by green cubes. Four on the top row, three in the middle, and four on the bottom. These represent the final landing locations of the items as the Sensei throws them.

Any time the Control of your Mapping Tracker touches a Target Box, a new beat will be added to your beatmap containing the time in the audio file that was playing when the contact occurred, the Target Box ID with which the contact occurred, the item type (board or cinderblock) active at the time of contact, and the rotation of the item at the time of contact. These attributes describe exactly how the beat will be presented to the player when that time occurs in the song. You can see these beats as they are mapped to the right of the Target Boxes on the Chalkboard.

You can map beats while the song is playing or paused. There is a Play/Pause button under the Target Boxes along with an audio slider for you to jump around the song time.

If the song is playing in the Mapping Station, any previously mapped beats will appear as the song plays. This allows you to preview the flow of the beatmap without having to leave the tool.

To further customize the gameplay at a previously-mapped time, you can select a beat from the Chalkboard to the right of the Target Boxes. This will jump to the audio time of that mapped beat as well as preview any beats mapped to that time. You can then map new beats at that same time or delete beats by hitting the red box next to any beat on the Chalkboard. Use this tool to create swipes and combos or really complicated unplayable beatmap art.

To save your beatmap at any time hit the Save to File button to the right of the Chalkboard. If this is a new beatmap, this will generate a new beatmap file within the same folder as the audio file you are mapping. The name will typically be something like ‘SongName_beatmap_custom_<timestamp>.txt’.

Saving to file is not done automatically, so if you do something like accidentally hit the Clear Beats button, you can exit the tool and re-enter and it will reload the beatmap from disk.

The Detect Beats button will algorithmically detect beats in the audio file that you are mapping. This feature can only be activated for new, empty beatmaps. It typically takes 5–15 seconds depending on the file size and is a bit experimental.

The intention here is to give you a skeleton of a beatmap to further customize. You can, of course, generate a full beatmap with the Detect Beats feature, Save to File, and play it immediately, but in our experience curating a beatmap to play exactly how you want will give players a more enjoyable experience. If you’re interested in the beat detection algorithm, we’ve written a detailed blog and released the working source code here.

For those that are interested in the internals of beatmaps, and potentially creating your own tools to create beatmaps, we will go into detail about the contents of a beatmap.

Understanding Beatmap Files

Beatmap files are essentially json serializations of the beatmaps generated in-game. Since we know some users may prefer to edit beatmaps manually or with an external tool, we’ll describe the properties of the beatmap here:

mapName — a display field for the name of the beatmap.

appVersion — populated with the current release version of Chop It. Example: “1.5.3”

randomSenseiMovement —one of true, false (no quotes)— a setting which enables or disables the Sensei’s ability to jump around the Pagoda during gameplay.

difficulty —one of “easy”, “standard”, “hard” — a display field describing the difficulty of the beatmap.

beats — a list of Beat objects listed in order by time — This list is iterated during gameplay and beat times are compared to the audio time as the song plays.

A beatmap with metadata, but no beats, would look like this:

{
“mapName”:”Techboy’s Beatmap”,
“appVersion”:”0.2.0",
“difficulty”:”standard”,
“randomSenseiMovement”:true,
“beats”:[]
}

Beat objects are representations of gameplay at a given audio time. The properties of a Beat:

beatID — the position of the beat in the sequence starting with the number 0. The first beat you map would have beatID of 0, the second beat you map would have beatID of 1, etc… When a beatmap is saved to file in the Mapping Station, these IDs are automatically generated after the beats are sorted by time.

time — the exact time in the audio file that the player is expected to hit an item. This time is in seconds with millisecond precision. Example: 125.004 would represent the audio playing 2 minutes, 5 seconds, and 4 milliseconds into the song.

rotationID — one of “H”, “V”, “R”, “L” — The rotation of the item when it is expected to be hit. H (horizontal), V (vertical), R (diagonal with top leaning right), L (diagonal with top leaning left). Default is horizontal.

itemType — one of “B”, “C” — The type of item spawned. B (board), C (cinderblock). Default is board.

targetID — “A”, “B”, “C”, “D”, “E”, “F”, “G”, “H”, “I”, “J”, “K” — The target location that the item is thrown to. Default is F., which is the center-most target.

Target locations as they appear to the player:

A — B — C — D
- E — F — G -
H — I — J — K

Regardless of the position of the Sensei, the targets rotate accordingly so this orientation to the player is guaranteed.

A beat object that is fully populated looks like this:

{
“beatID”:0,
“time”:3.58
“targetID”:”F”,
“rotationID”:”H”,
“itemType”:”B”
}

and a fully functional beatmap with 2 beats looks like this:

{
“mapName”:”Techboy’s Beatmap”,
“appVersion”:”0.2.0",
“difficulty”:”standard”,
“randomSenseiMovement”:true,
“beats”:[
{“beatID”:0,“time”:3.58,“targetID”:”F”,“rotationID”:”H”,“itemType”:”B”},
{“beatID”:1,“time”:6.91,“targetID”:”D”,“rotationID”:”V”,“itemType”:”C”}]
}

Summary

We’d love your feedback about how we can make the mapping experience better for you. Feel free to send us your beatmaps for us to play and test, and please report any bugs you come across! As always, you can find us on Twitter, Steam, or email us directly at scambot@giantscam.com.

Thanks!

Adding Songs and Beatmaps to Chop It was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Giant Scam was formed in 2017 by Jesse, who is an Engineering Lead by day, and Charlie, who is an excellent Game Designer and Twitch Parter. Today our crew consists of Jesse, Charlie, our technical artist Tanner, and our infrastructure engineer Brandon. We partner with local collective Strange Handle AV for music and NPALL Audio for SFX. We collaborate closely with the Nashville Game Developers group and also host the bimonthly Game Dev House Party series.

Our first game, a VR rhythm game named “Chop It”, released on Steam in September 2018. Alongside that release, we released an open-source solution for procedural rhythm games that is detailed under the “Algorithmic Beat Mapping in Unity” section of our blog.

Now, we’re gearing up for our next VR title, which will be announced in Q2 2019.

You can catch us at:

Our beautiful home page: http://www.giantscam.com
Twitter: https://twitter.com/giantscam
Our support line: scambot@giantscam.com
Discord: https://discord.gg/Yq3dzm2

If you want to support us outside of game, check out our Big Cartel merch store.

Lastly, feel free to sign up for our Mailing List (no spam/scam guaranteed):

That’s it.

Thanks!

What is Giant Scam? was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro
Real-time Audio Analysis Using the Unity API
Preprocessed Audio Analysis
Outro

Github Repo

This public repo is yours to clone and experiment with. While you’re welcome to contribute, I don’t plan to maintain this code sample long-term. If you get a chance to use it in a project, please give me a shout!

https://github.com/jesse-scam/algorithmic-beat-mapping-unity

What’s Next?

Once you are reliably and accurately detecting beats in your audio files, there are a few things you can experiment with to fit the algorithm to your particular use case:

1. Running the spectral flux algorithm on different sub-ranges of the frequency spectrum. I give you a hint on how to do this in Real-time Audio Analysis Using the Unity API.
2. Finding the threshold sensitivity time frame and multiplier that work best for your use case.
3. Getting deeper with Threads to speed up the preprocessing analysis. It takes about 8 seconds for a 5 minute song on my machine.

What you choose to do with the detected beats is what makes each use case unique. Once you have all the peaks in all the frequency ranges you care about, how do you determine which groupings of beats give you the best gameplay? This is completely up to you for what fits your type of game best, but you should now have all of the data to start experimenting!

Outro

I started this article as self-documentation to reference as I experimented with algorithmic beat mapping. I had never intended to include algorithmic mapping in Chop It, but the engineering challenge seemed interesting so I gave it a shot. After many dead ends and finding a general lack of understanding about how to do something like this in Unity, I wanted to share what I learned with the game dev community.

Shout outs:

Dylan Fitterer (https://twitter.com/dylanfitterer) for nailing this down years ago with Audioshield and inspiring me to take a stab at it.

Jashan Chittesh (https://twitter.com/jashan) for great conversation around VR rhythm games and for truly innovating in the genre with Holodance.

Dr. Eric Carr for proofreading my posts and helping me gain a much deeper and clearer understanding of the audio side of things!

Mario at Bad Logic Games (http://www.badlogicgames.com) for writing an amazing article about onset detection. You made this article series possible!

Tanner Netterville (https://twitter.com/rennat) for starting to work on art for Chop It so I don’t sit around for 2 more months writing blogs about algorithmic beat mapping.

Charlie Winsmore (https://www.twitch.tv/charliewinsmore) for helping me create the smallest gaming company with the best name of all time.

Everyone else that listened to me rant about this at a bar or over lunch for the past 2 months. You are saints.

Please don’t hesitate to reach out to us at scambot@giantscam.com or on Twitter at https://twitter.com/giantscam. Show us what you’re making!

Until next time!

Algorithmic Beat Mapping in Unity: Outro was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro
Real-time Audio Analysis Using the Unity API
Preprocessed Audio Analysis
Outro

If you haven’t read the previous post in the series, Real-time Audio Analysis Using the Unity API, please take the time to do so before reading on. It covers many of the core concepts needed to perform our preprocessing analysis.

When doing real-time analysis, we found that we had to lag slightly behind the currently playing audio in order to detect beats. We also could only use the beats detected up until the current time in the track to make decisions. We can eliminate these limitations by preprocessing the entire audio file up front and detecting all beats before playing audio to the user.

Unity Specifics

While most of Unity’s helpers are meant for real-time analysis, it does offer us one helper that can get us started. To process an entire audio file up front, we need all of that file’s sample data. Unity allows us to get that data with AudioClip.GetData. As you can see in the documentation example, it allows us to populate an array with all of the samples that the clip contains.

AudioClip.samples is the total number of single-channel or combined-channel samples contained within the clip. That means if a clip had 100 samples in stereo, AudioClip.samples would be 50. We multiply by AudioClip.channels because AudioClip.GetData is going to return sample data in interleaved format. Meaning, if we have a clip that is in stereo, the data will come back as:

L = Left Channel ; R = Right Channel
[L, R, L, R, L, R,…]

That means that, if we want data similar to what Channel 0 returns in the real-time helper AudioSource.GetOutputData, we need to go through our full set of samples and average every two samples together to get mono samples. You’ll find that this can be very taxing on the CPU because of the number of samples in a given clip.

Let’s do the math:

If I have a 5 minute (300 second) audio track, with a sampling rate of 48000 samples per second, that means we have:

300 * 48000 = 14,400,000 samples (which can be found in AudioClip.samples)

BUT, if we are in stereo, we have interleaved samples, which doubles our sample count

14,400,000 * 2 = 28,800,000 samples

We really want that 14.4 million samples in mono, so we’ll iterate over the 28.8 million samples and average every pair of stereo samples to get this. If you’d like to do this over a series of frames using the offset parameter to get smaller chunks of the audio samples, you should know that the offset parameter is actually applied against the combined-channel number of samples (AudioClip.samples). So if you pass an offset of 10, you’re still going to get interleaved stereo samples, but it will start 20 (10 pairs of stereo) samples into the stereo data.

No matter what you’re doing, iterating over 28.8 million samples is not going to be fast enough to do on the main thread in Unity. I recommend passing this task to a background thread using the System.Threading library, which is packaged with Unity C#. We won’t go deeply into System.Threading here, but you should know that Unity strongly suggests (often in the form of throwing an exception) that you do not access any Unity API functionality from within a background thread. Grab any values from AudioSouce / AudioClip that you need, make them accessible, and then do the math inside of the thread and leave all access of the Unity API to the main thread.

Let’s get set up to convert our stereo samples to mono. First, we need to grab any attributes from the Unity API that we might need later when we spawn the background thread:

Now the loop for combining channels:

Now, our float array preProcessedSamples contains data that is of the same format as what’s returned in real-time by AudioSource.GetOutputData, but it contains samples from the beginning of the track until the end instead of just the samples for the currently playing audio. You can compare your output to the output of AudioSource.GetOutputData for a point in time in the song and see that they are fairly close. One catch here is that AudioSource.GetOutputData returns the most recently played 1024 (or length of your array) samples, which might trip you up if you’re doing the math to find the starting point in your preprocessed samples that represent a point in time in the track.

Working with Frequencies (and external libraries)

We have our sample data, which is amplitude over time, but what we want is spectrum data, or significance over the frequency spectrum at a point in time. In our real-time analysis we achieved this with Unity’s helper AudioSource.GetSpectrumData to perform a Fast Fourier Transform. Unity does not have an equivalent helper for performing an FFT on raw sample data, so we’ll want to look elsewhere.

I landed on a very lightweight C# implementation of the basic Fourier Transform called DSPLib. It includes both the Discrete Fourier Transform and the Fast Fourier Transform, a number of available windows, and, most importantly, it gives us output that represents the same relative amplitude that we had when using AudioSource.GetSpectrumData.

Click “Download Library C# code only” to download the source code for the FFT, then extract the DSPLib.cs file and place it in a directory in your project.

There is a catch here. DSPLib relies heavily on the Complex data type provided by C#.NET’s System.Numerics library. You’ll see that Unity is complaining about not being able to find the Complex data type or System.Numerics. This is because Mono, the flavor of .NET provided by Unity, does not include the System.Numerics library. What we can do to get around this is go directly to the source (Microsoft’s github page in this case) and download Complex.cs and place it in our project. Complex.cs does require some minor conversions before it will compile in Unity. I’ll place my version of the conversion here:
https://github.com/jesse-scam/algorithmic-beat-mapping-unity/blob/master/Assets/Lib/External/NET/Complex.cs

If we add references to our new libraries at the top of our file, we should be able to compile with no issue.

I’ll go ahead and show you the code for executing the rest of the sample preparation before we send our spectrum data to our spectral flux algorithm. If we’ve done everything correctly, we won’t have to change our spectral flux algorithm at all.

Much of what you see here is based on the examples given on the DSPLib site. The basic steps are:

1. Combine stereo samples to mono
2. Iterate over samples in chunks the size of a power of 2. 1024 is our magic number here again.
3. Grab the current chunk of samples to be processed
4. Scale and window it with one of the available FFT Windows. I found DSPLib’s implementation of Hanning to be pretty reliable here.
5. Execute the FFT to retrieve complex spectrum values, which will again be half the size of our sample data — 512 in this case.
6. Convert our complex data to a usable format (array of doubles)
7. Apply our window scale factor to the output
8. Calculate the current audio time represented by the current chunk
9. Pass our scaled, windowed, converted spectrum data to our spectral flux algorithm. You can see here that I set us up to use floats, and DSPLib really likes doubles. I’m adding some overhead by doing the conversion to float instead of converting the spectral flux algorithm to use doubles.

In the real-time analysis we asked Unity to give us 1024 spectrum values, which means under the hood Unity was sampling 2048 audio samples on the time domain. Here we provide 1024 audio samples from the time domain which gives us 512 spectrum values. That means we have slightly different frequency bin granularity. We could of course provide 2048 audio samples to have the exact same granularity as we did in the real-time analysis, but I found that having 512 bins was very passable for onset detection at different points in the spectrum.

For 512 bins, we’d simply divide the supported frequency range (our sampling rate / 2 — the Nyquist frequency) by 512 to determine the frequency represented per bin.

48000 / 2 / 512 = 46.875Hz per bin.

We don’t need to redefine our Onset Detection using Spectral Flux algorithm here. It stays exactly the same because we’ve formatted our spectrum data in a similar way to what we had available when doing real-time analysis.

Navigating the Spectral Flux Output

The calculation of audio time is pretty simple. We know that our sample data is amplitude over time, so therefore each index must represent a different point in time. Our sample rate and our current position in the sample data can tell us roughly (within a few milliseconds) what time our current sample chunk is representing.

Let’s take our Terror Pigeon song from the real-time example. It is 04:27, or 267 seconds long. The clip has a sampling rate of 44100 (AudioClip.frequency) samples per second. So, we expect there to be roughly:

44100 * 267 = 11,774,700 samples

Logging AudioClip.samples gives us 11,782,329 samples. About 8k more samples, or 0.18 more seconds, than we expected. This is only because the track is not exactly 267 seconds long.

We need to know how much time is being processed per chunk, so that we have some idea of what time is represented by a spectral flux sample.

1 / 44100 = ~0.0000227 seconds per sample
0.0000227 * 1024 = 0.023 seconds per chunk

We could come to the same result by dividing the track length in seconds by the total number of samples, if we have that information available.

267 / 11,774,700 = ~0.0000227 seconds per sample
0.0000227 * 1024 = 0.023 seconds per chunk

We can do the math in reverse as well, to know what spectral flux index corresponds to a particular time in the song. Listening to the song , I’m hearing a bass beat about 3.6 seconds in. There are plenty of others, but let’s use this one as an example.

The time divided by the length of time per sample should give us the index, but we have to remember that we’ve been grouping by 1024 samples per chunk to get our spectral flux.

So at time 3.6:

3.6 / 0.023 = 156.52 — so we’d expect to find a peak near index 156.

Results

Each index in our spectral flux output only represents 0.023 seconds, and I picked out time 3.6 by ear, so we may not be right on target. Let’s take a look at 10 samples in each direction from index 156, about a half second total, to see if we’re close.

Our algorithm found a peak at index 148. So I was 8 indexes, or about 0.184 seconds off. Not too shabby.

Looking at a larger window in each direction, we can see that we are logging a peak about every 18 indexes, or every 0.414 seconds. This means that the song’s tempo must be ~145 BPM for the section we are analyzing. To be sure, I asked Terror Pigeon what the actual BPM of the song is and he said I was 2 off, it’s 143 BPM for the full song. Not bad for analyzing a ~1 second time frame!

You can do a similar comparison with the following code:

Let’s plot the output of both the real-time analysis and the preprocessed analysis side-by-side to compare.

Our real-time plot is on the top and our preprocessed plot is on the bottom. You can see there is a bit of skew, but the highest 9 peaks on the real-time plot roughly correspond to the same 9 peaks on the preprocessed plot. The skew is because our indexes in real-time are roughly 1 frame’s time apart, which is not the same distance as our indexes in preprocessed which we know are 0.023 seconds apart for this track. You can see that there is less fluctuation and less over-recording in the preprocessed plot and, of course, our preprocessed plot extends beyond real-time. We can jump to any time in the song and our preprocessed spectral flux will be available.

We are now mapping all beats of an audio file before playing the audio to the user. While results may vary, this should set you up nicely to start creating your own gameplay based on beats within an audio file.

What to experiment with and where to focus next will be covered briefly in the Outro.

Algorithmic Beat Mapping in Unity: Preprocessed Audio Analysis was originally published in Giant Scam on Medium, where people are continuing the conversation by highlighting and responding to this story.