Level Management Final solution for failing QR codes

Let's SHRINK all the QR codes!!

Hi! I know it's totally frustrating when a QR code for a level you crafted doesn't work because it is too dense. And a new level designer doesn't expect a code to fail, so great levels like King Of Kong fail for most users without the designer realizing it before posting. Experienced level designers know to test the QR before posting, but it adds minutes or hours to their workflow. It's a big issue, but I have a solution to make the QR codes work every time by making them less dense. It's a permanent solution! But it will require an app update.

First, a little background. My company develops apps that use QR codes for small business promotions in the US. There are millions of small businesses here, and each of them may have thousands of promotions. The possible QR code permutations could reach 1 trillion over a few years, so we had to think strategically. We solved the problem in an elegant way, and our QR codes are surprisingly simple. Before I explain the solution, I will outline the current way QR's are handled by the Mekorama app so we are all on the same page.

URL's, URI's, and QR codes
We are all familiar with website URLs, and apps can use something similar, which is called a URI (unique resource identifier). Just like a website URL a URI is a string of text. But instead of linking to a webpage it is a way to send a "data description" to an app, such as the "blueprint" of a Mekorama level. These URI's are actually strings of text that describe every detail, encoded into a QR code. So when you see a QR code for a Mekorama level, it includes a blueprint for each block and behavior in that level. Within Mekorama QR codes are a brilliant way to share the "blueprints" for a level with others.

The permanent solution
Instead of generating QR codes based on URI's that include all the detail for every block and behavior in a level, a "tiny URL" solution should be used in the following way. Instead of encoding every detail of a level directly into the QR code, the new process will publish and store the detailed URI into a database, and assign a short reference URI to it. This new shortened URI will be used by the app to generate very simple QR codes, which is only a reference to the long-form description of the level in the database.

This will require a couple changes, and I have further recommendations that would save tons of hours for level creators. First, the level descriptions could be indexed into a database that results in short URI's for each level, so that a QR code for a level would not include the full "blueprint" for that level, but instead a short URI address to link to the level's full blueprint.

But let's take this further. Currently level creators publish several iterations of a level before declaring a level is "finished". Wouldn't it be fantastic if the QR code for an evolving level always linked to the latest (or final) iteration? Here's how this can be achieved. The QR code URI should be based on a hash of the level's title, combined with the unique name of the level creator. (This still allows for unlimited levels per creator). For example, if I published a "draft" level named iRobot by Robot Artist, the QR code would only link to the latest version of the level. This approach implicitly allows for level creators to perform "soft-updates" to their levels without requiring the user to do anything. And if a creator simply adds "v2" or "v3" to a level title, it will automatically create separate versions.

There are two more things I need to address, with full respect for our growing Mekorama community.
1) What about current QR codes?!
2) What about security?!

1) What about Current QR codes:
All current QR codes will remain usable. In fact, there should be an option for any level designer to publish a "verbose" QR code that includes every block and behavior detail. That said, it should be understood that complex QR codes may fail regularly.

2) What about security:
I have proposed a URI handling update that will create simpler QR codes. But there's a glaring security flaw if a QR is made from a hash of a unique level's title and the creator's name. The flaw? It would be easy for someone to use the exact same level title and copy the creator's name, then publish a level that would override the previous level. It may not seem like a serious security matter, but I wanted to share some similar issues. I would be happy to share how we tackled this, let me know a good time!

 

Thank you @Gepeto for pointing me to the QR thread, I should have looked harder for an existing conversation. Should I delete this thread and contribute to the conversation there? I don't know what the best etiquette is.

The solution above is something that @Martin Magni may be interested in for a future app update, or he may disregard it. The Bitly API could be used instead of a custom hosted URL shortening script, but you have less control with Bitly.

Not a sales pitch I don't do any contract work, just our internal platform. I gave some company background only to give context for the solution I described. It didn't seem like a good idea to share our security methods on a public forum, but I could share over chat. That said, security doesn't seem too critical for this use.

 

Thanks for moving this thread!